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

[Lars Eggert via Datatracker <[e-mail]>]

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?

### IANA

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


----------------------------------------------------------------------
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?

### 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).

### 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.

### RFC2119 style

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

## 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.
+                                                    +
```

### 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).

### 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".

#### 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.

#### 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.

## 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