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

[Harald Alvestrand <[e-mail]>]

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.

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

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

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.


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

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

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

> 
> 
>