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

From: [email-masked]
Date: Sun, 04 Dec 2011 23:02:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title           : IMAP Support for UTF-8
	Author(s)       : Pete Resnick
                          Chris Newman
                          Sean Shen
	Filename        : draft-ietf-eai-5738bis-02.txt
	Pages           : 15
	Date            : 2011-12-04

   This specification extends the Internet Message Access Protocol
   version 4rev1 (IMAP4rev1) to support UTF-8 encoded international
   characters in user names, mail addresses and message headers.  This
   specification replaces RFC 5738.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-5738bis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-5738bis-02.txt

---

From: Sean Shen 沈烁 <[email-masked]>
Date: Tue, 6 Dec 2011 10:43:21 +0800

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!

Best,

Sean Shen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 05, 2011 3:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [EAI] I-D Action: draft-ietf-eai-5738bis-02.txt

_______________________________________________
IMA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 07 Dec 2011 20:17:38 +0000

> 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: [email-masked]

    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

---

From: Joseph Yee <[email-masked]>
Date: Tue, 20 Dec 2011 00:22:25 -0500

On 2011-12-07, at 3:17 PM, Alexey Melnikov wrote:

> I think you've updated the section about LOGIN and a couple of other sections incorrectly.
> 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:
> 

+1 for the suggestion

> 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.

> 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:
> 
>   command which is already capable of passing UTF-8 user names and credentials.
> 
> Or something like this.
> 
> 
> In Section 8:
> 
> the UTF8ONLY (listed below), not this one. So please undo the change to this option.
> 

Yes, UTF8 should have "Intended usage: COMMON" and UTF8ONLY should be "Intended usage: OBSOLETE".

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

Similar, there are some editorials and nits followup in separate email.

thanks
Joseph

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Dec 2011 12:27:13 +0000

> 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".
> 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.

  [...]