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

[Alexey Melnikov <[e-mail]>]

On 20/12/2011 05:22, Joseph Yee wrote:
> On 2011-12-07, at 3:17 PM, Alexey Melnikov wrote:
>
>> 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.
> +1 for the suggestion
>
>> 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.
> Suggest to replace the above paragraph with the following text:
>
> If IMAP clients that do not issue "ENABLE UTF8=ACCEPT" or "ENABLE UTF8=ONLY", IMAP servers MUST reject an APPEND command that includes any 8-bit in the message headers with a "NO" response.
I think this is a small change to the extensions, but I am Ok with it (I 
don't have any strong feelings either way). To improve wording a bit, I 
suggest:

IMAP servers that advertise support for "UTF8=ACCEPT" or "UTF8=ONLY" 
MUST reject an APPEND command that includes any 8-bit in the message 
headers with a "NO" response, when IMAP clients do not issue "ENABLE 
UTF8=ACCEPT" or "ENABLE UTF8=ONLY".
>> 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.
>>
> Yes, UTF8 should have "Intended usage: COMMON" and UTF8ONLY should be "Intended usage: OBSOLETE".
Right. And the "LIST-EXTENDED option description" needs to be correct 
accordingly.

  [...]