- From: Alexey Melnikov <alexey.melnikov@isode.com>
- Date: Wed, 13 Oct 2021 14:14:17 +0100
- To: Carsten Bormann <cabo@tzi.org>, Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
On 13/10/2021 14:05, Carsten Bormann wrote: >> On 2021-10-13, at 14:52, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> Am 13.10.2021 um 08:56 schrieb Carsten Bormann: >>> On 2021-10-13, at 08:48, Julian Reschke <julian.reschke@gmx.de> wrote: >>>> Am 12.10.2021 um 23:48 schrieb Carsten Bormann: >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-11 >>>>> says: >>>>> >>>>> media-type = type "/" subtype parameters >>>>> parameters = *( OWS ";" OWS [ parameter ] ) >>>>> >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-10 >>>>> says: >>>>> >>>>> media-type = type "/" subtype *( OWS ";" OWS parameter ) >>>>> >>>>> Is the rationale for making the parameter optional documented? >>>>> >>>>> Where -10 would have allowed: >>>>> text/plain;format=flowed >>>>> … 11 now allows: >>>>> text/plain;;;;format=flowed;; >>>>> >>>>> Very curious. >>>> See <https://github.com/httpwg/http-core/issues/33>. >>> Thank you! >>> So my conclusion is that this is on the same level as OWS or obs-text and should not be promoted in new specifications using this syntax. >> I would characterize it as something that many implementations decided >> to accept despite it being invalid, and thus it got used in the wild. > Sure, trying to outlaw these implementations doesn’t work for HTTP. > > But we are creating a different wild: > Using media-types (content-types and content-codings, actually) in SenML. > > https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-05.html#name-abnf (*) > >> Not sure about what new specifications you have in mind. If it really >> replicates Content-Type syntax, I would just align with the current >> spec. > Which is exactly what we don’t want to do — carrying that 25-year old baggage (HTAB, obs-text…) into new software that doesn’t have to (directly) interoperate. > (The use case really isn’t about copy-paste from an HTTP header to a SenML record; in that case carrying the baggage might make at least some sense.) Using more restrictive syntax in core-senml makes sense to me. > [CDDL has a way to identify syntax that is deprecated; maybe that is needed for ABNF. But that might be for another list…] > > Grüße, Carsten > > (*) Yes, there is one bug… Fixing that in today’s interim. > >
Received on Wednesday, 13 October 2021 13:14:39 UTC