Hello Antoine, others,
Many thanks for your very helpful comments. Sorry for the delay in
answering them. I just posted
https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-toplevel-05.
Please check the changes I made to address your comments with
https://author-tools.ietf.org/iddiff?url1=draft-ietf-mediaman-toplevel-03&url2=draft-ietf-mediaman-toplevel-05&difftype=--html
Please see below for some additional comments.
On 2023-09-05 21:10, Antoine Fressancourt via Datatracker wrote:
Reviewer: Antoine Fressancourt
Review result: Ready with Issues
I am an assigned INT directorate reviewer for
draft-ietf-mediaman-toplevel-03.txt. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and shepherd(s)
should treat these comments just like they would treat comments from any other
IETF contributors and resolve them along with any other Last Call comments that
have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.
Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.
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.
>>>>
- 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.".
- 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.
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.
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
