Re: [media-types] Paul Wouters' Discuss on draft-ietf-mediaman-toplevel-03: (with DISCUSS and COMMENT)

["Martin J. Dürst" <[e-mail]>]

Hello Paul, others,

On 2023-09-19 03:23, Harald Alvestrand wrote:
> Thanks for the review!
> 
> It seeems that the document is not quite clear enough on what a top 
> level type is, or how it's currently managed - suggestions for better 
> language to clear up the misunderstandings would be appreciated.

I have added some explanatory language with
https://github.com/ietf-wg-mediaman/toplevel/commit/b6591724fb29.
Hope this is enough (and not too much).

> Detailed comments below.
> 
> On 9/18/23 18:54, Paul Wouters via Datatracker wrote:
>> Paul Wouters has entered the following ballot position for
>> draft-ietf-mediaman-toplevel-03: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to 
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-mediaman-toplevel/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>          Every new top-level type MUST be defined in a Standards Track 
>> RFC.
>>
>> This is a bit of an odd thing to say, esp. for a BCP document? Should 
>> there
>> be a Standards Track policy that updates an IANA Registration policy to
>> be Standards Track for the top-level IANA Registry?
> 
> This document does not change RFC 6838 - the current policy is 
> "standards track", as specified in 
> https://www.rfc-editor.org/rfc/rfc6838#section-4.2.7

I explicitly mentioned section 4.2.7, done at
https://github.com/ietf-wg-mediaman/toplevel/commit/b6591724fb29.

>> If I look at
>> https://www.iana.org/assignments/media-types/media-types.xhtml
>> I see no such split in the Registry. It states "Expert Review for 
>> Vendor and
>> Personal Trees", leaving the top level registration policy undefined.

You do not see a split in the registry because the part of the registry 
that would be split off (the one for top-level types) doesn't yet exist. 
We are fixing this with this document.


> I think we may have failed to explain the difference between "toplevel" 
> and "trees" - not so strange, since this document does not deal with 
> "trees" at all.
> 
> Trees are strictly a construct at the right hand side of the MIME type 
> (after the slash) - all second level types start with vnd., prs. or 
> "nothing", if "nothing", we call it the "standards tree.
> 
> The toplevel type is what occurs to the left of the slash.

As said above, an explanation has been added with
https://github.com/ietf-wg-mediaman/toplevel/commit/b6591724fb29.

>> It would be odd if this BCP document would update the registration policy
>> for this registry at the top level. It is also odd that this document, as
>> a BCP, DOES in fact create a new Registry for the top level 
>> registrations,
>> but does not clearly set a registration policy.
> 
> The registration policy is "standards track required", as you described 
> above.
> 
>>
>> Additionally, I cannot find a definition of "standards tree" in 6838 
>> or this
>> document? Are some of the "top levels" in the IANA registree "standard" ?
> 
> The definition of the "standards tree" is in 
> https://www.rfc-editor.org/rfc/rfc6838#section-3.1 - this document does 
> not touch tis.

The concept of top-level types and of trees are essentially orthogonal.

>>
>>          At a minimum, one actual subtype SHOULD exist. But the existence
>>          of a single subtype SHOULD not be enough;
>>
>> Who are these SHOULDs directed at?
> 
> People who wish to register a new top level type.

Does anybody think this needs to be spelled out more clearly?

>>          The document defining the new top-level type MUST include 
>> initial
>>          registrations of actual subtypes.
>>
>> This MUST and the previous SHOULD's contradict each other.
> 
> Agree that the first SHOULD should be a MUST.

I'm not so sure. In general, MUST makes sense, but there's the example 
of the 'example/' (sic!) top level type, which on purpose doesn't have 
any subtypes. We may not want to rule out another similar top-level type.

So for the moment, I'm aligning this to SHOULD, but I'm ready to follow 
additional instructions.

(done with https://github.com/ietf-wg-mediaman/toplevel/commit/6f6cb9b85925)

Regards,   Martin.

>> It also seems these are directives towards the Delegated Experts, so 
>> perhaps
>> these do not need 2119 style wording?
> 
> They are directed at the people writing definition documents for new top 
> level types, such as the "haptics" type that is also under balloting.
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> This document references RFC6838 that states:
>>
>>          The media types reviewer, who is appointed by the
>>          IETF Applications Area Director(s)
>>
>> But there is no "Applications" Area anymore. Should this document
>> mention the new appropriate (ART ?) Area as an update? Or Whatever
>> the Area is called at time of publication :P
> 
> This document does not change anything about the Media Types reviewer, 
> so we wouldn't want to touch that text. It's for the IESG to decide what 
> the successor area of the Applications Area is - likely the IESG should 
> file its opinion on that as an errata on RFC 6838.
> 
> The WG is considering whether we should merge all the changes we're 
> contemplating in an RFC 6838 update; if we do, that's a natural thing to 
> include - but at the current pace of this WG, that's some time away.
> 
>>
>>
>>
>