Murray, Bron, Re: > OK, then Alice, please proceed without the new text.
Ack. Authors, We await your replies to the following questions, as well as any further changes, for this document (https://www.rfc-editor.org/authors/rfc9755.html and .txt and .pdf). This diff shows all changes from the Internet-Draft: https://www.rfc-editor.org/authors/rfc9755-rfcdiff.html On Feb 9, 2025, rfc-edi...@rfc-editor.org wrote: > 1) <!--[rfced] Regarding the term "UTF8-quoted": We note this term > was also used in RFC 6855, which is the only RFC where this term > has appeared in this form. Does it refer to the ABNF rule > 'utf8-quoted' as defined in RFC 5738 (which is obsolete), or > to another concept? Should it be replaced with 'utf8-quoted' > or should the concept be written in prose? > > Original: > All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in > mailbox names, and those that also support the Mailbox International > Naming Convention described in RFC 3501, Section 5.1.3, MUST accept > UTF8-quoted mailbox names and convert them to the appropriate > internal format. > --> > > > 2) <!-- [rfced] There is one Verified Technical errata report for RFC 6855: > https://www.rfc-editor.org/errata/eid4029 > This document contains the old text from Section 3 mentioned in that > report. Please review whether any updates are needed for this document. > --> > > > 3) <!--[rfced] Here, does "UTF8-related" mean related to > the UTF8 data item or related to the UTF-8 character encoding? > If the former, may the sentence be updated as follows? > > Original: > This document removes APPEND's UTF8 data item, making the > UTF8-related syntax compatible with IMAP4rev2 ... > > Perhaps: > This document removes APPEND's UTF8 data item, making the > syntax related to that data item compatible with IMAP4rev2 ... > --> > > > 4) <!--[rfced] Please clarify the "/" in "IMAP4rev1/2" here. > Is the intended meaning "and" or "or" or otherwise? > Original: > As of today, > an IMAP client cannot learn whether a particular message was stored > using the UTF8 data item, nor would it be able to trust that > information even if IMAP4rev1/2 were extended to provide that > information. > > Perhaps: > ... even if IMAP4rev1 and 2 were extended to provide that information. > --> > > > 5) <!--[rfced] In general in RFCs, the term "MIME type" > should be "media type". Please review whether these updates > convey the intended meaning. > > a new MIME type -> a new media type > > the MIME structure of a message > -> the media type of the body of a message > --> [#6 has been addressed.] [#7 asked for your review re: inclusive language; no open question.] Thank you. RFC Editor/ar > On Feb 20, 2025, at 9:25 AM, Murray S. Kucherawy <superu...@gmail.com> wrote: > > OK, then Alice, please proceed without the new text. > > -MSK, ART AD > > On Thu, Feb 20, 2025 at 9:20 AM Bron Gondwana <br...@fastmailteam.com> wrote: > On Thu, Feb 20, 2025, at 16:59, Murray S. Kucherawy wrote: >> On Wed, Feb 19, 2025 at 3:01 PM Alice Russo <aru...@staff.rfc-editor.org> >> wrote: >> Murray (as AD), >> >> Re: https://www.rfc-editor.org/authors/rfc9755.html >> >> Would you please offer guidance on whether to add the "Note that when" >> paragraph in Section 7 (pasted below)? My understanding is that we do not >> have consensus among the authors on whether to add it (specificially, the >> authors are 1 in favor, 1 against, and 1 OK either way). The WG chair (Bron) >> wrote "no strong preference either way". >> >> If this is the aggregate position, I'm inclined to suggest one of two things: >> >> (a) Do not make the change. >> >> (b) Put the question to the working group (say, for a week) and have the >> chairs call consensus on the result of that discussion. If the consensus >> answer to that question is ambiguous, default to (a). > > I vote for (a) Do not make the change. It's already been discussed in the > working group for over a week and the working group is generally unhappy with > the change as far as I can see. > > So let's go ahead with it as-is and not add the text. I think it's clear > enough without it. > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > br...@fastmailteam.com > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
