Subject: [EAI] EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models

From: John C Klensin <[email-masked]>
Date: Thu, 09 Feb 2012 07:15:23 -0500

WG participants,

My last note covered the status of the documents we have
approved but that are not yet published.    This one is an
attempt to summarize where we are --and, more important, what
people should be doing-- going forward (starting now).

With the core documents out of the WG's hands, people should
turn their attention to the POP, IMAP, and downgrade sets,
including examining the current documents.  The WG and authors
of the IMAP and POP documents should think about how to modify
those documents to accommodate multiple downgrade models, some
of which might still be unspecified when the POP and IMAP
documents are published.

We are also looking for an I-D on the stripped-down downgrade
option suggested by Arnt, John Leslie, and others and for
author(s) for an I-D on the pseudo-DSN for "you don't get this
message until you upgrade" option.   As I indicated in an
earlier note, I think those two, plus an updated version of
pop-imap-downgrade, would form the core of the new strategy.
That strategy is a hypothesis, not a conclusion: those with
other ideas should speak up.

Anyone who believes the WG needs a formal consensus call on
moving in the direction of multiple downgrade options should say
so (private notes to Joseph and/or myself would be sufficient;
if it is desired, I'd prefer to just do a consensus call rather
than spend time debating whether or not it is necessary).

   john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 9 Feb 2012 13:59:04 +0100

On 02/09/2012 01:15 PM, John C Klensin wrote:
> option suggested by Arnt, John Leslie, and others

I'll happily write one.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 9 Feb 2012 16:33:04 +0100

>> option suggested by Arnt, John Leslie, and others

I hate having TODOs and couldn't concentrate on programming anyway.

My new desktop isn't properly set up for RFCs yet; appended is a protodraft.

Arnt

---

From: Kazunori Fujiwara <[email-masked]>
Date: Fri, 10 Feb 2012 01:59:57 +0900 (JST)

Starting with old document may work well. MIME encapsulation is easy.

  http://tools.ietf.org/html/draft-ietf-eai-downgrade-01

Or, another downgraded message may contain multi parts

  part1 (main part): message/delivery-status ? text/plain; charset=ascii ?
                     Error message
                     a message to update receiver's MUA

  part2:             text/plain; charset=utf-8
  
                     header fields of the non-ascii message
		     some of lines of the body  of the non-ascii message

  part3:             message/global?

                     The original non-ascii message which may contain multipart
                     # However RFC 2045 disallow nested encoding.

> From: Arnt Gulbrandsen <[email-masked]>
>                   EAI: Simplified POP/IMAP downgrading
>               draft-gulbrandsen-eai-simpledowngrade-00.txt
> 
>    "[email-masked] <[email-masked]>" or "Fred
>    <[email-masked]>".

Before you use 'invalid' TLD, you should reserve 'invalid' TLD
even if you use it as an example.

> 3.2 Mime values and comments
> 
>    Any mime field (whether in the message header or a bodypart header)
>    which cannot be presented as-is to the client is silently excised
>    along with its name.
> 
>    Given a field such as "Content-Disposition: attachment; filename=foo;
>    signed-off-by=[email-masked]", the field is presented as "Content-
>    Disposition: attachment; filename=foo".

MIME header fields are easily converted by RFC 2231.

> 3.3 Remaining header fields
> 
>    Any header field which cannot be presented to the client even after
>    the modifications in sections 3.1 and 3.2 is silently excised.

Do you mean deleting 'Subject:' header fields which contains non-ASCII
character?

--
Kazunori Fujiwara

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 9 Feb 2012 20:23:07 +0100

>   http://tools.ietf.org/html/draft-ietf-eai-downgrade-01

Perhaps. I found it quick and easy to write what I wanted to say (using
the source of a quite different draft for the boilerplate).

> even if you use it as an example.

RFC 2606 reserves it.

> MIME header fields are easily converted by RFC 2231.

Many things are easily done; the sum isn't easy any more. This draft is
about specifying a minimal proposal. In that context, even easy
conversions must be individually justified.

> Do you mean deleting 'Subject:' header fields which contains non-ASCII

Hm. That omission comes from my code, where subject is orthogonal to
EAI. I had to take care of unlabelled 8-bit subject fields already
(there are many in the wild), therefore I didn't need to add that for EAI.

I guess it should go in.

Thank you for your comments.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2012 21:41:14 -0000

Looks pretty reasonable to me.  Perhaps add a sentence allowing but
not requiring servers to beautify headers if they want, e.g., turn
UTF-8 into MIME, but stress that it is OPTIONAL and the primary goal
here is to let the user know he or she has mail that the MUA can't
handle.

R's,
John