Skip to main content

Guidelines for the Definition of New Top-Level Media Types
draft-ietf-mediaman-toplevel-05

Yes

Murray Kucherawy
Orie Steele

No Objection

Erik Kline
Gunter Van de Velde
Jim Guichard
(Andrew Alston)
(Martin Duke)

Abstain


No Record

Deb Cooley
Warren Kumari

Note: This ballot was opened for revision 03 and is now closed.

Murray Kucherawy
Yes
Orie Steele
Yes
Paul Wouters
(was Discuss) Yes
Comment (2024-02-25 for -04) Sent
Thanks for addressing my concerns and clarifying the document. I updated my ballot to Yes.
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment (2024-04-15) Sent for earlier
Thank you for the work on this document.

Thank you for addressing my comment.
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2023-09-18 for -03) Sent
Thanks for this document!

I support Paul Wouters’ DISCUSS. Generally, the IANA Considerations section is a little less comprehensive than I’m used to seeing, but I guess the sponsoring AD and IANA will be able to work with the authors if they think changes are needed. 

Also, to elaborate on one of Paul’s points, it seems to me all the SHOULD in “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” are misplaced. They SHOULD be “should”. 

Finally, a nit: In Section 3, you don’t want “shortly describes” but “briefly describes”.
Mahesh Jethanandani
No Objection
Comment (2024-04-17) Sent
No reference entries found for these items, which were mentioned in the text:
[draft-ietf-mediaman-haptics] and [draft-duerst-mediaman-toplevel-00].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

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.

Uncited references: [RFC8126].

Reference [RFC2048] to RFC2048, which was obsoleted by RFC4289 and RFC4288
(this may be on purpose).

Reference [RFC1341] to RFC1341, which was obsoleted by RFC1521 (this may be on
purpose).
Roman Danyliw
No Objection
Comment (2023-09-18 for -03) Sent
** Section 1.1
   The main function of media types and subtypes is the dispatch of data
   formats to application code.  In most cases, this requires and is
   done using the full type (i.e. including the subtype, and often some
   parameters).  The top-level type can occasionally serve as a fallback
   for the tentative dispatch to applications handling a very wide range
   of related formats.

Consider reminding the reader to make assumptions about correctness of the media type related to the presented content cautiously as one or both could be under the control of an attacker (all of course depending on the circumstances of the application).

** Typos
-- Section 1.  Typo. s/detailled/detailed.

-- Section 2.1.  Typo. s/approriate/appropriate/

-- Section 2.2.  Typo. s/understading/understanding/
Zaheduzzaman Sarker
No Objection
Comment (2023-09-20 for -03) Sent
Thanks for working on this specification. I think the additional considerations will be useful.

In my review I have no TSV related issues (obviously :-) ). However, I think the IANA consideration section should say the registry policy is "RFC required" with "standard track" specification and point to (https://www.rfc-editor.org/rfc/rfc8126.html#section-4.7). Even though it puts a requirement saying - "Every new top-level type MUST be defined in a Standards Track RFC", I don't think it hurts repeating it in IANA consideration.
Éric Vyncke
No Objection
Comment (2024-04-16) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-mediaman-toplevel-05

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Harald Alvestrand for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

Other thanks to Antoine Fressancourt, the Internet directorate reviewer, please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-mediaman-toplevel-03-intdir-lc-fressancourt-2023-09-05/ (and I have read a start of the discussion)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

Probably due to my ignorance on the topic, but in `the right of the slash with a prefix of '.../vnd.` can there be a '/' in the '...' ?

## Section 1.1

Section 1 was about `top-level media types` and now this section is about `top-level types`, they are probably the same concept, but may I suggest introducing the shorthand equivalent ?

I am afraid that I cannot identify the scenarii in `In some older scenarios,` 

## Section 2.1

I would expect a BCP document to clearly (punt intended) specify how `clearly` is evaluated in this section. E.g., is IETF consensus on the clarity enough ? See also Lars Eggert's ballot.

Unsure about the usefulness of `Please note that the 'example' top-level describes a subtype 'example'.`

## Section 2.2

`Existing wide use of an undefined top-level type` what is an "undefined top-level type" ? One that is not IANA registered ? Please be explicit.

## Section 2.3

Please expand `RDF`.

## Section 3

An interesting read but suggest moving this section in the introduction or in the appendix.
Deb Cooley
No Record
Warren Kumari
No Record
Andrew Alston Former IESG member
No Objection
No Objection (2023-09-21 for -03) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (for -03) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2023-09-19 for -03) Sent
Thanks for this document.  I think that this is the right approach.  One minor comment is that I concur with some other ADs comments that the RFC 2119 language feels a bit out of place in the requirements, and much, perhaps all of it might be better stated in regular English.

Regards,
Rob
Lars Eggert Former IESG member
(was Discuss, No Objection, Discuss) Abstain
Abstain (2024-03-18) Sent for earlier
I believe the guidance this document intends to give is useful. I do not believe the guidance is presented in a way that is actionable enough for a BCP.