Subject: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade

From: Joseph Yee <[email-masked]>
Date: Tue, 10 Jul 2012 18:32:14 -0400

Hi all,

This is the WG Last Call of the following four documents:

draft-ietf-eai-rfc5721bis-05
    POP3 Support for UTF-8

draft-ietf-eai-5738bis-04
    IMAP Support for UTF-8

draft-ietf-eai-popimap-downgrade-06
    Post-delivery Message Downgrading for Internationalized Email Messages

draft-ietf-eai-simpledowngrade-05
    EAI: Simplified POP/IMAP downgrading

The Last Call runs for 1 week - from Tuesday July 10 22:00 UTC to
Tuesday July 17 23:59 UTC.

Regards,
Joseph Yee, co-chair of EAI

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 12:52:27 +0100

> This is the WG Last Call of the following four documents:
  [...]
> draft-ietf-eai-5738bis-04
This document needs another revision: it has remains of removed 
functionality all over the remaining sections, in particular:

> 1.  Introduction
>
>    This specification extends IMAP4rev1 [RFC3501] to permit UTF-8
>    [RFC3629] in headers as described in "Internationalized Email
>    Headers" [RFC6532] .  It also adds a mechanism to support mailbox
>    names, login names, and passwords using the UTF-8 charset.

This document doesn't add UTF-8 login names/passwords, as this functionality
is already present in the AUTHENTICATE command.

> 3.  UTF8=ACCEPT IMAP Capability
>
>    The "UTF8=ACCEPT" capability indicates that the server supports UTF-8
>    quoted strings, the "UTF8" parameter to SELECT and EXAMINE,

UTF8 parameter to SELECT/EXAMINE was removed, so this is no longer 
correct. However something need to be said about SELECT/EXAMINE, so maybe:

--------
  the ability to open mailboxes containing EAI messages(*) with SELECT 
and EXAMINE,
--------

(*) - or whatever we call these beasts now...

> and UTF-8
>    responses from the LIST and LSUB commands.
>
>
> 4.  IMAP UTF8 Append Data Extension
>
>    If the "UTF8=ACCEPT" capability is advertised, then the server
>    accepts UTF-8 headers in the APPEND command message argument. A
>    client that sends a message with UTF-8 headers to the server MUST
>    send them using the "UTF8" APPEND data extension.  If the server also
>    advertises the CATENATE capability (as specified in [RFC4469]), the
>    client can use the same data extension to include such a message in a
>    CATENATE message part.  The ABNF for the APPEND data extension and
>    CATENATE extension follows:
>
>         utf8-literal   = "UTF8" SP "(" literal8 ")"
>
>         append-data    =/ utf8-literal
>
>         cat-part       =/ utf8-literal
>
>    A server that advertises "UTF8=ACCEPT" MAY fail for \NotUTF8
>    mailboxes with a NOT-UTF-8 response code.

Delete the above sentence, as this functionality was removed.

> If this command does not
>    fail, it MAY follow the requirements of the IMAP base specification
>    and [RFC5322] for message fetching.
>
> 6.  UTF8=ONLY Capability
>
>    The "UTF8=ONLY" capability permits an IMAP server to advertise that
>    it does not support the international mailbox name convention
>    (modified UTF-7), and does not permit selection or examination of any
>    mailbox unless the "UTF8" parameter is provided.
Delete everything starting from ", and does not permit".

> 8.  Issues with UTF-8 Header Mailstore
>
>    When an IMAP server uses a mailbox format that supports UTF-8 headers
>    and it permits selection or examination of that mailbox without the
>    "UTF8" parameter,
Remove "and it permits ... "UTF-8" parameter".
> it is the responsibility of the server to comply
>    with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with
>    respect to all header information transmitted over the wire.
>    Mechanisms for 7-bit downgrading to help comply with the standards
>    are discussed in [popimap-downgrade].

And finally, if we are making all sorts of other simplifications, can be 
please also drop the whole section 3.1 (as suggested by Dave Cridland 
and discussed by Arnt and myself)?

Thank you,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 13:10:53 +0100

> draft-ietf-eai-rfc5721bis-05
I've reviewed this document and it looks ready to me.
>      EAI: Simplified POP/IMAP downgrading
This looks Ok to me as well.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 13 Jul 2012 14:54:14 +0200

> and discussed by Arnt and myself)?

Uhm. I think you mean to drop the starry quote stuff and allow 
quoted-string to contain UTF8. Right? If so, a hearty +1 from me.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 14:10:41 +0100

On 13/07/2012 13:54, Arnt Gulbrandsen wrote:
> quoted-string to contain UTF8.
... after ENABLE UTF8=ACCEPT or ENABLE UTF=ONLY.
> Right? If so, a hearty +1 from me. 
Yes.

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Jul 2012 13:11:39 -0400

Grump.  All of this was supposed to be cleared up after the
Jabber chat.  It seems that we cannot get anyone to check the
specs until either there is an immanent meeting or a Last Call.  

So, Steve and/or Chris, when can we expect an update (noting the
Monday cutoff)?  Or should Joseph and I be looking for a new
editor?

    john

--On Friday, July 13, 2012 12:52 +0100 Alexey Melnikov
<[email-masked]> wrote:

> This document needs another revision: it has remains of
> removed functionality all over the remaining sections, in
> particular:
> 
>> 1.  Introduction
>> 
>>    This specification extends IMAP4rev1 [RFC3501] to permit
>>    UTF-8 [RFC3629] in headers as described in
>>    "Internationalized Email Headers" [RFC6532] .  It also
>>    adds a mechanism to support mailbox names, login names,
>>    and passwords using the UTF-8 charset.
> 
>>    The "UTF8=ACCEPT" capability indicates that the server
>>    supports UTF-8 quoted strings, the "UTF8" parameter to
>>    SELECT and EXAMINE,
> 
> UTF8 parameter to SELECT/EXAMINE was removed, so this is no
> longer correct. However something need to be said about
> SELECT/EXAMINE, so maybe:
> 
> --------
>   the ability to open mailboxes containing EAI messages(*)
> with SELECT and EXAMINE,
> --------
> 
>>    If the "UTF8=ACCEPT" capability is advertised, then the
>>    server accepts UTF-8 headers in the APPEND command message
>>    argument. A client that sends a message with UTF-8 headers
>>    to the server MUST send them using the "UTF8" APPEND data
>>    extension.  If the server also advertises the CATENATE
>>    capability (as specified in [RFC4469]), the client can use
>>    the same data extension to include such a message in a
>>    CATENATE message part.  The ABNF for the APPEND data
>>    extension and CATENATE extension follows:
>> 
>>    A server that advertises "UTF8=ACCEPT" MAY fail for
>>    \NotUTF8 mailboxes with a NOT-UTF-8 response code.
> 
>>    fail, it MAY follow the requirements of the IMAP base
>>    specification and [RFC5322] for message fetching.
>> 
>> 6.  UTF8=ONLY Capability
>> 
>>    The "UTF8=ONLY" capability permits an IMAP server to
>>    advertise that it does not support the international
>>    mailbox name convention (modified UTF-7), and does not
>>    permit selection or examination of any mailbox unless the
>>    "UTF8" parameter is provided.
>>    When an IMAP server uses a mailbox format that supports
>>    UTF-8 headers and it permits selection or examination of
>>    that mailbox without the "UTF8" parameter,
>>    with the IMAP4rev1 base specification [RFC3501] and
>>    [RFC5322] with respect to all header information
>>    transmitted over the wire. Mechanisms for 7-bit
>>    downgrading to help comply with the standards are
>>    discussed in [popimap-downgrade].
> 
> And finally, if we are making all sorts of other
> simplifications, can be please also drop the whole section 3.1
> (as suggested by Dave Cridland and discussed by Arnt and
> myself)?
> 
> Thank you,
> Alexey
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: "Jiankang Yao" <[email-masked]>
Date: Sat, 14 Jul 2012 12:34:05 +0800

----- Original Message ----- 
From: "Alexey Melnikov" <[email-masked]>
To: "Joseph Yee" <[email-masked]>
Cc: "EAI WG" <[email-masked]>
Sent: Friday, July 13, 2012 7:52 PM
Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, 
draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade

....
> please also drop the whole section 3.1 (as suggested by Dave Cridland and 
> discussed by Arnt and myself)?
>

If section 3.1 "IMAP UTF-8 Quoted Strings" is removed, that will give this 
document more simplifications.

I just checked section 3.1 and its relationship with other sections of this 
document, and found
that it is fine to remove the whole section 3.1.

Jiankang Yao

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 15 Jul 2012 10:40:26 +0100

On 14 Jul 2012, at 05:34, "Jiankang Yao" <[email-masked]> wrote:

> ----- Original Message ----- From: "Alexey Melnikov" <[email-masked]>
> Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade
> 
> 
> ....
>> 
>> And finally, if we are making all sorts of other simplifications, can be please also drop the whole section 3.1 (as suggested by Dave Cridland and discussed by Arnt and myself)?
>> 
> 
> If section 3.1 "IMAP UTF-8 Quoted Strings" is removed, that will give this document more simplifications.
> 
> I just checked section 3.1 and its relationship with other sections of this document, and found

I should have been more specific: the existing "quoted" string should have been extended to allow UTF-8. I propose some ABNF changes.