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. 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. 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! 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. > > > >
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
