Re: [Int-dir] Intdir last call review of draft-ietf-mediaman-toplevel-03

[Antoine FRESSANCOURT <[e-mail]>]

Hello Martin, 

Thanks for your answer. Please see some more detailed comments about your answers (beginning with [AFT]), but, as with the original comments I made, they are absolutely not major or blocking in any way in my perspective. 

[...]
> 
> I found the following minor issues, which I think SHOULD be clarified 
> before
> publication: - Section 1.1 is not clear about what are the issues with 
> the media type registration process described in RFC 6838. An hint 
> about an explanation is only given at the end of section 3 when the 
> author gives some details about the history. I think the background 
> section should better highlight what are the main issues with RFC 6838 
> before defining an updated registration procedure.

Actually, I think this is addressed just before Section 1.1, where the documents says:

 >>>>
RFC 6838 (Media Type Specifications and Registration Procedures), Section 4.2.7 only summarily gave criteria for defining additional top-level media types. This document provides more detailed criteria for defining additional top-level media types.
 >>>>

[AFT] My intention here was to get an intuition whether the lack of clarity of the criteria given in RFC 6838 has been an issue for a registration. Besides, the draft's text does not include the specific reference to Section 4.2.7. I think it is a good idea to add it as you did in this answer.

> - In section 2.1, the draft mentions that new top-level type MUST be 
> defined in a Standard Track RFC. This is a difference from section
> 3.1 in RFC 6838, which mentions that a media type can be registered 
> with a Standards Track, a BCP, an Informational or an Experimental 
> track document as soon as there is an IETF consensus, and I think it 
> should be highlighted more clearly.

BCP is still possible. Informational or Experimental don't need IETF consensus, and so they are not considered good enough for such a major thing as top-level types. There hasn't actually been any registration with the later two (not counting RFC 1437, which is an April Fool RFC), so I don't think there will be a big uproar like "I've always wanted to register this top-level type in an Informational RFC, and suddenly I can't.".

[AFT] Agreed, my point was just to stress that the current draft clarifies this point compared to RFC 6838.

> - This may be a layperson misunderstanding, but the draft does not 
> mention the concept of Registration trees introduced in section 3 of 
> RFC 6838, while I think some examples that justify the writing of the 
> current draft could have been addressed using a method described there.

standards/vendor/personal tree are now described at the start of 1. Introduction.

[AFT] Great, thanks.

> For instance, in section 3
> of the draft, the example of the undocumented use of the 'font' top 
> level type could have been adressed by having the actors using this 
> type use 'vnd.font' or 'x.font' instead to prove the point that this 
> top tier media type is useful while 'font' was documented in a draft 
> following the Standards track. I wonder why the author does not 
> encourage the use of a transitory faceted media type to accompany the registration of a new top-tier media type.

I don't think we want to tell people how to do things unofficially to then tell them how to do things officially.

[AFT] I am not encouraging people to do things unofficially, but, in some cases, people may want to test whether there is traction for a given top level type by experimenting using it under an experimental or vendor-specific top level type that implementations are not forced to understand before standardizing. My point was to express this possibility, and I think giving an explicit playground for experimental types would help.

> The following are minor issues (typos, misspelling, minor text improvements)
> with the document: - In section 3, on page 7, 'recommended' should be used
> rather than 'recommened' at the end of the penultimate paragraph of the section.

Thanks, good catch, fixed.

Many thanks again,    Martin.