Hi Neil, Thanks for your reply and guidance. We have updated as requested and reposted the files.
Once you have a chance to review, please contact us with any further updates or your approval of the document in its current form. Remember to review carefully as we do not make changes once the document is published. We will await approvals from you and Daniel prior to moving forward in the publication process. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9979.txt https://www.rfc-editor.org/authors/rfc9979.pdf https://www.rfc-editor.org/authors/rfc9979.html https://www.rfc-editor.org/authors/rfc9979.xml The diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9979-diff.html (comprehensive) https://www.rfc-editor.org/authors/rfc9979-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9979-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9979-auth48rfcdiff.html (side by side) The AUTH48 status page is available here: https://www.rfc-editor.org/auth48/rfc9979 Thank you. Megan Ferguson RFC Production Center > On May 11, 2026, at 10:05 PM, Neil Jenkins > <[email protected]> wrote: > > On Fri, 8 May 2026, at 01:31, [email protected] wrote: >> >> >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. >> >> 1) <!--[rfced] In the following, should "sent items folder" be made >> "\Sent mailbox"? >> >> Original: >> Supporting clients can present these messages differently in the sent >> items folder... >> >> --> > > > Yes let's change this as suggested; I think \Sent mailbox is clearer. > >> 2) <!--[rfced] We had a few questions related to the IANA keyword >> registrations: >> >> a) We note that the template in RFC 5788 includes "Person & email >> address to contact for further information:". This document does not >> include this for any of the subsections of Section 9.1. We assume >> this has been left off intentionally. If not, please let us know any >> desired updates. > > > Yes, this is left out deliberately; looking at the registry contents, it's > only used when there's not an RFC to reference for the keyword. > >> b) The template in RFC 5788 does not list "Scope". RFC 8621 lists it >> before "Purpose (description)". Please let us know if any updates are >> desirable to placement (i.e., should it be moved before Purpose or >> follow Owner/Change controller?). > > > I think the current position after Intended Usage is fine — that matches the > order on the IANA registry page. > >> c) Related to the above, should "Purpose" be made "Purpose >> (description)" for an exact match to the template? > > > I think just "Purpose" is fine, but don't think it really matters much either > way. > >> d) The template in RFC 5788 contains the following: >> >> Related keywords: (for example, "mutually exclusive with keywords Y >> and Z") >> >> We see the following in this document: >> >> Section 4: >> The $hasattachment and $hasnoattachment keywords are mutually >> exclusive. >> >> and Section 9.1.4 lists $hasnoattachment as a related keyword for >> $hasattachment. >> >> Please let us know if any updates should be made to either Section >> 9.1.4 to mention the mutual exclusivity or to Section 9.1.6 where >> $hasnoattachment lists "Related keywords: None". > > > Yes, please update these. Section 9.1.4 should read "Mutually exclusive with > $hasnoattachment." and Section 9.1.6 should read "Mutually exclusive with > $hasattachment." > >> e) We see that the template in RFC 5788 lists "LIMITED USE" as a >> possible value for Intended usage. Sections 9.1.12 and 9.1.15 use >> "LIMITED" without "USE". Please let us know if an update should be >> made. > > > Yes, let's make these "LIMITED USE" to match RFC 5788. > >> f) The heading "Is it an advisory keyword or may it cause an automatic >> action:" sounds like it must be one of those options (i.e., advisory >> or automatic action). However, we see "No" for the following: >> >> $MailFlagBit0 >> $MailFlagBit1 >> $MailFlagBit2 >> >> Please review and let us know if any updates are necessary. > > > Please update these to "This keyword is advisory." > >> g) In the following text, does the client also set the keyword during >> message delivery (note that similar text occurs more than once): >> >> Original: >> When/by whom the keyword is set/cleared: It is set by the server >> during message delivery, or by the client (if neither >> $hasattachment nor $hasnoattachment are currently set). >> >> Perhaps A: >> When/by whom the keyword is set/cleared: It is set during message >> delivery by the server or the client (if neither $hasattachment nor >> $hasnoattachment is currently set). >> >> Perhaps B: >> When/by whom the keyword is set/cleared: It is set by the server >> during message delivery; otherwise, it is set by the client (if neither >> $hasattachment nor $hasnoattachment are currently set). >> --> > > > Option B is the intended semantics here. I think this is clearer than the > original so let's change to this, thanks. > >> 3) <!--[rfced] We had the following questions/comments related to >> abbreviation use throughout the document: >> >> a) We have expanded abbreviations upon first use. Please review for >> accuracy. >> --> > > > Yes, these are correct; thank you. > >> 4) <!--[rfced] We had the following questions related to special text >> marking throughout the file: >> >> We see both <tt>$hasnoattachment</tt> and $hasnoattachment. >> We see both <tt>$hasattachment</tt> and $hasattachment. >> >> Note: the unmarked version appears in the (recurring) sentence "if neither >> $hasattachment nor $hasnoattachment is currently set". >> >> Please review and confirm that these appear as desired. >> --> > > > For consistency I think we should always mark up these keyword names with a > <tt>, so let's add that in where missing. > >> 5) <!--[rfced] We had the following question regarding terminology used >> throughout the document: >> >> We see "hasAttachment" Email property. Please confirm that the capping >> scheme here should not match other uses (i.e., it should not be >> "hasattachment"). --> > > > Yes, the current document is correct — the Email property name in JMAP is > case-sensitive and MUST be hasAttachment. > >> 6) <!-- [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. >> --> > > > Noted. > >> 7) <!--[rfced] A note to Neil: we have updated your initials in the >> header to simply your first initial to match use in RFC 9670. >> Please let us know if you'd prefer otherwise. --> > > > That's fine, thank you. > > Thanks for all your hard work! > > Cheers, > Neil. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
