Jiankang, Pete, Thank you for your replies. We have updated the document as detailed in the mail included below, with my notes inline as "AR:".
Re: #3 > I will defer to Arnt if he thinks differently, but I think updating to the > new text from the erratum report seems like a good idea. Section 3 has been updated to match the new text on https://www.rfc-editor.org/errata/eid4029. We'll await word from Arnt before proceeding. The changes can be seen in these files. https://www.rfc-editor.org/authors/rfc9755.html https://www.rfc-editor.org/authors/rfc9755.txt https://www.rfc-editor.org/authors/rfc9755.pdf https://www.rfc-editor.org/authors/rfc9755.xml This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9755-diff.html https://www.rfc-editor.org/authors/rfc9755-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9755-auth48diff.html https://www.rfc-editor.org/authors/rfc9755-auth48rfcdiff.html (side by side) This diff file shows only the changes since the last posted version: https://www.rfc-editor.org/authors/rfc9755-lastrfcdiff.html This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9755 Thank you. RFC Editor/ar > On Mar 7, 2025, at 1:41 PM, Pete Resnick <resn...@episteme.net> wrote: > > Whoops. Re-sending my answers to the entire Cc list. > > Inline below: > >>>>> 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. >>>>>> --> > > I think we should avoid using UTF8-quoted anymore. How's this: > > NEW > > 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 > UTF-8 in mailbox names and convert them to the appropriate > internal format. AR: Updated. > >>>>>> 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? > > I will defer to Arnt if he thinks differently, but I think updating to the > new text from the erratum report seems like a good idea. AR: Updated and awaiting review. > >>>>>> 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. > > Yes, keep the original, or simply delete "UTF-related". By removing the > "UTF8" data item, this document makes the syntax of APPEND compatible with > IMAPrev2, etc. AR: The original remains. > >>>>>> 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. > > I disagree with Yao. The proposed new version is better. Either "and" or "or" > would work. AR: Updated to "and". > >>>>>> 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. > > I agree with Murray: "media type" is used more often now, and the terms are > equivalent. I think you can change them to "media type". AR: Updated. > > pr > > > -- > Pete Resnick https://www.episteme.net/ > All connections to the world are tenuous at best > On Mar 7, 2025, at 3:33 AM, Jiankang Yao <ya...@cnnic.cn> wrote: > > > > From: Alice Russo > Date: 2025-03-04 06:31 > To: Jiankang Yao; resnick; 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 > > > >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. > > Agree. Works for me! > > Thanks a lot > Jiankang Yao > > > 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 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
