Authors, Jiankang, thank you for your reply.
Re: #1, per your reply, no update has been made to "UTF8-quoted". Re: #3, per your reply, no update has been made to "UTF8-related". Re: #4, per your reply, no update has been made to "IMAP4rev1/2". The open questions are now 2 and 5, where: For #2 re: https://www.rfc-editor.org/errata/eid4029 You wrote: > Pete and Arnt, what are your views about this errata? For #5, you wrote: > My understanding is that "MIME type" is better than "media type" in the > document. We agree with Murray's reply that this is the older name. On IANA's Media Type registry (https://www.iana.org/assignments/media-types) is this note: "[RFC2046] specifies that Media Types (formerly known as MIME types) and Media Subtypes will be assigned and listed by the IANA." Thank you. RFC Editor/ar > On Feb 27, 2025, at 10:28 PM, Jiankang Yao <ya...@cnnic.cn> wrote: > > > > 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
