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

[Alexey Melnikov <[e-mail]>]

On 06/12/2011 02:43, Sean Shen 沈烁 wrote:
> Dear EAIers,
> The revised draft tries to reflect the following decisions in last eai meeting:
>
> "    - Tentative agreement not to extend LOGIN.
>      - Tentative agreement to remove up-conversion as a requirement.
>      - Apparent agreement to solve issue in section 3.3 by including
>        literals.
> "
>
> Your comments will be helpful!
Hi Sean,
I think you've updated the section about LOGIN and a couple of other 
sections incorrectly.
Here are the detailed comments on -02 that try to correct that:

3.3.  UTF-8 LIST and LSUB Responses

    After an IMAP client successfully issues an "ENABLE UTF8=ACCEPT"
    command, the server MUST NOT return in LIST results any mailbox names
    to the client following the IMAP4 Mailbox International Naming
    Convention.  Instead, the server SHOULD return any mailbox names with
    characters using utf8-quoted syntax.

You've changed  MUST to SHOULD here. While this is Ok, I don't think it 
is optimal, as it doesn't explain in which cases the SHOULD can be 
violated. I suggest the following replacement:

   Instead, the server MUST return any mailbox names with
   characters using either utf8-quoted or literal syntax.

In Section 4:

    IMAP servers that do not advertise the "UTF8=ACCEPT" or "UTF8=ONLY"
    capability SHOULD reject an APPEND command that includes any 8-bit in
    the message headers with a "NO" response.

This text seems to be placing requirements on servers that don't 
implement this specification. Because implementors who don't implement 
this specification are unlikely to read this specification, we can't do 
that. I suggest dropping the whole paragraph.

In Section 5.  LOGIN Command and UTF-8

    If the "UTF8=ACCEPT" capability is advertised, that indicates the
    server accepts UTF-8 user names and passwords and applies SASLprep
    [RFC4013] to both arguments of the LOGIN command.  The server MUST
    reject UTF-8 that fails to comply with the formal syntax in RFC 3629
    [RFC3629] or if it encounters Unicode characters listed in Section
    2.3 of SASLprep RFC 4013 [RFC4013].

    Although this makes it syntacically legal to have a UTF-8 user name
    or password, there is no guarantee the user provisioning system used
    by the IMAP server will allow such identities.  This is an
    implementation decision and MAY depend on what identity system the
    IMAP server is configured to use.

The proposal was not to extend the LOGIN command and instead use the 
AUTHENTICATE command which already supports UTF-8 usernames and 
passwords. So, I suggest replacing the whole section to read:

    This specification doesn't extend the IMAP LOGIN command [RFC3501]
    to support UTF-8 usernames and passwords. Whenever a client needs
    to use UTF-8 username/passwords, it MUST use the IMAP AUTHENTICATE
    command which is already capable of passing UTF-8 user names and 
credentials.

Or something like this.


In Section 8:

    1.  LIST-EXTENDED option name: UTF8

        LIST-EXTENDED option type: SELECTION

        Implied return options(s): UTF8

        LIST-EXTENDED option description: Part of previous experiment, no
        longer used.

You obsoleted the wrong selection option: you should have obsoleted
the UTF8ONLY (listed below), not this one. So please undo the change to 
this option.

        Published specification: RFC 5738bis, Section 3.4.1

        Security considerations: RFC 5738bis, section 9

        Intended usage: OBSOLETE

        Person and email address to contact for further information: see
        the Authors' Addresses at the end of this specification

        Owner/Change controller: [e-mail]

    2.  LIST-EXTENDED option name: UTF8ONLY

        LIST-EXTENDED option type: SELECTION

        Implied return options(s): UTF8

        LIST-EXTENDED option description: Causes the LIST response to
        include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter
        and exclude mailboxes that do not support the UTF8 SELECT/EXAMINE
        parameter.

I might send a couple of extra changes in a separate email.

Best Regards,
Alexey