Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Jun 2006 12:45:12 +0100

On Wed, 14 Jun 2006 15:18:33 +0100, Xiaodong Lee <[email-masked]> wrote:

> 3.There are still some scenarios that we may consider in the document.

We need a scenario where a message/rfc822 object in utf8 form is sent as  
an attachment. I shall write an example of this.

> 6.It is better that the editor can put some utf8header examples in the
> document. Because the current ASCII ID formt cannot support utf-8, the
> editor may submit a PDF version of his draft in addition to the ASCII  
> one.

I seem to remember a proposal to allow iso-8859-1 in drafts and RFCs. Does  
anyone know if that was ever agreed? That would be good enough for our  
purpose (in any case, any examples would need to use some set of  
characters that most people worldwide would recognise and be able, more or  
less, to pronounce). So we should stick to examples in French, German,  
Norwegian and so on which just use Latin letters with assorted accents  
over them.
>
> For smtpext document
> 7.Some profiles such as SASLprep may be used in the local part of the
> email address, but we should start out by being permissive, discover
> what the problems are and forbid that while doing implementaion
> experiences. There was considerable uncertainty on how much the EAI
> specification should try to police the content of the local part.

I think it is clear that we need some form of *-prep, and certainly need  
NFKC. I just had a look though the SASLprep standard (RFC 4013) and it  
certainly looks about right. Allowing any of the things that it proposes  
to forbid would certainly make it harder to pass the telephone and fax  
tests. I propose that we should write SASLprep into our drafts, with a  
note that it may be reviewed before the final draft in the light of actual  
experience. My view is that anything we eventually choose will need to be  
more stringent than SASLprep, rather than less.

> 8.Using the below form defined in rfc2821 to define the mail and rcpt
> commends may not work.
> MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
> RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

Surely we just define <utf8-reverse-path> and <utf8-forward-path> (which  
include the existing <*-path>s, and say that they MUST NOT be used unless  
the UTF8SMTP capability is advertised.

> For IMAP/POP documents
> 15.The IMAP document mentions the upgrading. Those who care about
> upgrading should read that section carefully to check that it says what
> you think it should say.

I think upgrading needs a mention in the downgrade document, if only to  
tell you when _not_ to use it. But it also needs to be made clear what it  
can be expected to do. Certainly, if you upgrade a downgraded document,  
you cannot expect to retrieve exactly the original (because the original  
might have already contained some RFC2-47-encoded stuff, which the upgrade  
might upgrade for you, and some addresses that were replaced by  
ALT-ADDRESSES might be irrecoverable).

OTOH, we can be more clear about the reverse process. In fact, we should  
be able to say that
    for all messages X downgrade(upgrade(X)) == X
Is that achievable?

> 23.Terminologies Option : In the past, multiple short names have been
> used for this effort: EAI, I-email , i18nemail, utf8email, emailing,
> IMX, IMAE, utf8smtp, ismtp. The WG needs to decide on one; in the
> absence of compelling technical arguments for one or the other, the
> meeting decided to take a straw poll to get a decision to present to the
> mailing list.

I think the problem was that some of the alternatives that have been  
mentioned, such as I-email, Iemail, I18Nemail, I18email I14Nemail (where  
did the 14 come from?) are just too similar for anyone to remember which  
was which, and they are not particularly easy to pronounce, either. So I  
had already concluded that something with "UTF" in it would be far better.  
The meeting seems to have agreed with that.

> Utf8smtp(4), i18nemail(4), utf8email(1), IMX(1), IMAE(1), ismtp

However, we should hope that our lead in using raw UTF8 is going to be  
followed by other protocols (Netnews is the obvious example, but I am sure  
there will be others). But it would be nice if all the protocols that  
followed us could use the same name for the capability that they  
advertised. That rules out any use of "smtp" or even "email" in the word.

> In the second round voting for the two favor: Utf8smtp, i18nemail. the
> result is
> Utf8smtp(5), i18nemail(3)

So I would prefer the first to the second, but my real preference would be  
for
either "Utf8" on its own, or for "Utf8headers".

I note that our IMAP draft currently uses "UTF8" (remember that IMAP is  
also supposed to work for Netnews).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   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

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 23 Jun 2006 14:07:08 +0100

On Thu, 22 Jun 2006, Charles Lindsey wrote:
> anyone know if that was ever agreed?

Using non-ASCII Characters in RFCs: draft-hoffman-utf8-rfcs-01.txt
(dated December 1, 2005, expires June 4, 2006).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
WHITBY TO THE WASH: WEST OR SOUTHWEST 3 OR 4 BACKING SOUTH LATER TODAY, THEN
BECOMING VARIABLE TONIGHT. OCCASIONAL RAIN. MAINLY GOOD. SMOOTH, OCCASIONALLY
SLIGHT IN OPEN WATER.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Jun 2006 07:23:56 -0700

>(dated December 1, 2005, expires June 4, 2006).

This was not accepted. Internet Drafts and RFCs are still ASCII-only, 
and will remain so for the foreseeable future.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Jun 2006 12:35:50 -0400

--On Thursday, 22 June, 2006 12:45 +0100 Charles Lindsey
<[email-masked]> wrote:

> We need a scenario where a message/rfc822 object in utf8 form
> is sent as  an attachment. I shall write an example of this.

Charles,

As you do this, please remember the "no multiple encodings"
rule.  I agree that there is a requirement for this (simple
forwarding would force it), but it is not straightforward.  I
haven't had time to write it up, but have come to suspect that
the best path might be to design something more like

  multipart/i18n-message;  boundary="foo--"
     foo--
     message/i18n-headers
     content-transfer-encoding: base64   (if needed)
        ....
     foo--
     ... message body with whatever content-types and CTE are 
       needed.
     --foo--

than like a simple message type.  I haven't researched, and
don't know off the top of my head, whether one could design a
message/ subtype to do this instead or resulting to multipart,
but you get the general picture.

     john

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 Jun 2006 10:17:03 +0100

> rule.

Not sure what you mean by the "no multiple encodings" rule.

If you mean that a CTE MUST NOT have another CTE hidden inside it, then  
yes. But my example did not contain that, and neither did my solution.

The underlying problem is that when they invented MIME, they arranged for  
"bodies" to be CT-encoded and for assorted charsets to be used inside  
them, but they assumed that all "headers" would remain in ASCII for ever.  
That included the headers (Content-*) that introduced each part of a  
multipart, and also the email headers of a message/rfc822. That basic  
assumption is, of course, the one that this WG is now trying to overturn.

My example illustrated two separate problems (maybe I would have been  
better to have given two examples).

1. A Content-Disposition with a utf8 filename parameter (that example  
needed to be within a multipart to cause the problem).

2. A message/rfc822 for an email message with utf8 headers. The fact that  
it was in a multipart was purely incidental - the problem would have  
arisen even if the message/rfc822 has been the sole thing in the body of  
the email.

>  I agree that there is a requirement for this (simple

That seems a complicated way to solve the problem. Existing MUAs know all  
about message/rfc822, and with no modification beyond what we have already  
discussed for Utf8smtp, they are going to try to create message/rfc822's  
with utf8 in their headers. And as far as those MUAs are concerned, it  
will just work (at both ends). And in a path where every MTA en route  
supports 8BITMIME (as most do these days), it will just work.

So it seems to be better to build on that, and simply to downgrade (or  
bounce) the message/rfc822 using exactly the same rules as for downgrading  
the main top-level email.

-- 
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