Hi Martin, Apologies for the oversight. The document has been updated and is available for review here: https://www.rfc-editor.org/authors/rfc9694.xml https://www.rfc-editor.org/authors/rfc9694.txt https://www.rfc-editor.org/authors/rfc9694.pdf https://www.rfc-editor.org/authors/rfc9694.html
Diffs of the most recent updates only: https://www.rfc-editor.org/authors/rfc9694-lastdiff.html https://www.rfc-editor.org/authors/rfc9694-lastrfcdiff.html (side by side) AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9694-auth48diff.html https://www.rfc-editor.org/authors/rfc9694-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9694-diff.html https://www.rfc-editor.org/authors/rfc9694-rfcdiff.html (side by side) Regarding the change with the subject "split up long sentence into three shorter sentences” <https://github.com/ietf-wg-mediaman/toplevel/commit/b0503dd0f3932d52d258d7a9d2355c09072542dd>, is the last sentence part of the example? Perhaps it should be connected to the second sentence? Current: For example, 'x- scheme-handler/http' should be changed to something like 'application/scheme-handler; scheme=http'. The type 'inode/ directory' should be changed to 'multipart/inode-directory' or 'application/inode-directory. Perhaps: For example, 'x- scheme-handler/http' should be changed to something like 'application/scheme-handler; scheme=http’, and the type 'inode/ directory' should be changed to 'multipart/inode-directory' or 'application/inode-directory. Thanks, RFC Editor/sg > On Mar 4, 2025, at 2:18 PM, Martin J. Dürst <due...@it.aoyama.ac.jp> wrote: > > Hello Sandy, > > Sorry that I forgot to say this in my last mail, but please add a reference > for RDF. Thanks! > > Regards, Martin. > > On 2025-03-04 16:54, Martin J. Dürst wrote: >> Hello Sandy, >> Many thanks for your work! I have looked at the diffs below. It looks to me >> as if the comments in my mail were applied to the documents, but the changes >> that I made in the XML I sent, and which are listed as changes at >> https://github.com/ietf-wg-mediaman/toplevel/commits/main/draft-ietf-mediaman-toplevel.xml, >> have not been integrated. >> Can you please cross-check? >> Regards, Martin. >> On 2025-03-04 06:03, Sandy Ginoza wrote: >>> Hi Martin, >>> >>> Thank you for your close review and for the updated XML. We have >>> incorporated the document based on the replies below. The current files >>> are available here: >>> https://www.rfc-editor.org/authors/rfc9694.xml >>> https://www.rfc-editor.org/authors/rfc9694.txt >>> https://www.rfc-editor.org/authors/rfc9694.pdf >>> https://www.rfc-editor.org/authors/rfc9694.html >>> >>> AUTH48 diffs: >>> https://www.rfc-editor.org/authors/rfc9694-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9694-auth48rfcdiff.html (side by >>> side) >>> >>> Comprehensive diffs: >>> https://www.rfc-editor.org/authors/rfc9694-diff.html >>> https://www.rfc-editor.org/authors/rfc9694-rfcdiff.html (side by side) >>> >>> >>> Please note the following: >>> >>> A) >>>> One additional question: In section 2.3, the document mentions "RDF >>>> (Resource Description Framework)". Does this need a citation, or can >>>> people look it up? >>> >>> >>> [rfced] In looking at other RFCs that mention RDF, some include a reference >>> and some don’t. We see a reference to the following in RFC 9290. Would >>> you like to include an informative reference? >>> >>> [RDF] Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1 Concepts and >>> Abstract Syntax", W3C Recommendation, 25 February 2014, >>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/>. >>> >>> >>> B) >>>> It seems difficult or impossible to provide direct links from the table >>>> entries in the RFC to the individual registries, both because IANA cannot >>>> guarantee the stability of links to individual registries as well as >>>> because these links would be too long. I propose that we don't use links >>>> at all. As long as it is clear to IANA that they should provide links in >>>> their table (which they already do) and the readers of the RFC have a >>>> pointer to https://www.iana.org/assignments/top-level-media-types close >>>> before or after the table, things should be fine. >>> >>> [rfced] We confirmed with IANA that individual registry links should not >>> appear in the RFC. We left the registry names in the table, but we did not >>> include direct links. We added links to the registries where they are >>> first mentioned within the section. Please review and let us know if any >>> changes are needed. >>> >>> >>> Thank you, >>> RFC Editor/sg >>> >>> >>> >>> >>> >>> >>> On Feb 28, 2025, at 11:07 PM, Martin J. Dürst <due...@it.aoyama.ac.jp> >>> wrote: >>>> >>>> Dear RFC Editors, >>>> >>>> First, I'm very sorry for the long delay in answering you. I should have >>>> more time over the next days and weeks, so that we hopefully can complete >>>> this soon. >>>> >>>> I have reviewed the diff at >>>> https://www.rfc-editor.org/authors/rfc9694-rfcdiff.html. >>>> Most of the changes are okay, but some need additional tweaks. >>>> >>>> I'm attaching an updated xml file including these tweaks. These tweaks are >>>> also visible on github as individual commits, please see >>>> https://github.com/ietf-wg-mediaman/toplevel/commits/main/draft-ietf-mediaman-toplevel.xml >>>> (all commits are on March 1 (or February 28 in your location, depending >>>> on where you are and how github deals with timezones)). >>>> >>>> One additional question: In section 2.3, the document mentions "RDF >>>> (Resource Description Framework)". Does this need a citation, or can >>>> people look it up? >>>> >>>> The rest of this mail contains answers to your comments, in some cases >>>> with new proposals for text. Except where mentioned, these new proposals >>>> are not yet integrated into the attached xml. Please integrate them unless >>>> you see problems, or tell me to integrate them. >>>> >>>> Regards, Martin. >>>> >>>> >>>> On 2024-12-24 16:07, 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 >>>>> --> >>>> >>>> Yes, I think this is correct. >>>> >>>>> 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. >>>>> --> >>>> >>>> That should be okay. >>>> >>>> >>>>> 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. >>>>> --> >>>> >>>> "wider community" refers to the community that is using documents that >>>> would fall under the new top-level type (if that top-level type is >>>> approved). I think this will be clear to the reader. If you think it is >>>> not clear enough, I propose to change "wider community" to "wider user >>>> community". >>>> >>>> >>>>> 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. >>>>> --> >>>> >>>> Your proposal looks fine to me. >>>> >>>> >>>>> 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. >>>>> --> >>>> >>>> Your edit points in the right direction. However, I think it would be good >>>> if we expanded this as follows: >>>> >>>> RFC 9695 [RFC9695] defines a new 'haptics' top-level type. RFC 9695 and >>>> this document were developed in parallel, and RFC 9695 was used to >>>> cross-check the considerations and procedures defined in this document. >>>> >>>>> 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>. >>>>> --> >>>> >>>> Your proposed change looks good to me. >>>> >>>> >>>>> 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. >>>>> --> >>>> >>>> In general, this looks good. However, I'd really want to keep the comma >>>> before the "and", because otherwise, it's way too easy to read "document" >>>> as a noun and get stuck. Also, we don't envision that many >>>> new top-level registrations, so I think singular works better. >>>> The resulting changes are in the attached xml file, please cross-check. >>>> >>>> >>>>> 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. >>>>> --> >>>> >>>> This should be fine. >>>> >>>>> 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. >>>>> --> >>>> >>>> It seems difficult or impossible to provide direct links from the table >>>> entries in the RFC to the individual registries, both because IANA cannot >>>> guarantee the stability of links to individual registries as well as >>>> because these links would be too long. I propose that we don't use links >>>> at all. As long as it is clear to IANA that they should provide links in >>>> their table (which they already do) and the readers of the RFC have a >>>> pointer to https://www.iana.org/assignments/top-level-media-types close >>>> before or after the table, things should be fine. >>>> >>>> >>>>> 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. >>>>> --> >>>> >>>> Most probably, this is easier to understand: >>>> >>>> This document itself 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 >>>> >>>> -- >>>> Prof. Dr.sc. Martin J. Dürst >>>> Department of Intelligent Information Technology >>>> College of Science and Engineering >>>> Aoyama Gakuin University >>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara >>>> 252-5258 Japan<draft-ietf-mediaman-toplevel.xml> >>> > > -- > Prof. Dr.sc. Martin J. Dürst > Department of Intelligent Information Technology > College of Science and Engineering > Aoyama Gakuin University > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > 252-5258 Japan -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
