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

[John C Klensin <[e-mail]>]

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
<[e-mail]> wrote:

> 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
> 
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima