Re: [media-types] New draft-duerst-mediaman-toplevel-00.txt (was: Re: WG: Still need an editor....)

[Harald Alvestrand <[e-mail]>]

Thank you Martin!

This is a great starting point.

Do you have a github repo for the draft where we should track things 
using issues, or do you manage it by yourself?

Harald

On 3/6/22 11:04, Martin J. Dürst wrote:
> Hello Murray, Harald, others,
>
> For what it's worth, I managed to create and submit a first version of 
> the draft we spoke about. Below are the details. The draft is 
> currently just a collection of ideas and references to history. Any 
> comments appreciated!
>
> Regards,   Martin.
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
>         Title           : Guidelines for the Definition of New Top 
> Level Media Types
>         Author          : Martin J. Dürst
>     Filename        : draft-duerst-mediaman-toplevel-00.txt
>     Pages           : 7
>     Date            : 2022-03-06
>
> Abstract:
>    The goal of this document is to identify best practices for defining
>    new top-level media types.  It updates RFC 6838 [RFC6838], when
>    approved.  Comments and discussion about this document should be
>    directed to [e-mail], the mailing list of the Media Type
>    Maintenance (mediaman) WG.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-duerst-mediaman-toplevel/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-duerst-mediaman-toplevel-00.html
>
>
> On 2022-03-04 01:30, Murray S. Kucherawy wrote:
>> On Wed, Feb 23, 2022 at 6:20 PM Martin J. Dürst <[e-mail]>
>> wrote:
>>
>>> I have started working on such a draft, mostly on getting up to speed
>>> with the newest version of xml2rfc and related tooling.
>>>
>>> When I started looking for status, update relationships, and references
>>> that I might have to include, I found
>>> https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.7, which 
>>> says:
>>>
>>> 4.2.7.  Additional Top-Level Types
>>>
>>>      In some cases, a new media type may not "fit" under any currently
>>>      defined top-level type names.  Such cases are expected to be quite
>>>      rare.  However, if such a case does arise, a new type name can be
>>>      defined to accommodate it.  Definition of a new top-level type 
>>> name
>>>      MUST be done via a Standards Track RFC; no other mechanism can be
>>>      used to define additional type names.
>>>
>>> If you compare this text with what Harald and I wrote above and below,
>>> there's really not much (if indeed anything) that isn't already said.
>>>
>>> So before I continue working on this draft (which I can do this
>>> weekend), I really want to make sure that we need such a draft.
>>>
>>
>> Hi Martin, thanks for taking this up.
>>
>> RFC 6838 Sections 4.2.5 and 4.2.7 are mushy in that the former says we
>> should use "application" as the top-level type for anything that doesn't
>> clearly fit into some other top-level type, while the latter says you 
>> can
>> also make new top-level types in the rare case that it's necessary.  
>> When
>> the "haptics" application appeared, the community had that 
>> discussion, and
>> it was noted that there's little guidance (only what you cited) about 
>> when
>> one should do one or the other.  The only other example is RFC 8081, 
>> where
>> a top-level type was indeed registered.
>>
>> What I think we were hoping for is an update to RFC 6838 that 
>> provides some
>> consensus guidance about (a) when it's appropriate to make a new 
>> top-level
>> type versus using "application" (and/or maybe some examples of when 
>> doing
>> so is not appropriate); and (b) what a document declaring a new 
>> top-level
>> type should be required to contain.  It's fine to use RFC 8081 as a 
>> model
>> if people think that worked out well, or well enough to serve as a basis
>> for something going forward.
>>
>> -MSK
>>
>