From: Alice Russo Date: 2025-02-28 00:02 To: resnick; Jiankang Yao; Arnt Gulbrandsen CC: Murray S. Kucherawy; Bron Gondwana; extra-ads; extra-chairs; RFC Editor; auth48archive Subject: Re: AUTH48: RFC-to-be 9755 <draft-ietf-extra-6855bis-04> for your review
> On Feb 27, 2025, at 7:59 AM, Alice Russo <aru...@staff.rfc-editor.org> wrote: > > Authors, > > We see that you have re-sent your approvals of the document; however, we > await your reply to these 5 open questions. > Hi RFC Editor/ar, some comments inline below > If you have already answered the questions, please forward that mail; we did > not receive it. > > Re: https://www.rfc-editor.org/rfc/rfc9755.html (and other formats) >Correction: https://www.rfc-editor.org/authors/rfc9755.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? >> I think that either keeping the current one "UTF8-quoted" or using "utf8-quoted". same meaning, no difference. both are ok. >> 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. >> --> >> Thanks for pointing it out. I am ok with the suggested text in errata ( https://www.rfc-editor.org/errata/eid4029 ) new text: " Once an IMAP client has enabled UTF-8 support with the "ENABLE UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that contains a charset specification. If an IMAP server receives such a "SEARCH" command in that situation, it SHOULD reject the command with a "BAD" response (due to the conflicting charset labels). This also applies to any IMAP command or extension that includes an optional charset label and associated strings in the command arguments, including the MULTISEARCH extension. For commands with a mandatory charset field, such as SORT and THREAD, servers SHOULD reject charset values other than UTF-8 with a “BAD” response (due to the conflicting charset labels)." old text: "Once an IMAP client has enabled UTF-8 support with the "ENABLE UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that contains a charset specification. If an IMAP server receives such a "SEARCH" command in that situation, it SHOULD reject the command with a "BAD" response (due to the conflicting charset labels). " Pete and Arnt, what are your views about this errata? >> >> 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 ... >> --> >> My understanding is that the original one is better. >> >> 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. >> --> My understanding is that the original one is better. >> >> >> 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 >> --> > My understanding is that "MIME type" is better than "media type" in the document. Thanks Jiankang Yao > [#6 has been addressed.] > [#7 asked for your review re: inclusive language; no open question.] > > > Thank you. > RFC Editor/ar
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
