So this is waiting on Pete and Arnt for Jiankang's question, and on Jiankang for my question.
-MSK On Mon, Mar 3, 2025 at 2:31 PM Alice Russo <aru...@staff.rfc-editor.org> wrote: > 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
