Hi Martin, Thanks for your quick reply. We will continue with publication shortly!
Sandy > On Mar 16, 2025, at 4:38 PM, Martin J. Dürst <due...@it.aoyama.ac.jp> wrote: > > Hello Sandy, > > Many thanks for your quick answer! It looks like you also enjoy working in > Bangkok. I really didn't expect an answer over the weekend. I'm glad I don't > have to let you and others wait anymore, and want to thank everybody again > for their continued patience and occasional reminders. > > Regards, Martin. > > On 2025-03-17 00:05, Sandy Ginoza wrote: >> Hi Martin, >> Thanks Martin, I am definitely enjoying Bangkok. I hope you are finding >> some relief after your busy season! >> We have updated the document so your name appears as it was in the >> Internet-Draft. With this update, we believe you approve the RFC for >> publication, so we have noted your approval on the AUTH48 page. We will >> continue with publication shortly. >> Note that the 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 >> Diffs highlighting the most recent update 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) >> Thanks Martin! >> RFC Editor/sg >>> On Mar 16, 2025, at 3:44 AM, Martin J. Dürst <due...@it.aoyama.ac.jp> wrote: >>> >>> Hello Sandy, >>> >>> Really sorry for the repeated delay. I hope you have a very productive and >>> nice time in Bangkok (if you are there) or elsewhere! >>> >>> I have read the PDF version from front to back, and see no problems. >>> However, I have one "last wish". I earlier told you that I'd be fine with >>> keeping my name without middle initial, to align with the RFCs where I was >>> author previously. However, when I read the PDF version, I suddenly >>> realized that the name wouldn't be the same anyway: In all the previous >>> RFCs, it was "Martin Duerst", now it would be "Martin Dürst". Once I >>> realized that, I got to the conclusion that in that case, we can make it >>> "Martin J. Dürst" as well, with would align with my other publication. >>> >>> I'm sorry about this very late change of opinion. >>> >>> Regards, Martin. >>> >>> On 2025-03-12 01:16, Sandy Ginoza wrote: >>>> Hi Martin, >>>> Thank you for your review. We agree with your suggestions and have >>>> updated the document accordingly. Please review and let us know if any >>>> additional updates are needed or if you approve the RFC for publication. >>>> The 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 >>>> Diffs highlighting 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 diff: >>>> 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) >>>> We will wait to hear from you before continuing with the publication >>>> process. >>>> Thank you, >>>> RFC Editor/sg >>>>> On Mar 10, 2025, at 10:22 PM, Martin J. Dürst <due...@it.aoyama.ac.jp> >>>>> wrote: >>>>> >>>>> Hello Sandy, >>>>> >>>>> Apologies for the delay in answering you. I think we are very close to >>>>> done, but please see two issues below. >>>>> >>>>> On 2025-03-05 09:56, Sandy Ginoza wrote: >>>>>> 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? >>>>> >>>>> The last sentence isn't part of the example, it's another 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. >>>>> >>>>> What about: >>>>> >>>>> As an example, 'x-scheme-handler/http' should be changed to >>>>> something like 'application/scheme-handler; scheme=http’. >>>>> As another example, the type 'inode/directory' should be >>>>> changed to 'multipart/inode-directory' or >>>>> 'application/inode-directory. >>>>> >>>>> What do you think? >>>>> >>>>> A second issue: Section 4.2, Initialization of the Registry of Top-Level >>>>> Media Types, mentions pointers to this registry from IANA pages both in >>>>> the first and in the last paragraph. In the last paragraph, this is about >>>>> the application form for registering media (sub)types. If that's the way >>>>> IANA prefers it, or the way the RFC Editor usually does this, that's >>>>> perfectly fine. The alternative would be to move the contents of the last >>>>> paragraph in that section to the first paragraph to have all the talk >>>>> about these pointers in one location. This is just a thought, I'm fine if >>>>> you ignore it. >>>>> >>>>> Regards, Martin. >>>>> >>>>>> 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 >>>>> >>>>> -- >>>>> 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 >>> >>> -- >>> 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 > > -- > 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
