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

["Martin J. Dürst" <[e-mail]>]

Hello Lars,

Many thanks for your comments. Sorry for the very late reply.

On 2023-09-20 22:15, Lars Eggert via Datatracker wrote:
> Lars Eggert 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:
> ----------------------------------------------------------------------
> 
> # GEN AD review of draft-ietf-mediaman-toplevel-03
> 
> CC @larseggert
> 
> ## Discuss
> 
> ### Section 2, paragraph 1
> ```
>    2.  Rules for the Registration of New Top-Level Media Types
> ```
> These aren't really rules or a best current practice. At best, this is
> an assembly of considerations around top-level media types one may
> want to think about. I had expected much more practical prescriptive
> rules that someone considering a new top-level media type can
> follow. Could these be tightened up?

I changed the title to "Rules and Criteria" (implemented with 
https://github.com/ietf-wg-mediaman/toplevel/commit/03970e3571e7). I 
agree that tighter rules would have been better. But we tried, and we 
didn't find anything tighter. This is because this is a very high-level 
subject, where human judgement, intuition, and experience get involved.
If you have any ideas for additional rules or criteria, we would 
certainly welcome that.

> ### IANA
> 
> This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
> so we can determine next steps during the telechat.

These should be addressed by now, see separate mails.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ## Comments
> 
> ### Section 2, paragraph 1
> ```
>       This section describes the rules and criteria for new top-level media
>       types, including criteria already defined in RFC 6838 (Media Type
>       Specifications and Registration Procedures).  Further work is needed
>       to distinguish between required and optional criteria.
> ```
> "Further work is needed" - is this a leftover editing note that should
>   be removed? If not, where is this work happening and why are we
>   publishing this now?

Sorry, yes, this is a leftover. Removed with
https://github.com/ietf-wg-mediaman/toplevel/commit/b5374999c406.

> ### Section 2.1, paragraph 0
> ```
>    2.1.  Required Criteria
> ```
> If they are "required", why are many of them SHOULDs?
> 
> ### Section 2.1, paragraph 6
> ```
>       *  The registration and actual use of a certain number of subtypes
>          under the new top-level type SHOULD be expected.  At a minimum,
>          one actual subtype SHOULD exist.  But the existence of a single
>          subtype SHOULD not be enough; it SHOULD be clear that new similar
>          types may appear in the future.  Otherwise, the creation of a new
>          top-level type is most probably not justified.
> ```
> This use of RFC2119-language is IMO a bit iffy. The second SHOULD
> ("SHOULD exist") should IMO be a MUST, and all the other SHOULDs
> should be lowercase, because they are not enforceable
> (like the "should" in the last list item).

Changed to "should" throughout. They are "should", and not "must", 
because the example top-level type is an example of a type without subtypes.

> ### Section 3, paragraph 4
> ```
>       The first time an additional top-level type was defined was in RFC
>       1437 [RFC1437], but this was purely for entertainment purposes
>       (please check date).
> ```
> "Please check date"? Just say that it was an April Fools RFC and not a
>   standard.

Done with https://github.com/ietf-wg-mediaman/toplevel/commit/6edca14e1c21.

> ### RFC2119 style
> 
> Using lowercase "not" together with an uppercase RFC2119 keyword is not
> acceptable usage. Found: "SHOULD not"

Seems to have fixed already.

> ## Nits
> 
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> ### Typos
> 
> #### Section 1, paragraph 1
> ```
> -    level media types.  This document provides more detailled criteria
> -                                                          -
> ```
> 
> #### Section 2.1, paragraph 4
> ```
> -       template for a subtype contains the approriate information.  If
> +       template for a subtype contains the appropriate information.  If
> +                                                +
> ```
> 
> #### Section 2.2, paragraph 5
> ```
> -    *  Top-level types can help humans with understading and debugging.
> +    *  Top-level types can help humans with understanding and debugging.
> +                                                    +
> ```

Fixed with
https://github.com/ietf-wg-mediaman/toplevel/commit/4fdf2f95fd95

> ### Outdated references
> 
> Reference `[RFC1341]` to `RFC1341`, which was obsoleted by `RFC1521` (this may
> be on purpose).
> 
> Reference `[RFC2048]` to `RFC2048`, which was obsoleted by `RFC4288` and
> `RFC4289` (this may be on purpose).

Yes, these are historical references.

> ### Grammar/style
> 
> #### "Abstract", paragraph 2
> ```
> rnatively, issues can be raised on github at https://github.com/ietf-wg-medi
>                                     ^^^^^^
> ```
> The official name of this software platform is spelled with a capital "H".

That paragraph will be removed by the RFC Editor anyway.

> #### Section 1.1, paragraph 2
> ```
>   landscape, where computers and smart phones can handle a very wide variety
>                                  ^^^^^^^^^^^^
> ```
> Nowadays, it's more common to write this as one word.

Fixed with
https://github.com/ietf-wg-mediaman/toplevel/commit/bd85b9c4e15f

> #### Section 2.1, paragraph 5
> ```
> he new top-level type, will allow to check the appropriateness of the defini
>                                    ^^^^^^^^
> ```
> Did you mean "checking"? Or maybe you should add a pronoun? In active voice,
> "allow" + "to" takes an object, usually a pronoun.

Fixed with
https://github.com/ietf-wg-mediaman/toplevel/commit/83076c42aca0

Regards,   Martin.

> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>