Re: Media type parameters optional between semicolons

[Julian Reschke <[e-mail]>]

Am 13.10.2021 um 15:05 schrieb Carsten Bormann:
>
>
>> On 2021-10-13, at 14:52, Julian Reschke <[e-mail]> wrote:
>>
>> Am 13.10.2021 um 08:56 schrieb Carsten Bormann:
>>> On 2021-10-13, at 08:48, Julian Reschke <[e-mail]> 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.)
> ...

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