Re: [auth48] [IANA #1275013] [IANA] Re: AUTH48: RFC-to-be 9122 <draft-ietf-extra-sieve-action-registry-06> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Sabrina.  Looks great!  Thank you!

RFC Editor/lb

> On Jun 20, 2023, at 10:46 AM, Sabrina Tanamal via RT <[e-mail]> wrote:
> 
> Hi Lynne, 
> 
> These changes are complete: 
> 
> https://www.iana.org/assignments/sieve-extensions
> 
> Thanks,
> Sabrina
> 
> On Fri Jun 16 19:25:03 2023, [e-mail] wrote:
>> Dear IANA,
>> 
>> Please make the following updates on
>> <https://www.iana.org/assignments/sieve-extensions/>:
>> 
>> OLD:
>> 
>> File message into the user's main mailbox
>> 
>> Incompatible with "vacation" action. Typically is not permitted with
>> actions that cause mail delivery, such as "keep", "fileinto", and
>> "redirect".
>> 
>> Use of :copy suppresses cancelation of implicit keep
>> 
>> All subsequent tests and actions, except "redirect" apply to the
>> altered message
>> 
>> Incompatible with "reject" and "ereject" actions.
>> 
>> Vacation autoresponder
>> 
>> = = =
>> 
>> NEW (add "the" after "File";
>>   remove ending periods in three places (two of which are "This
>> action is incompatible with the "vacation" action" entries);
>>   change "cancelation" to "cancellation" in two places;
>>     remove a comma; make fragments complete sentences):
>> 
>> File the message into the user's main mailbox
>> 
>> This action is incompatible with the "vacation" action.  Typically is
>> not permitted with actions that cause mail delivery, such as "keep",
>> "fileinto", and "redirect"
>> 
>> Use of :copy suppresses cancellation of implicit keep
>> 
>> All subsequent tests and actions except "redirect" apply to the
>> altered message
>> 
>> This action is incompatible with "reject" and "ereject" actions
>> 
>> Implement a vacation autoresponder
>> 
>> = = =
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>>> On Jun 16, 2023, at 12:01 PM, Lynne Bartholomew
>>> <[e-mail]> wrote:
>>> 
>>> Hi, Ken.  Great; thank you!  So noted:
>>> 
>>> https://www.rfc-editor.org/auth48/rfc9122
>>> 
>>> We will write to IANA shortly and ask them to make updates to their
>>> pages as needed so that they match this document.  After those
>>> updates are done, we will prepare this document for publication.
>>> 
>>> RFC Editor/lb
>>> 
>>>> On Jun 16, 2023, at 11:56 AM, Ken Murchison <[e-mail]>
>>>> wrote:
>>>> 
>>>> I approve the document as it stands.
>>>> 
>>>> 
>>>> On Fri, Jun 16, 2023, at 2:51 PM, Lynne Bartholomew wrote:
>>>>> Hi, Ken.
>>>>> 
>>>>> We do not believe that we have heard from you regarding this
>>>>> document's
>>>>> readiness for publication.
>>>>> 
>>>>> Please review the latest files, and let us know whether updates are
>>>>> needed or you approve this document for publication.
>>>>> 
>>>>> The latest files are posted here:
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9122.txt
>>>>> https://www.rfc-editor.org/authors/rfc9122.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9122.html
>>>>> https://www.rfc-editor.org/authors/rfc9122.xml
>>>>> https://www.rfc-editor.org/authors/rfc9122-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9122-rfcdiff.html
>>>>> https://www.rfc-editor.org/authors/rfc9122-auth48diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9122-lastdiff.html
>>>>> https://www.rfc-editor.org/authors/rfc9122-lastrfcdiff.html
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9122-xmldiff1.html
>>>>> https://www.rfc-editor.org/authors/rfc9122-xmldiff2.html
>>>>> 
>>>>> The AUTH48 status page is here:
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9122
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>>> On Jun 9, 2023, at 4:17 PM, Lynne Bartholomew
>>>>>> <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi, Alexey.
>>>>>> 
>>>>>> We have noted your approval on the AUTH48 status page:
>>>>>> 
>>>>>> https://www.rfc-editor.org/auth48/rfc9122
>>>>>> 
>>>>>> Thank you!
>>>>>> 
>>>>>> RFC Editor/lb
>>>>>> 
>>>>>>> On Jun 9, 2023, at 2:16 AM, Alexey Melnikov
>>>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi Lynne,
>>>>>>> The current version is fine to publish.
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Alexey
>>>>>>> 
>>>>>>>> On 8 Jun 2023, at 19:51, Lynne Bartholomew
>>>>>>>> <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi, Alexey and Ken.
>>>>>>>> 
>>>>>>>> Checking in with you regarding the status of this document.
>>>>>>>> Please let us know if further updates are needed.
>>>>>>>> 
>>>>>>>> The AUTH48 status page is here:
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9122
>>>>>>>> 
>>>>>>>> Thank you!
>>>>>>>> 
>>>>>>>> RFC Editor/lb
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On May 26, 2023, at 11:21 AM, Lynne Bartholomew
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Hi, Alexey.
>>>>>>>>> 
>>>>>>>>> Thank you for the notes!  We've placed a few "[rfced]" replies
>>>>>>>>> inline below.
>>>>>>>>> 
>>>>>>>>> The latest files are posted here:
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.txt
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.pdf
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.xml
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-rfcdiff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-auth48diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-lastdiff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-lastrfcdiff.html
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-xmldiff1.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-xmldiff2.html
>>>>>>>>> 
>>>>>>>>> Thanks again!
>>>>>>>>> 
>>>>>>>>> RFC Editor/lb
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>> On May 25, 2023, at 5:33 AM, Alexey Melnikov
>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Lynne,
>>>>>>>>>> 
>>>>>>>>>> I finally got around to checking the last version. Answering
>>>>>>>>>> your questions below:
>>>>>>>>>> 
>>>>>>>>>> On 20/05/2023 00:07, Lynne Bartholomew wrote:
>>>>>>>>>>> Hi, Alexey.
>>>>>>>>>>> 
>>>>>>>>>>> We have updated this document per your note below and have
>>>>>>>>>>> some follow-up questions/notes for you.
>>>>>>>>>>> 
>>>>>>>>>>> We see that this document has a mix of US and UK spellings
>>>>>>>>>>> (initialize (US), cancelation (US), behaviours (UK).  Would
>>>>>>>>>>> you prefer US or UK spelling for this document?
>>>>>>>>>> US is fine. (Or whichever is less work :-))
>>>>>>>>> 
>>>>>>>>> [rfced]  Thank you; we went with US (and also went with the
>>>>>>>>> more common spelling "cancellation", as "cancelation" has only
>>>>>>>>> been used in four RFCs to date.  Apologies for not catching
>>>>>>>>> that earlier).
>>>>>>>>> 
>>>>>>>>>>> = = = = =
>>>>>>>>>>> 
>>>>>>>>>>> Please note that per the spacing style used in Sections 7.4
>>>>>>>>>>> and 7.5 of RFC 6785, we have used "compact" vertical spacing
>>>>>>>>>>> for the existing "template" list in Section 2.1, as well as
>>>>>>>>>>> the lists in Section 2.2 that now replace the table.  Please
>>>>>>>>>>> review, and let us know if you prefer the "normal" vertical
>>>>>>>>>>> spacing (i.e., one vertical space between each entry); we
>>>>>>>>>>> realize that the "normal" spacing might make it easier to
>>>>>>>>>>> read the multi-line entries.
>>>>>>>>>>> 
>>>>>>>>>>> Also, rather than have blank entries, we used "N/A" and added
>>>>>>>>>>> text re. same to the paragraph that precedes the
>>>>>>>>>>> registrations.
>>>>>>>>>> I just checked the old table against the new text and I
>>>>>>>>>> believe they match.
>>>>>>>>> 
>>>>>>>>> [rfced]  Thank you for the double-check!
>>>>>>>>> 
>>>>>>>>>>> Additionally, we have flagged an update for IANA, to be made
>>>>>>>>>>> just prior to publication, re. inconsistent punctuation in
>>>>>>>>>>> three of the "Action Interactions" column entries.  Please
>>>>>>>>>>> see our note on<https://www.rfc-editor.org/auth48/rfc9122>,
>>>>>>>>>>> and let us know if you prefer to add periods at the end of
>>>>>>>>>>> most of the entries instead of removing them from three
>>>>>>>>>>> entries.
>>>>>>>>>> Either way is fine, whatever is less work.
>>>>>>>>> 
>>>>>>>>> [rfced]  Thank you for this as well; at PUB time we will
>>>>>>>>> proceed as noted on <https://www.rfc-
>>>>>>>>> editor.org/auth48/rfc9122>.
>>>>>>>>> 
>>>>>>>>>>> = = = = =
>>>>>>>>>>> 
>>>>>>>>>>> As we noticed the following after looking carefully at the
>>>>>>>>>>> registration entries --
>>>>>>>>>>> (1) Would you like "File message" in the "keep" registration
>>>>>>>>>>> to be "File the message"?
>>>>>>>>>> Sure.
>>>>>>>>>>> (2) Could the three "Incompatible with ..." phrases somehow
>>>>>>>>>>> be made complete sentences, per the other "Action
>>>>>>>>>>> Interactions" entries?
>>>>>>>>>> Yes. Just change them to "This action is incompatible with
>>>>>>>>>> ..."
>>>>>>>>>>> (3) Could "Vacation autoresponder" in the "vacation" entry be
>>>>>>>>>>> made a complete sentence, per the rest of the "Description"
>>>>>>>>>>> entries (perhaps "Implement a vacation autoresponder" per
>>>>>>>>>>> Section 4 of RFC 5230)?
>>>>>>>>>> 
>>>>>>>>>> "Implement a vacation autoresponder" is fine with me.
>>>>>>>>> 
>>>>>>>>> [rfced]  Made these additional updates as well and have flagged
>>>>>>>>> them for IANA updates pre-PUB.  Thank you!
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Best Regards,
>>>>>>>>>> 
>>>>>>>>>> Alexey
>>>>>>>>>> 
>>>>>>>>>>> If yes, we will ask IANA to make corresponding updates as
>>>>>>>>>>> appropriate.
>>>>>>>>>>> 
>>>>>>>>>>> The latest files are posted here:
>>>>>>>>>>> 
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.txt
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.pdf
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.xml
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-rfcdiff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-auth48diff.html
>>>>>>>>>>> 
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-xmldiff1.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-xmldiff2.html
>>>>>>>>>>> 
>>>>>>>>>>> Unfortunately, because the changes to Section 2.2 are
>>>>>>>>>>> extensive, there isn't an easy way to view them.
>>>>>>>>>>> 
>>>>>>>>>>> Please review all of our updates to Section 2.2 carefully,
>>>>>>>>>>> and let us know if anything is incorrect.
>>>>>>>>>>> 
>>>>>>>>>>> Thank you!
>>>>>>>>>>> 
>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>> 
>>>>>>>>>>>> On May 17, 2023, at 9:05 AM, Alexey
>>>>>>>>>>>> Melnikov<[e-mail]>  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Lynne,
>>>>>>>>>>>> 
>>>>>>>>>>>> On 16/05/2023 21:27, Lynne Bartholomew wrote:
>>>>>>>>>>>>> Hi, Alexey and Ken.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thank you for your quick replies!  Further updates are in
>>>>>>>>>>>>> progress.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regarding our question 6) and the original table in Section
>>>>>>>>>>>>> 2.2:  Thank you for your guidance.  We are looking into
>>>>>>>>>>>>> splitting Table 1 into two tables, but would you prefer
>>>>>>>>>>>>> breaking all of the table rows out into 18 lists?  For
>>>>>>>>>>>>> example, the first of the 18 items would look as follows:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Name: addheader
>>>>>>>>>>>>> Description: Add a header field to the existing message
>>>>>>>>>>>>> header
>>>>>>>>>>>>> References: [RFC5293]
>>>>>>>>>>>>> Capabilities: "editheader"
>>>>>>>>>>>>> Action Interactions: All subsequent tests and actions apply
>>>>>>>>>>>>> to the altered message
>>>>>>>>>>>>> Cancels Implicit Keep?  No
>>>>>>>>>>>>> Can Use with IMAP Events?  Yes
>>>>>>>>>>>> This would be fine with me. Whatever is Ok with both you and
>>>>>>>>>>>> IANA would be fine.
>>>>>>>>>>>> 
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> 
>>>>>>>>>>>> Alexey
>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks again!
>>>>>>>>>>>>> 
>>>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On May 15, 2023, at 7:35 AM, Alexey
>>>>>>>>>>>>>> Melnikov<[e-mail]>  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>> On 15/05/2023 13:52, Ken Murchison wrote:
>>>>>>>>>>>>>>> I approve of the current editorial changes made by the
>>>>>>>>>>>>>>> editors.  Answers to outstanding questions are inline
>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>> I concur.
>>>>>>>>>>>>>>> On 5/13/23 2:27 AM,[e-mail]  wrote:
>>>>>>>>>>>>>>>> Authors,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> While reviewing this document during AUTH48, please
>>>>>>>>>>>>>>>> resolve (as necessary)
>>>>>>>>>>>>>>>> the following questions, which are also in the XML file.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 1) <!-- [rfced] The registration policy for the Sieve
>>>>>>>>>>>>>>>> Actions Registry is
>>>>>>>>>>>>>>>> Expert Review, which we do not believe requires an IETF
>>>>>>>>>>>>>>>> Stream RFC.
>>>>>>>>>>>>>>>> Therefore, we have removed "IETF Stream" from the the
>>>>>>>>>>>>>>>> following. Please let
>>>>>>>>>>>>>>>> us know if any corrections are needed.
>>>>>>>>>>>>>> This is fine.
>>>>>>>>>>>>>>>> In addition, please consider whether "vendor specific
>>>>>>>>>>>>>>>> actions" should be
>>>>>>>>>>>>>>>> "vendor-specific documentation" (or similar) since
>>>>>>>>>>>>>>>> "actions" has a specific
>>>>>>>>>>>>>>>> meaning in this document.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> Registration
>>>>>>>>>>>>>>>> of both actions specified in IETF Stream RFCs and vendor
>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>> actions is allowed and encouraged.
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>> I would be fine with this changes, but will defer to
>>>>>>>>>>>>>>> Alexey on the final determination.
>>>>>>>>>>>>>> I like "vendor-specific documentation", so let's do this
>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>> 2) <!-- [rfced] Should the template be formatted more
>>>>>>>>>>>>>>>> like a blank
>>>>>>>>>>>>>>>> template readers can use for future registrations? For
>>>>>>>>>>>>>>>> example:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Name: name of the action
>>>>>>>>>>>>>>>> Description: short description
>>>>>>>>>>>>>>>> References: one or more documents describing the action
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> any significant updates to its definition (this field
>>>>>>>>>>>>>>>> is required for actions described in RFCs and is
>>>>>>>>>>>>>>>> optional
>>>>>>>>>>>>>>>> otherwise).
>>>>>>>>>>>>>>>> Capabilities: Interactions with other Sieve actions (as
>>>>>>>>>>>>>>>> described in
>>>>>>>>>>>>>>>> Section 2.10.1 of [RFC5228]), if any.
>>>>>>>>>>>>>>>> Action Interactions: ...
>>>>>>>>>>>>>>>> Cancels Implicit Keep? ...
>>>>>>>>>>>>>>>> Can Use With IMAP Events? ...
>>>>>>>>>>>>>>>> Comments: ...
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>> Yes, I think an empty template would be preferable.
>>>>>>>>>>>>>> Sounds good to me.
>>>>>>>>>>>>>>>> 3) <!-- [rfced] We added an informative reference to RFC
>>>>>>>>>>>>>>>> 8126 to help the
>>>>>>>>>>>>>>>> user understand Expert Review and designated expert.
>>>>>>>>>>>>>>>> Please let us know if
>>>>>>>>>>>>>>>> you have any objections.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> Registration procedure for this registry is Expert
>>>>>>>>>>>>>>>> Review.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>>>> The registration procedure for this registry is Expert
>>>>>>>>>>>>>>>> Review [RFC8126].
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>> No objection to adding a reference to RFC 9126.
>>>>>>>>>>>>>> I assume you meant 8126.
>>>>>>>>>>>>>> No objections from me either.
>>>>>>>>>>>>>>>> 4) <!-- [rfced] "err on the side of registering" is a
>>>>>>>>>>>>>>>> bit awkward. May we
>>>>>>>>>>>>>>>> update the text as follows?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> The Designated
>>>>>>>>>>>>>>>> Expert can’t reject a registration based on personal
>>>>>>>>>>>>>>>> dislike of the
>>>>>>>>>>>>>>>> document defining an action and should always err on the
>>>>>>>>>>>>>>>> side of
>>>>>>>>>>>>>>>> registering, even if documentation is not complete.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Suggested:
>>>>>>>>>>>>>>>> The designated
>>>>>>>>>>>>>>>> expert can’t reject a registration because of a personal
>>>>>>>>>>>>>>>> dislike for the
>>>>>>>>>>>>>>>> document defining an action and should always err on the
>>>>>>>>>>>>>>>> side of approving
>>>>>>>>>>>>>>>> the registration, even if documentation is not complete.
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>> The suggested text looks good to me.
>>>>>>>>>>>>>> +1.
>>>>>>>>>>>>>>>> 5) <!-- [rfced] For readability, we suggest the
>>>>>>>>>>>>>>>> following update.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> Addition of a new reference to an existing registration
>>>>>>>>>>>>>>>> or change to
>>>>>>>>>>>>>>>> the description field goes through the same registration
>>>>>>>>>>>>>>>> procedure as
>>>>>>>>>>>>>>>> a new registration.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Suggested:
>>>>>>>>>>>>>>>> The same registration procedure is used to add a new
>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>> or to change the description field of an existing
>>>>>>>>>>>>>>>> registration.
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>> The suggested text looks good to me.
>>>>>>>>>>>>>> +1.
>>>>>>>>>>>>>>>> 6) <!-- [rfced] The table extends well beyond the 69
>>>>>>>>>>>>>>>> characters per line
>>>>>>>>>>>>>>>> limitation. We are discussing any possible options
>>>>>>>>>>>>>>>> within our team. However,
>>>>>>>>>>>>>>>> do you have any suggestions for trimming it down? We are
>>>>>>>>>>>>>>>> getting warnings
>>>>>>>>>>>>>>>> like the following:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Total table width (84)
>>>>>>>>>>>>>>>> exceeds available width (69)
>>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Too long line found (L133),
>>>>>>>>>>>>>>>> 15 characters longer than 72 characters:
>>>>>>>>>>>>>>>> +============+=============+==========+==============+============+========+=======+
>>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Too long line found (L134),
>>>>>>>>>>>>>>>> 15 characters longer than 72 characters:
>>>>>>>>>>>>>>>> |Name |Description |References|Capabilities |Action
>>>>>>>>>>>>>>>> |Cancels |Can Use|
>>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Too long line found (L135),
>>>>>>>>>>>>>>>> 15 characters longer than 72 characters:
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>> I would have 3 possible suggestions which could be used
>>>>>>>>>>>>>>> independently or in concert:
>>>>>>>>>>>>>>> • Remove the Capabilities column, as its contents can be
>>>>>>>>>>>>>>> inferred from the References column
>>>>>>>>>>>>>> I don't like this, as it would be helpful to have this
>>>>>>>>>>>>>> information in the IANA registry.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> • Split the table into two: one for actions that can be
>>>>>>>>>>>>>>> used with IMAP Events and one for those that can not.
>>>>>>>>>>>>>> This can work, but maybe start with the following
>>>>>>>>>>>>>> suggestion first:
>>>>>>>>>>>>>>> • Change the Action Interactions column to just be a
>>>>>>>>>>>>>>> reference to numbered footnotes as most of the text is
>>>>>>>>>>>>>>> used multiple times:
>>>>>>>>>>>>>>> • All subsequent tests and actions apply to the altered
>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>> • All subsequent tests and actions, except "redirect"
>>>>>>>>>>>>>>> apply to the altered message
>>>>>>>>>>>>>>> • Incompatible with "vacation" action. Typically is not
>>>>>>>>>>>>>>> permitted with actions that cause mail delivery, such as
>>>>>>>>>>>>>>> "keep", "fileinto", and "redirect".
>>>>>>>>>>>>>>> • Use of :copy suppresses cancelation of implicit keep
>>>>>>>>>>>>>>> • Incompatible with "reject" and "ereject" actions.
>>>>>>>>>>>>>> That would be fine with me!
>>>>>>>>>>>>>>>> 7) <!-- [rfced] The Acknowledgements currently says
>>>>>>>>>>>>>>>> "TBD." Please let us
>>>>>>>>>>>>>>>> know if you'd like to update the text or if if should be
>>>>>>>>>>>>>>>> removed from the
>>>>>>>>>>>>>>>> document.
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>> I'll leave this for Alexey.
>>>>>>>>>>>>>> I did a quick scan of mailing list discussions and I
>>>>>>>>>>>>>> suggest to add the following:
>>>>>>>>>>>>>> Thank you to Barry Leiba, Donald Eastlake, Yoshiro Yoneya,
>>>>>>>>>>>>>> Murray Kucherawy for reviews and feedback on this
>>>>>>>>>>>>>> document.
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Alexey
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 8) <!-- [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.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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 May 15, 2023, at 5:52 AM, Ken
>>>>>>>>>>>>>> Murchison<murch=[e-mail]>  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I approve of the current editorial changes made by the
>>>>>>>>>>>>>> editors.  Answers to outstanding questions are inline
>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 5/13/23 2:27 AM,[e-mail]  wrote:
>>>>>>>>>>>>>>> Authors,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> While reviewing this document during AUTH48, please
>>>>>>>>>>>>>>> resolve (as necessary)
>>>>>>>>>>>>>>> the following questions, which are also in the XML file.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 1) <!-- [rfced] The registration policy for the Sieve
>>>>>>>>>>>>>>> Actions Registry is
>>>>>>>>>>>>>>> Expert Review, which we do not believe requires an IETF
>>>>>>>>>>>>>>> Stream RFC.
>>>>>>>>>>>>>>> Therefore, we have removed "IETF Stream" from the the
>>>>>>>>>>>>>>> following. Please let
>>>>>>>>>>>>>>> us know if any corrections are needed.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> In addition, please consider whether "vendor specific
>>>>>>>>>>>>>>> actions" should be
>>>>>>>>>>>>>>> "vendor-specific documentation" (or similar) since
>>>>>>>>>>>>>>> "actions" has a specific
>>>>>>>>>>>>>>> meaning in this document.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>> Registration
>>>>>>>>>>>>>>> of both actions specified in IETF Stream RFCs and vendor
>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>> actions is allowed and encouraged.
>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> I would be fine with this changes, but will defer to
>>>>>>>>>>>>>> Alexey on the final determination.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 2) <!-- [rfced] Should the template be formatted more
>>>>>>>>>>>>>>> like a blank
>>>>>>>>>>>>>>> template readers can use for future registrations? For
>>>>>>>>>>>>>>> example:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Name: name of the action
>>>>>>>>>>>>>>> Description: short description
>>>>>>>>>>>>>>> References: one or more documents describing the action
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> any significant updates to its definition (this field
>>>>>>>>>>>>>>> is required for actions described in RFCs and is optional
>>>>>>>>>>>>>>> otherwise).
>>>>>>>>>>>>>>> Capabilities: Interactions with other Sieve actions (as
>>>>>>>>>>>>>>> described in
>>>>>>>>>>>>>>> Section 2.10.1 of [RFC5228]), if any.
>>>>>>>>>>>>>>> Action Interactions: ...
>>>>>>>>>>>>>>> Cancels Implicit Keep? ...
>>>>>>>>>>>>>>> Can Use With IMAP Events? ...
>>>>>>>>>>>>>>> Comments: ...
>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> Yes, I think an empty template would be preferable.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 3) <!-- [rfced] We added an informative reference to RFC
>>>>>>>>>>>>>>> 8126 to help the
>>>>>>>>>>>>>>> user understand Expert Review and designated expert.
>>>>>>>>>>>>>>> Please let us know if
>>>>>>>>>>>>>>> you have any objections.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>> Registration procedure for this registry is Expert
>>>>>>>>>>>>>>> Review.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>>> The registration procedure for this registry is Expert
>>>>>>>>>>>>>>> Review [RFC8126].
>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> No objection to adding a reference to RFC 9126.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 4) <!-- [rfced] "err on the side of registering" is a bit
>>>>>>>>>>>>>>> awkward. May we
>>>>>>>>>>>>>>> update the text as follows?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>> The Designated
>>>>>>>>>>>>>>> Expert can’t reject a registration based on personal
>>>>>>>>>>>>>>> dislike of the
>>>>>>>>>>>>>>> document defining an action and should always err on the
>>>>>>>>>>>>>>> side of
>>>>>>>>>>>>>>> registering, even if documentation is not complete.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Suggested:
>>>>>>>>>>>>>>> The designated
>>>>>>>>>>>>>>> expert can’t reject a registration because of a personal
>>>>>>>>>>>>>>> dislike for the
>>>>>>>>>>>>>>> document defining an action and should always err on the
>>>>>>>>>>>>>>> side of approving
>>>>>>>>>>>>>>> the registration, even if documentation is not complete.
>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> The suggested text looks good to me.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 5) <!-- [rfced] For readability, we suggest the following
>>>>>>>>>>>>>>> update.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>> Addition of a new reference to an existing registration
>>>>>>>>>>>>>>> or change to
>>>>>>>>>>>>>>> the description field goes through the same registration
>>>>>>>>>>>>>>> procedure as
>>>>>>>>>>>>>>> a new registration.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Suggested:
>>>>>>>>>>>>>>> The same registration procedure is used to add a new
>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>> or to change the description field of an existing
>>>>>>>>>>>>>>> registration.
>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> The suggested text looks good to me.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 6) <!-- [rfced] The table extends well beyond the 69
>>>>>>>>>>>>>>> characters per line
>>>>>>>>>>>>>>> limitation. We are discussing any possible options within
>>>>>>>>>>>>>>> our team. However,
>>>>>>>>>>>>>>> do you have any suggestions for trimming it down? We are
>>>>>>>>>>>>>>> getting warnings
>>>>>>>>>>>>>>> like the following:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Total table width (84) exceeds
>>>>>>>>>>>>>>> available width (69)
>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Too long line found (L133), 15
>>>>>>>>>>>>>>> characters longer than 72 characters:
>>>>>>>>>>>>>>> +============+=============+==========+==============+============+========+=======+
>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Too long line found (L134), 15
>>>>>>>>>>>>>>> characters longer than 72 characters:
>>>>>>>>>>>>>>> |Name |Description |References|Capabilities |Action
>>>>>>>>>>>>>>> |Cancels |Can Use|
>>>>>>>>>>>>>>> rfc9122.xml(195): Warning: Too long line found (L135), 15
>>>>>>>>>>>>>>> characters longer than 72 characters:
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> I would have 3 possible suggestions which could be used
>>>>>>>>>>>>>> independently or in concert:
>>>>>>>>>>>>>> • Remove the Capabilities column, as its contents can be
>>>>>>>>>>>>>> inferred from the References column
>>>>>>>>>>>>>> • Split the table into two: one for actions that can be
>>>>>>>>>>>>>> used with IMAP Events and one for those that can not.
>>>>>>>>>>>>>> • Change the Action Interactions column to just be a
>>>>>>>>>>>>>> reference to numbered footnotes as most of the text is
>>>>>>>>>>>>>> used multiple         times:
>>>>>>>>>>>>>> • All subsequent tests and actions apply to the altered
>>>>>>>>>>>>>> message
>>>>>>>>>>>>>> • All subsequent tests and actions, except "redirect"
>>>>>>>>>>>>>> apply to the altered message
>>>>>>>>>>>>>> • Incompatible with "vacation" action. Typically is not
>>>>>>>>>>>>>> permitted with actions that cause mail delivery, such as
>>>>>>>>>>>>>> "keep", "fileinto", and "redirect".
>>>>>>>>>>>>>> • Use of :copy suppresses cancelation of implicit keep
>>>>>>>>>>>>>> • Incompatible with "reject" and "ereject" actions.
>>>>>>>>>>>>>>> 7) <!-- [rfced] The Acknowledgements currently says
>>>>>>>>>>>>>>> "TBD." Please let us
>>>>>>>>>>>>>>> know if you'd like to update the text or if if should be
>>>>>>>>>>>>>>> removed from the
>>>>>>>>>>>>>>> document.
>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> I'll leave this for Alexey.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 8) <!-- [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.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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 May 12, 2023, at 11:17 PM,[e-mail]
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Updated 2023/05/12
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> *[e-mail]  (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).
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> *[e-mail], 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,
>>>>>>>>>>>>>>> [e-mail]  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/rfc9122.xml
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.html
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.pdf
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.txt
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-diff.html
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-rfcdiff.html
>>>>>>>>>>>>>>> (side by side)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122-xmldiff1.html
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> The following files are provided to facilitate creation
>>>>>>>>>>>>>>> of your own
>>>>>>>>>>>>>>> diff files of the XML.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>>>>>>>>>>>> https://www.rfc-
>>>>>>>>>>>>>>> editor.org/authors/rfc9122.original.v2v3.xml
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> XMLv3 file that is a best effort to capture v3-related
>>>>>>>>>>>>>>> format updates
>>>>>>>>>>>>>>> only:
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9122.form.xml
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> The details of the AUTH48 status of your document are
>>>>>>>>>>>>>>> here:
>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9122
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>> RFC9122 (draft-ietf-extra-sieve-action-registry-06)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Title : IANA registry for Sieve actions
>>>>>>>>>>>>>>> Author(s) : A. Melnikov, K. Murchison
>>>>>>>>>>>>>>> WG Chair(s) : Jiankang Yao, Bron Gondwana
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Area Director(s) : Murray Kucherawy, Francesca Palombini
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Kenneth Murchison
>>>>>>>>>>>>>> Senior Software Developer
>>>>>>>>>>>>>> Fastmail US LLC
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> --
>>>> Kenneth Murchison
>>>> Senior Software Developer
>>>> Fastmail US LLC
>>>> [e-mail]
>>>> 
>>> 
> 
>