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.
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.
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.
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.
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".
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
