Subject: Media type parameters optional between semicolons

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 Oct 2021 23:48:26 +0200

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.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Oct 2021 08:48:03 +0200

> text/plain;;;;format=flowed;;

See <https://github.com/httpwg/http-core/issues/33>.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Oct 2021 08:56:56 +0200

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

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Oct 2021 14:52:22 +0200

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

Disallowing it at this point was somewhat pointless.

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. On the other hand, if it's something really new, I would suggest
looking at Structured Fields.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Oct 2021 15:05:55 +0200

> On 2021-10-13, at 14:52, Julian Reschke <[email-masked]> wrote:
> 

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 (*)

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Oct 2021 14:14:17 +0100

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Oct 2021 15:21:40 +0200

Am 13.10.2021 um 15:05 schrieb Carsten Bormann:
> ...

That may work if you require recipients to reject invalid values. If you
do not, you may end up in the same situation as the HTTP world.

 > ...

Best regards, Julian