Hello Murray, Harald, others,

I'm very sorry for the long delay. It's currently 'grading season', so I'm essentially grading from morning to evening, and have to hurry up because I'm already missing the original deadline and get hassled by the University administration.

But there's some good news: Yesterday, I managed to look through a side-by-side diff, and identify what changes are okay (most of them) and what needs further fixing. I should be able to write that up (or change it in XML) early next week.

Again, very sorry but hope things will get better soon.

Regards,   Martin.

On 2025-02-12 14:05, Murray S. Kucherawy wrote:
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








--
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

Reply via email to