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

[John C Klensin <[e-mail]>]

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.

(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