Ballot for draft-ietf-mediaman-toplevel
Yes
No Objection
Abstain
No Record
Note: This ballot was opened for revision 03 and is now closed.
Thanks for addressing my concerns and clarifying the document. I updated my ballot to Yes.
Thank you for the work on this document. Thank you for addressing my comment.
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”.
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).
** 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/
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, 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.
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
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.