Martin, We do not believe we have heard from you regarding the questions below. Please let us know how we may resolve the items listed below.
Thank you, RFC Editor/sg > On Dec 23, 2024, at 11:07 PM, rfc-edi...@rfc-editor.org wrote: > > Martin, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] This document updates RFC 6838, which is part of BCP 13. > Please note that we have marked this RFC as being part of BCP 13 as well. > Please verify that this is correct (i.e., please verify that it should > not be part of another existing BCP and that a new BCP number is not needed). > > > For more info about BCP 13, see > https://www.rfc-editor.org/info/bcp13 > > In addition, a complete list of current BCPs is available here: > https://www.rfc-editor.org/bcps > --> > > > 2) <!-- [rfced] Martin, we have removed "J." from the document header > (it remains in the authors' addresses section) to match what appears > in your published RFCs. Please let us know if you prefer otherwise. > --> > > > 3) <!-- [rfced] Does "wider community" refer to the IETF Community, as > these top-level types can only be introduced via Standards Action? Or, > does this mean the community interested in using the new top-level type? > Will this be clear to the reader? > > Original: > * The proposers of the new top-level type and the wider community > should be willing to commit to emitting and consuming the new top- > level type in environments that they control. > --> > > > 4) <!-- [rfced] For readability, we suggest the following update. > Please let us know if this is acceptable. > > Original: > The first time an additional top-level type was defined was in RFC > 1437 [RFC1437], but this was an April Fools RFC, purely for > entertainment purposes. > > Perhaps: > RFC 1437 [RFC1437] defined the first additional top-level type; however, > it was not registered because RFC 1437 is an April Fools RFC that was > published purely for entertainment purposes. > > --> > > > 5) <!-- [rfced] As draft-ietf-mediaman-haptics will be published at the > same time as this document, should this text be updated as follows? > > Original: > There is ongoing work on defining a new 'haptics' top-level type in > draft-ietf-mediaman-haptics [HAPTICS]. > > Perhaps: > RFC 9695 [RFC9695] defines a new 'haptics' top-level type. > --> > > > 6) <!-- [rfced] For clarity, may we update this text and add an informative > reference for the wikipedia page to > https://en.wikipedia.org/wiki/Chemical_file_format? > > Original: > Wikipedia (at https://en.wikipedia.org/wiki/Chemical_file_format) > reports the unofficial use of a 'chemical' top-level type. This top- > level type was proposed by Peter Murray-Rust and Henry Rzepa at a > workshop at the First WWW conference in May 1994 CHEMIME [CHEMIME]. > It is in widespread use, but remains unregistered. > > Perhaps: > The "Chemical file format" Wikipedia page [CHEMICAL] > reports the unofficial use of a 'chemical' top-level type. This top- > level type was proposed by Peter Murray-Rust and Henry Rzepa at a > workshop at the First WWW conference in May 1994 CHEMIME [CHEMIME]. > It is in widespread use, but remains unregistered. > > [CHEMICAL] Wikipedia, "Chemical file format", 19 July 2024, > <https://en.wikipedia.org/w/ > index.php?title=Chemical_file_format&oldid=1235421631>. > --> > > > 7) <!-- [rfced] We have changed "They have" to "The defining specifications", > as it's the document (as opposed to the registration) that will have the IANA > Considerations and Security Considerations. Please review and let us know if > updates are needed. > > Original (the first sentence is provided for context): > Registrations of new top-level types have to provide the name of the > top-level type, the defining specification (RFC, or the respective > draft during the approval process), and, if applicable, some > comments. They have to contain a "IANA Considerations" section > requesting addition to the registry of top-level media types, and > have to document security considerations for the top-level types they > register. > > Current: > The defining specifications have to contain an "IANA > Considerations" section requesting addition to the registry of top- > level media types and document security considerations for the top- > level types they register. > --> > > > 8) <!-- [rfced] The following text has been removed as directives to IANA. > We note that IANA has created a new registry for Top-Level Media Types (see > https://www.iana.org/assignments/top-level-media-types/top-level-media-types.xhtml) > > and have added a pointer to the Top-Level Media Types from the Media > Types registry. > > This should be done by expanding the "Registries included below" > section > of https://www.iana.org/assignments/media-types/media-types.xhtml > (assuming this is compatible with IANA infrastructure; if not, then > there should be at least a pointer from that page to this new > registry). > > Note that IANA provided this information related to the registry: > NOTE: the first paragraph of Section 4.2 will have to be adjusted. > For architectural reasons related to iana.org/protocols, we were > unable to place the new Top-Level Media Types registry at > https://www.iana.org/assignments/media-types. > > Please let us know if any corrections are needed. > --> > > > 9) <!-- [rfced] Currently, instances of "[pointer to be added by IANA]" > in table 1 have been updated to match the text that appears in the > IANA registry. However, we are experimenting with how these should be > linked as using <eref> to link to the registries causes the table to > extend beyond the 69-character limit in the text output, and forcing a > break within <eref> causes the links to break. > > Notes: > - The links go to the registry group, rather than individual registries. > Per IANA, they prefer that links be to the registry group (see "Other > considerations" on https://www.iana.org/help/protocol-registration for > more details). > > - We will continue to seek a solution while you review the other updates > to the RFC. Please let us know if you have a suggestion regarding how > the table could be updated. > --> > > > 10) <!-- [rfced] To what does "as such" refer? Is there text missing? > > Original: > 5. Security Considerations > > This document as such is not expected to introduce any security > issues. > > --> > > > 11) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> > > > Thank you. > > RFC Editor > > On Dec 23, 2024, at 10:58 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2024/12/23 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9694.xml > https://www.rfc-editor.org/authors/rfc9694.html > https://www.rfc-editor.org/authors/rfc9694.pdf > https://www.rfc-editor.org/authors/rfc9694.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9694-diff.html > https://www.rfc-editor.org/authors/rfc9694-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9694-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9694 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9694 (draft-ietf-mediaman-toplevel-06) > > Title : Guidelines for the Definition of New Top-Level Media Types > Author(s) : M. Dürst > WG Chair(s) : Harald T. Alvestrand > Area Director(s) : Murray Kucherawy, Orie Steele > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
