Martin, is there anything further that needs to be reviewed here? Are you willing to delegate the final review to the chairs and/or me?
We've gone well past AUTH48, and are somewhere near AUTH1200. :-) We'd like to get this moving. -MSK, ART AD On Sun, Jan 19, 2025 at 12:26 AM Harald Alvestrand <har...@alvestrand.no> wrote: > On 1/19/25 06:21, Martin J. Dürst wrote: > > Hello Harald, > > > > Thanks for the encouragement. > > > > On 2025-01-19 07:23, Harald Alvestrand wrote: > >> Martin, I have reviewed the diffs and found them to contain nothing > >> that changes the meaning of the document. > > > > As far as I have looked, I agree. But I didn't check everything yet. > > > > Can you please check the following: > > > > 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). > > > > This seem more something for the WG, or at least the chairs, to decide, > > than for the author. > > I agree with the RFC Editor that this forms part of BCP 13. > > From the WG perspective, the plan is to release a 6838bis that includes > the normative parts of this RFC - but at the speed things are going, > this is going to take a while; in the meantime, this should form part of > BCP13. > > If more confirmation is needed, we should ask our AD to confirm. > > > > > > Regards, Martin. > > > >> I hope you can get around to this soon, since it's the blocking item > >> for both our "finished" documents from the MEDIAMAN working group. > >> > >> Thank you for all the work you've done on it so far! > >> > >> Harald > >> > >> On 12/24/24 07:58, 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 > >>> > >>> -------------------------------------- > >>> RFC 9694 (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
