If we can get these three, then we're DONE with EXTRA and can close it :) Please reply you three, and let's get it done!
Thanks all :) Bron. On Tue, Mar 4, 2025, at 17:27, Murray S. Kucherawy wrote: > 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 >> > -- 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
