Re: [EAI] I-D Action: draft-ietf-eai-5738bis-05.txt

[Alexey Melnikov <[e-mail]>]

On 14/07/2012 12:08, Arnt Gulbrandsen wrote:
>
> Now the ability to send Utf8 in quoted strings is completely gone. I 
> an sorry about that. While it is not critical to correctness, I think 
> it is important to ease of implementation.
>
> A client that sent select commands using printf no longer can do that: 
> the printf format has to change a lot and formally speaking the client 
> has to wait on a literal.
>
> Alexey, can you suggest a syntax change to allow utf8 in 
> quited-strings? (i am afk, sorry.)
>
Here is the proposed change:

3.  UTF8=ACCEPT IMAP Capability

    The "UTF8=ACCEPT" capability indicates that the server supports the
    ability to open mailboxes containing internationalized messages with
    SELECT and EXAMINE, and UTF-8 responses from the LIST and LSUB
    commands.

    A client MUST use the "ENABLE UTF8=ACCEPT" command (defined in
    [RFC5161]) to indicate to the server that the client accepts UTF-8

Insert "in" here

    quoted-strings.


Add back the Section 3.1 (slightly modified):

3.1.  UTF-8 in IMAP Quoted Strings

    The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit
    characters in atoms or quoted strings.  Thus, a UTF-8 string can only
    be sent as a literal.  This can be inconvenient from a coding
    standpoint, and unless the server offers IMAP4 non-synchronizing
    literals [RFC2088], this requires an extra round trip for each UTF-8
    string sent by the client.  When the IMAP server advertises the
    "UTF8=ACCEPT" capability, it informs the client that it supports
    UTF-8 in quoted-strings with the following syntax:

         quoted        =/ DQUOTE *uQUOTED-CHAR DQUOTE
                ; QUOTED-CHAR is not modified, as it will affect
                ; other RFC 3501 ABNF non terminal.

         uQUOTED-CHAR  = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4

         UTF8-2        =   <Defined in Section 4 of RFC3629>

         UTF8-3        =   <Defined in Section 4 of RFC3629>

         UTF8-4        =   <Defined in Section 4 of RFC3629>

    When this extended quoting mechanism is used by the client, then the 
server
    MUST reject octet sequences with the high bit set that fail to comply
    with the formal syntax in [RFC3629] with a BAD response.

    The IMAP server MUST NOT send UTF-8 in quoted strings to the client 
unless
    the client has indicated support for that syntax by using the "ENABLE
    UTF8=ACCEPT" command.

    If the server advertises the "UTF8=ACCEPT" capability, the client MAY
    use extended quoted syntax with any IMAP argument that permits a string
    (including astring and nstring).  However, if characters outside the
    US-ASCII repertoire are used in an inappropriate place, the results
    would be the same as if other syntactically valid but semantically
    invalid characters were used.  Specific cases where UTF-8 characters
    are permitted or not permitted are described in the following
    paragraphs.

    All IMAP servers that advertise the "UTF8=ACCEPT" capability 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.  Mailbox names MUST comply with
    the Net-Unicode Definition (Section 2 of [RFC5198]) with the specific
    exception that they MUST NOT contain control characters (0000-001F,
    0080-009F), delete (007F), line separator (2028), or paragraph
    separator (2029).

    An IMAP client MUST NOT issue a SEARCH command that uses a mixture of
    UTF-8 in quoted strings and a SEARCH CHARSET other than UTF-8. If an 
IMAP
    server receives such a SEARCH command, it SHOULD reject the command
    with a BAD response (due to the conflicting charset labels).

(And add back the removed references: RFC 2088 and RFC 5198)


4.  IMAP UTF8 Append Data Extension

  [...]

         utf8-literal   = "UTF8" SP "(" literal8 ")"

It might be worth adding here:

          literal8 = <Defined in RFC 4466>