Re: [dispatch] IANA Registry for parameters for the MIME header field "Content-Type" ?

[Alexey Melnikov <[e-mail]>]

Hi John,

On Wed, Apr 19, 2023, at 12:01 AM, John C Klensin wrote:
> Dan,
>
> This probably falls within the scope of the existing MEDIAMAN WG
> (copied).  Two observations:
>
> (1) There was, at least as I recall, never a plan for parameters
> to be shared, using the same keywords, value set, and semantics
> across content-types, especially top-level content types.
> Unless we intent to change that, it is not clear what value a
> registry might have.

I am not arguing in favour or against have a new registry, but I got an impression that parameters like "charset" are shared across all text/* media types, and "boundary" is common for all multipart/* media types. So even if originally there was no intent to share parameters, I don't think your statement above is still true.

Best Regards,
Alexey

> (2) While content-type parameters seemed like a good idea for
> email and probably were, they introduce some interesting issues
> for URLs.  Interactions with the latter have led to structured
> content-type subtypes of the application/foo+bar+baz variety.
> MEDIAMAN is explicitly addressing that topic [1].  The
> relationship between the two approaches is a major subject of a
> note I've been trying to find time to write since IETF 116.
>
> best,
>    john
> 
>
> [1] See, e.g.,
> https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/
>
> --On Tuesday, April 18, 2023 16:50 -0400 Daniel Kahn Gillmor
> <[e-mail]> wrote:
>
>> Hey IETF folks--
>> 
>> While polishing draft-ietf-lamps-header-protection, i noticed
>> that there is no IANA registry for parameters for the
>> Content-Type MIME header field.
>> 
>> Some of these are pretty common, like "boundary" (for
>> distinguishing subparts of any multipart MIME part) and
>> "charset" (for identifying the encoding used in a text part),
>> and others are more obscure.
>> 
>> Scanning a reasonably large mail corpus, i found a range of
>> parameters used:
>> 
>>   - boundary
>>   - charset
>>   - delsp
>>   - format
>>   - markup
>>   - micalg
>>   - name
>>   - protected-headers
>>   - protocol
>>   - reply-type
>>   - report-type
>>   - smime-type
>>   - type
>> 
>> I note that there are also some comparably-structured
>> "parameter" fields for the Content-Disposition header (e.g.
>> "filename"), though i doubt that there are so many as there
>> are for Content-Type.
>> 
>> It seems like it might be worthwhile to try to establish a
>> registry for these parameters (at least for Content-Type, so
>> that there is at least a stable reference that can be used by
>> a MUA that wants to handle the parts appropriately..
>> 
>> Any thoughts about the right place to do this work on e-mail
>> in the IETF?
>> 
>>         --dkg
>> 
>> PS to be clear, it is not the intent of this message to:
>> 
>>  - create any new document dependency that might block
>>    draft-ietf-lamps-protected-headers
>> 
>>  - define any new parameters for Content-Type
>
>
>
> --On Tuesday, April 18, 2023 16:50 -0400 Daniel Kahn Gillmor
> <[e-mail]> wrote:
>
>> Hey IETF folks--
>> 
>> While polishing draft-ietf-lamps-header-protection, i noticed
>> that there is no IANA registry for parameters for the
>> Content-Type MIME header field.
>> 
>> Some of these are pretty common, like "boundary" (for
>> distinguishing subparts of any multipart MIME part) and
>> "charset" (for identifying the encoding used in a text part),
>> and others are more obscure.
>> 
>> Scanning a reasonably large mail corpus, i found a range of
>> parameters used:
>> 
>>   - boundary
>>   - charset
>>   - delsp
>>   - format
>>   - markup
>>   - micalg
>>   - name
>>   - protected-headers
>>   - protocol
>>   - reply-type
>>   - report-type
>>   - smime-type
>>   - type
>> 
>> I note that there are also some comparably-structured
>> "parameter" fields for the Content-Disposition header (e.g.
>> "filename"), though i doubt that there are so many as there
>> are for Content-Type.
>> 
>> It seems like it might be worthwhile to try to establish a
>> registry for these parameters (at least for Content-Type, so
>> that there is at least a stable reference that can be used by
>> a MUA that wants to handle the parts appropriately..
>> 
>> Any thoughts about the right place to do this work on e-mail
>> in the IETF?
>> 
>>         --dkg
>> 
>> PS to be clear, it is not the intent of this message to:
>> 
>>  - create any new document dependency that might block
>>    draft-ietf-lamps-protected-headers
>> 
>>  - define any new parameters for Content-Type
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch