rfc9755v2.txt   rfc9755.txt 
skipping to change at line 161 skipping to change at line 161
quoted syntax with any IMAP argument that permits a string (including quoted syntax with any IMAP argument that permits a string (including
astring and nstring). However, if characters outside the US-ASCII astring and nstring). However, if characters outside the US-ASCII
repertoire are used in an inappropriate place, the results would be repertoire are used in an inappropriate place, the results would be
the same as if other syntactically valid but semantically invalid the same as if other syntactically valid but semantically invalid
characters were used. Specific cases where UTF-8 characters are characters were used. Specific cases where UTF-8 characters are
permitted or not permitted are described in the following paragraphs. permitted or not permitted are described in the following paragraphs.
All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in
mailbox names, and those that also support the Mailbox International mailbox names, and those that also support the Mailbox International
Naming Convention described in [RFC3501], Section 5.1.3, MUST accept Naming Convention described in [RFC3501], Section 5.1.3, MUST accept
UTF8-quoted mailbox names and convert them to the appropriate UTF-8 in mailbox names and convert them to the appropriate internal
internal format. Mailbox names MUST comply with the Net-Unicode format. Mailbox names MUST comply with the Net-Unicode Definition
Definition ([RFC5198], Section 2) with the specific exception that ([RFC5198], Section 2) with the specific exception that they MUST NOT
they MUST NOT contain control characters (U+0000 - U+001F and U+0080 contain control characters (U+0000 - U+001F and U+0080 - U+009F), a
- U+009F), a delete character (U+007F), a line separator (U+2028), or delete character (U+007F), a line separator (U+2028), or a paragraph
a paragraph separator (U+2029). separator (U+2029).
Once an IMAP client has enabled UTF-8 support with the "ENABLE Once an IMAP client has enabled UTF-8 support with the "ENABLE
UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
contains a charset specification. If an IMAP server receives such a contains a charset specification. If an IMAP server receives such a
"SEARCH" command in that situation, it SHOULD reject the command with "SEARCH" command in that situation, it SHOULD reject the command with
a "BAD" response (due to the conflicting charset labels). 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).
4. "APPEND" Command 4. "APPEND" Command
If the server supports "UTF8=ACCEPT", then the server accepts UTF-8 If the server supports "UTF8=ACCEPT", then the server accepts UTF-8
headers in the "APPEND" command message argument. headers in the "APPEND" command message argument.
If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not
issued the "ENABLE UTF8=ACCEPT" command, the server MUST reject, with issued the "ENABLE UTF8=ACCEPT" command, the server MUST reject, with
a "NO" response, an "APPEND" command that includes any 8-bit a "NO" response, an "APPEND" command that includes any 8-bit
character in message header fields. character in message header fields.
skipping to change at line 486 skipping to change at line 492
UTF8-related syntax compatible with IMAP4rev2 as defined by [RFC9051] UTF8-related syntax compatible with IMAP4rev2 as defined by [RFC9051]
and making it simpler for clients to support IMAP4rev1 and IMAP4rev2 and making it simpler for clients to support IMAP4rev1 and IMAP4rev2
with the same code. with the same code.
IMAP4rev2 [RFC9051] provides roughly the same abilities as [RFC6855] IMAP4rev2 [RFC9051] provides roughly the same abilities as [RFC6855]
but does not include APPEND's UTF8 item. None of [RFC6855], but does not include APPEND's UTF8 item. None of [RFC6855],
IMAP4rev2, or JMAP [RFC8620] specify any way to learn whether a IMAP4rev2, or JMAP [RFC8620] specify any way to learn whether a
particular message was stored using the UTF8 data item. As of today, particular message was stored using the UTF8 data item. As of today,
an IMAP client cannot learn whether a particular message was stored an IMAP client cannot learn whether a particular message was stored
using the UTF8 data item, nor would it be able to trust that using the UTF8 data item, nor would it be able to trust that
information even if IMAP4rev1/2 were extended to provide that information even if IMAP4rev1 and 2 were extended to provide that
information. information.
In July 2023, one of the authors found only one IMAP client that uses In July 2023, one of the authors found only one IMAP client that uses
the UTF8 data item, and that client uses it incorrectly (it sends the the UTF8 data item, and that client uses it incorrectly (it sends the
data item for all messages if the server supports UTF8=ACCEPT, data item for all messages if the server supports UTF8=ACCEPT,
without regard to whether a particular message includes any UTF8 at without regard to whether a particular message includes any UTF8 at
all). all).
For these reasons, it was judged best to revise [RFC6855] and adopt For these reasons, it was judged best to revise [RFC6855] and adopt
the same syntax as IMAP4rev2. the same syntax as IMAP4rev2.
B.2. FETCH BODYSTRUCTURE B.2. FETCH BODYSTRUCTURE
[RFC6532] defines a new MIME type, message/global, which is [RFC6532] defines a new media type, message/global, which is
substantially like message/rfc822 except that the submessage may substantially like message/rfc822 except that the submessage may
(also) use the syntax defined in [RFC6532]. [RFC3501] and [RFC9051] (also) use the syntax defined in [RFC6532]. [RFC3501] and [RFC9051]
define a FETCH item to return the MIME structure of a message, which define a FETCH item to return the media type of the body of a
servers usually compute once and store. message, which servers usually compute once and store.
None of the RFCs point out to implementers that IMAP4rev1 and None of the RFCs point out to implementers that IMAP4rev1 and
IMAP4rev2 are slightly different, so storing the BODYSTRUCTURE in the IMAP4rev2 are slightly different, so storing the BODYSTRUCTURE in the
way servers and clients often do can easily lead to problems. way servers and clients often do can easily lead to problems.
This document makes the syntax optional, making it simple for server This document makes the syntax optional, making it simple for server
authors to implement this extension correctly. This implies that authors to implement this extension correctly. This implies that
clients need to parse and handle both varieties, which they need to clients need to parse and handle both varieties, which they need to
do anyway if they want to support both IMAP4rev1 and IMAP4rev2. do anyway if they want to support both IMAP4rev1 and IMAP4rev2.
 End of changes. 5 change blocks. 
11 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.48.