Just chming in as MEDIAMAN chair here.
On 3/4/24 06:18, Antoine FRESSANCOURT
wrote:
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.
The basic problem with the registration procedure in RFC 6838 and predecessors was that there wasn't none. So every time the question of a new top level type came up, we had to reinvent a process.
That's why the MEDIAMAN WG was chartered.
I don't think this needs elaborating.
- 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.
The requirement in https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.7 says that
"
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. " Experimental or Informational has never been allowed for top level types. This is not changed, and since there is no change, no stress of the change is needed.
- 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.
This is a historical note. Not an example to be followed.
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
