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

[Alexey Melnikov <[e-mail]>]

On 10/07/2012 23:32, Joseph Yee wrote:
> Hi all,
>
> This is the WG Last Call of the following four documents:
  [...]
> draft-ietf-eai-5738bis-04
>      IMAP Support for UTF-8
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