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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
