Hi Mark, On Tuesday, February 13th, 2024 at 10:11 AM, Mark Nottingham <mnot=40mnot.net@xxxxxxxxxxxxxx> wrote: > Hi Rahul, > > > On 12 Feb 2024, at 6:48 pm, Rahul Gupta cxres=40protonmail.com@xxxxxxxxxxxxxx wrote: > > > > Hi there, > > > > I would like to put forth the following points for consideration before adopting 'Structured Field Values for HTTP' as a proposed standard. > > > > 1. The text in the section on Display Strings (a new addition in this standard) fails to mention that these must begin with a `%` followed by a DQUOTE (compare that, for example, with text in the section on Boolean). One is forced to infer this from the example or by reading the parsing rules. > > > I'll take that as editorial feedback, thanks. You're welcome! > > > 2. The specification implicitly assumes that members of a List are allowed to repeat, building on a traditional notion of an array. It would be ideal if this notion be made explicit, especially since it is possible to ascribe special meaning to repeated items, much more so when these repeated items can be parameterized differently. More importantly, I would request that additional guidance be provided by the specification, requiring that header field definitions specify how repeated Items (and associated parameters) are dealt with, at least in the specific (uncommon) case where repeated items are not treated as separate items (but, say, for example as an override) by the header field in question. > > > The WG discussed this in https://github.com/httpwg/http-extensions/issues/2724, which you opened recently. Based on what's happened there so far, I don't think there's reason to make a change. Unfortunately, what happened there was that I withdrew from the discussion (see PS in my last comment), because it was not my intention to grandstand. Note that my request here is significantly weaker than the one I made in the GitHub issue cited above. However, I stand by this comment, especially since it relates to an in-group consensus that an outsider might not be in on. This also relates to an actual life experience where a server erroneously repeats headers (although rare, is known to happen). Since, this was an Item header, it was dismissed in the cited discussion, quite unfairly, as a "red-herring"; it could easily have been a List (with multiple parametrized Items repeating). Alerting headers to specify any non-standard List/Array of Items handling solves this issue. I would like this comment (and response) to be on-the-record, even if the consensus is to refuse this watered down version of my request! > > > 3. I had made a request, rather late in the day, that parameters allow not just "bare items" but "bare array of items" as well. This change allows for arbitrarily deep nesting of headers, which is currently not possible. I have illustrated its need with a use-case. Its absence would force one to resort to rather ugly hacks and/or header proliferation in certain circumstances. One of the authors has suggested that this request constitutes a breaking change, and therefore not eligible to be considered. However, as I observed in the issue, this is a feature enhancement (as opposed to a breaking change), completely backwards compatible with the proposed specification. AFAICT, all structured field values that would be successfully parsed in the current version of the proposed specification would parse no differently. Only some field that would have emitted an error, i.e. those using bare arrays of items as parameters, will now parse as well. This might trip type checkers etc., but is no different from the introduction of a new type like Display Strings. In any case, new fields are required to refer to the specification they are using! > > > See discussion in https://github.com/httpwg/http-extensions/issues/2732. > In light of the discussion in the issue mentioned above, I withdraw this comment for this last-call. > > Cheers, > > > BR/Rahul > > > > On Monday, January 29th, 2024 at 10:31 PM, The IESG iesg-secretary@xxxxxxxx wrote: > > > > > The IESG has received a request from the HTTP WG (httpbis) to consider the > > > following document: - 'Structured Field Values for HTTP' > > > <draft-ietf-httpbis-sfbis-05.txt> as Proposed Standard > > > > > The IESG plans to make a decision in the next few weeks, and solicits final > > > comments on this action. Please send substantive comments to the > > > last-call@xxxxxxxx mailing lists by 2024-02-12. Exceptionally, comments may > > > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > > > of the Subject line to allow automated sorting. > > > > > Abstract > > > > > This document describes a set of data types and associated algorithms > > > that are intended to make it easier and safer to define and handle > > > HTTP header and trailer fields, known as "Structured Fields", > > > "Structured Headers", or "Structured Trailers". It is intended for > > > use by specifications of new HTTP fields that wish to use a common > > > syntax that is more restrictive than traditional HTTP field values. > > > > > This document obsoletes RFC 8941. > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-httpbis-sfbis/ > > > > > No IPR declarations have been submitted directly on this I-D. > > > > <publickey - cxres@xxxxxxxxxxxxxx - 0x0CEC7748.asc>-- > > last-call mailing list > > last-call@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/last-call > > > -- > Mark Nottingham https://www.mnot.net/
Attachment:
publickey - cxres@protonmail.com - 0x0CEC7748.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
