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

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

--On Wednesday, April 26, 2023 10:28 +0100 Alexey Melnikov
<[e-mail]> wrote:

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

Alexey,

Three things:

(1) When I said "especially top-level content-types", I had
multipart/ and maybe text/ in mind.   "boundary=" was
definitely, and, IIR, quite explicitly, bound to multipart and
not any of its specific subtypes.  The intent was that, even if
a processor did not recognize the subtype, there was a default
handling for all multipart/ types.  Presumably, there would be
no multipart/ types that did not support/use "boundary".  The
relationship to text/ was, IIR, not assumed to be quite as
strong, but a similar relationship applied there too.

(2) My concern is that we don't accidentally stumble into a
place where we don't want to go.  Using "charset" and "boundary"
as examples, they, and their definitions, are bound to top-level
types, described in standards track documents, and very heavily
used.  For "charset", there is even an existing registry of
values.  But, especially when MEDIAMAN is considering mechanisms
for defining new top-level types, I don't think we want to
accidentally define "foo=" in such a way that it is required (or
assumed) to have the same meaning when used with zorgle/fraz as
when it is used with bong/bing.

(3) As I think I said earlier, we certainly should not be bound
by decisions that are three decades old.  On the other hand, we
should be aware that these were design decisions then, not just
accidents, and should make changes only with equally careful
thought.

I'm not opposed to having a registry but, unless we are going to
risk creating confusion where the intent was to avoid/reduce it,
it is going to have to be carefully designed.  It might be
structured to bind parameter names to top-level types rather
than assuming they apply across types, or in some other way...
if nothing else to avoid conflicts with semi-public top-level
types whose creators might not pay attention to a registry even
if one existed.  

And, as discussed in the context of some recent notes about
draft-diaz-lzip, we seem to be headed toward having essentially
the same information transmitted in the base subtype name, in
parameters, and in structured suffixes.  If that is going to be
the practice, it would probably be good to document some best
(or at least good) practices as to which to use and under what
circumstances.  In the case of lzip and things similar to it,
that may also require looking at the relationship between
Content-type and Content-transfer-encoding.  

Let's keep the overall system in mind and be conscious of where
particular decisions might take us if made in isolation.

    john