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
<https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml>,
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]
