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

[Sabrina Tanamal via RT <[e-mail]>]

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