Subject: Re: [EAI] Comments on draft--eai-pop-00

From: Chris Newman <[email-masked]>
Date: Mon, 10 Jul 2006 08:20:38 -0700

Charles Lindsey wrote on 6/30/06 17:16 +0100:
> 3.  UTF8 Capability
>
>     ... The retrieved message MUST still be textual
>     and otherwise formatted according to RFC 2822 [RFC2822] and MIME
>     [RFC2045].
>              ^
>            as extended by [utf8headers]

This change seems redundant to me given I mentioned that reference in the first 
sentence of the section.

> 5.  Up-Conversion Server Requirements
>
> It is interesting that you have chosen to include up-conversion at the POP
> level, since I had always assumed this would be a function of the MUA  (they
> are already in the business of up-converting RFC 2047 stuff, and  even RFC
> 2231 stuff if they are doing a proper job). Moreover, MUAs which  take good
> 'ol mbox format as their input will still need to know how to  up-convert.
>
>     The following charsets MUST be supported for up-conversion of MIME
>     header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2,
>     ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7,
>     ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15.
>     Other widely deployed MIME charsets SHOULD be supported.
>
> Why do you want to support the ISO-8859-*? We are primarily concerned with
> UTF-8 here, so I would have thought the others were no more than SHOULD.

MIME mail agents are required to support those charsets per RFC 2049.  If our 
goal is to migrate towards a UTF-8 only mode of operation, then we need to 
up-convert the mandatory charsets to UTF-8.  And it's best to do it at the 
final delivery agent or POP server where it's more likely to be done correctly. 
Mail user agents have a long history of implementing RFC 2047 in a 
non-interoperable fashion, so the more we can do to prevent them from ever 
seeing it, the better.

What makes me excited about EAI is that we can deprecate most use of RFC 2047 
which will actually improve interoperability, so I consider that an important 
secondary goal of the EAI effort.

>     ... and MAY/SHOULD support various other headers {to be discussed},
> including things previously downgraded by RFC 2231.

So if I understand your comment correctly, you want to upgrade the following 
text:

>     While this specification does not require it, server implementations
>     are encouraged to up-convert all MIME body headers, and particularly
>     the deprecated (and misused) name parameter [RFC1341] on Content-Type
>     and the Content-Disposition [RFC2183] filename parameter.  These may
>     be encoded using the standard MIME parameter encoding [RFC2231]
>     mechanism, or via non-standard use of MIME header encoding [RFC2047]
>     in quoted strings.

to a "SHOULD"?

FWIW, I was uncomfortable telling POP servers they SHOULD implement a MIME 
parser.  While I consider a MIME parser a very simple and lightweight piece of 
code (that took me less than a day to write), that attitude is not shared by 
other implementers.  How do other people feel about this?

>     Servers are also encouraged to up-convert the headers on embedded
>     message/rfc822 body parts [TBD-ref].  Servers MAY convert the charset
>     on MIME body parts to UTF-8, and MAY remove quoted-printable or
>     base64 encodings as long as the resulting text complies with the
>     requirements of the 8-bit content-transfer-encoding [RFC2045].
>
> I am pleased to see that someone else is interested in those MIME body
> headers and message/rfc822 headers. All we need now is to get them  included
> in the 'downgrade' document :-) .

The downgrade document is certainly incomplete until it discusses these issues.

                - Chris

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 10 Jul 2006 19:32:21 +0100

------- Forwarded message -------
From: "Chris Newman" <[email-masked]>
To: "Charles Lindsey" <[email-masked]>, [email-masked]
Subject: Re: [EAI] Comments on draft--eai-pop-00
Date: Mon, 10 Jul 2006 16:20:38 +0100

> This change seems redundant to me given I mentioned that reference in  

Yes, but somebody will read that wording as undoing the good you did  
earlier. Taken on its own, and taken too literally, it could be  
misunderstood. All it needs is an "as extended" inserted at an appropriate  
place.

> MIME mail agents are required to support those charsets per RFC 2049.

OK, point taken.

> non-interoperable fashion, so the more we can do to prevent them from  

And are POP3 agents notably better?>

> to a "SHOULD"?

Yes, that would help, though I would not want to give any comfort to those  
who try to use RFC 2047 where RFC 2231 ouught to have been used. Also, if  
we prescribe the use of IRIs in the List-* headers (with the obvious  
diwngrade), do we want to be encourgaging the upgrading of URIs to IRIs in  
appropriate cases?

> other implementers.  How do other people feel about this?

If you are going to do it, then do it properly. Maybe that is a way to get  
UTF8smtp up and running without waiting for MUAs to be fully upgraded, but  
OTOH I suspect all those MUAs are going to need upgrading in any case -  
indeed they should already be parsing such MIME as comes their way. The  
chief problem with current MUAs, I suspect, is that although they display  
MIME stuff as received, they are mush less likely to construct correct  
MIME for stuff they generate :-( .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "abel" <[email-masked]>
Date: Tue, 11 Jul 2006 10:21:11 +0800

> other implementers.  How do other people feel about this?
I had some different idea when I implement  our EAI trial ,
when the POP3 client login UTF8-name (pass UTF8-name) , POP3 service 'RETR
command' returns MUA a EAI mail content,
if  MUA login as US-ASCII name , POP3 returns mail as Downgraded (downward
compatibility for current MUA).
The US-ASCII name can be MIME or Punycode , and the name point to same UTF8
mailbox,
Considering and supporting current MUA is benefits

Regards

Abel

---

From: Chris Newman <[email-masked]>
Date: Tue, 11 Jul 2006 07:12:52 -0700

Overloading the semantics of the user name to determine whether the protocol is 
eai-aware is an ugly kludge and doesn't work in general because people with 
ascii-only names will want to use EAI and the POP AUTH command already permits 
UTF-8 user names in non-EAI POP.

An alternative proposal where we add a "UTF8 ON" command to POP3 which switches 
the existing POP3 commands to 8BIT mode is worth considering.  It has the 
advantage of potentially fewer changes to POP clients, but the disadvantage of 
being a hard modal switch in the protocol so it's less flexible than the 
current proposal and more likely to be implemented incorrectly.  I'm certainly 
open to a debate contrasting an explicit modal switch command to the parallel 
command approach.

                - Chris

---

From: Randall Gellens <[email-masked]>
Date: Tue, 11 Jul 2006 06:21:28 -0700

At 8:20 AM -0700 7/10/06, Chris Newman wrote:

>  FWIW, I was uncomfortable telling POP servers they SHOULD implement 
> a MIME parser.  While I consider a MIME parser a very simple and 
> lightweight piece of code (that took me less than a day to write), 
> that attitude is not shared by other implementers.  How do other 
> people feel about this?

Well, Qpopper has a MIME parser (as part of it's so-called 
mime-mangling support).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Never ask two questions in a business letter.  The reply will
discuss the one you are least interested in and say nothing about
the other.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 11 Jul 2006 06:26:29 -0700

>  Considering and supporting current MUA is benefits

I apologize, but I am a bit confused: the text you quoted is Chris 
asking about the burden of implementing a MIME parser, but your reply 
seems to propose an alternative to the use of new commands in place 
of RETR/TOP.  In regards to this proposal, I'd prefer Chris' approach 
of new commands to make things explicit, rather than having it be 
implicit based on the login name.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Any smoothly functioning technology will be
indistinguishable from a rigged demo.  --Isaac Asimov

---

From: Randall Gellens <[email-masked]>
Date: Tue, 11 Jul 2006 06:21:28 -0700

---

From: Randall Gellens <[email-masked]>
Date: Tue, 11 Jul 2006 06:26:29 -0700