Subject: Re: [EAI] draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 02 Apr 2007 12:21:45 +0100

On Fri, 30 Mar 2007 18:51:56 +0100, Harald Tveit Alvestrand  
<[email-masked]> wrote:

> --On 29. mars 2007 11:49 +0100 Charles Lindsey <[email-masked]>  
> wrote:

>> Firstly, the term defined is "UTF-8 header", not "UTF-8 header field".
>>
>> The definition is:
>>
>>     In this document, header fields are "UTF-8 headers" if the bodies of
>>     those headers contain UTF-8 characters.
>>
>
> Charles, we went over this in USEFOR.
>
> According to RFC 2822, a "header field" is a single (possibly folded)  
> line - consisting of a header field name and a header field value.

No! No! "UTF-8 header" is the term that Jeff Yeh currently defines in  
Utf8headers (actual text quoted above). It is him you should be  
complaining to. I agree it ought to be changed.

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

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 02 Apr 2007 12:37:37 +0100

On Sat, 31 Mar 2007 11:41:38 +0100, Frank Ellermann  
<[email-masked]> wrote:

> Charles Lindsey wrote:
>
>> That all depends whether we are going to define message/utf8 or not.
>> All suggested definitions of that type so far are EXPRESSLY FORBIDDEN
>> by RFC 2045.
>
> It's "only" a SHOULD, and necessarily EAI is an excuse to violate it.

RFC 2119 does not define the term "EXPRESSLY FORBIDDEN", but I would  
imagine its meaning is at least as strong as "MUST NOT", and probably  
stronger.
>
>> Personally, I want to allow UTF8 messages to be sent as message/rfc822
>
> That gives you MIME 1.0 as is with RFC 2049 as is, and the whole EAI
> effort should IMNSHO never survive something like an IETF Last Call.

-1

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 Apr 2007 22:24:05 +0200

> imagine its meaning is at least as strong as "MUST NOT", and probably

The EXPRESSLY FORBIDDEN is about CTEs different from 8bit, 7bit, or
binary for composite types (multipart/* or message/* at the moment),
it's on line 926 of RFC 2045.

The "SHOULD" is actually only a "should" about using 7bit for message/*
subtypes in section 5.2.4 in RFC 2046.  In other words a message/utf-8
using 8bit does not violate an upper case SHOULD, and it also doesn't
come into any conflicts with the EXPRESSLY FORBIDDEN in RFC 2045.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 03 Apr 2007 10:10:29 +0100

> come into any conflicts with the EXPRESSLY FORBIDDEN in RFC 2045.

But it would conflict with that EXPRESSLY FORBIDDEN if you tried to  
downgrade it as envisaged in the current DSN draft. So how would you  
propose to downgrade it?

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 03 Apr 2007 19:08:00 +0200

> downgrade it as envisaged in the current DSN draft.

The DSN draft is at -00, it's far from ready, it captures the basic ideas
and most issues that have to be addressed in the next rounds of this I-D.

> So how would you propose to downgrade it?

Downgrading a message/utf-8 will be explained in the "downgrading" I-D
for 8BITMIME-to-7BIT gateways knowing what a message/utf-8 is.  If they
don't know this they can either give up, or use a radical approach like
application/message.

We're talking about DSNs concerning messages originally sent from an MSA
supporting UTF8SMTP.  The forward route somehow reached a hop triggering
a DSN, e.g. an ordinary non-delivery report ("bounce").

Now that DSN is returned to the originator "as indicated in the reverse-
path".  There's no problem if the event triggering the DSN was at a 7BIT
mailer, somehow the original message/utf-8 was already "downgraded" to a
7BIT message/rfc822 on the forward route in this case.

Similarly the message was already 8BITMIME if the event triggering a DSN
was at an 8BITMIME mailer, the message/utf-8 was already "downgraded" to
an 8BITMIME message/rfc822 on the forward route in this case.

Therefore we only need to worry about the original message/utf-8 at an
UTF8SMTP capable relay triggering a DSN (e.g. if there's no way forward
for UTF8SMTP, and no way to downgrade the message).

This UTF8SMTP mailer will then be forced to send an UTF8SMTP DSN to an
UTF8SMTP originator.  Unfortunately with 2821-SMTP it's possible that
the reverse route is very different from the forward route, and it can
hit a hop that does not support UTF8SMTP.

If that hop still supports 8BITMIME we're fine, the message/utf-8 part
in the DSN can be downgraded as specified in the "downgrading" I-D (not
yet ready, but no showstopper in sight).

The one and only _bad_ situation is a 7BIT relay on the reverse path.
But we still know that "something" (the MSA and likely the MUA) on the
side of the originator did support UTF8SMTP.  Therefore the DSN only
has to be "tunneled" through this (IMO very unlikely) 7bit hop on the
reverse route.  For that a new MIME type like application/message can
be used to encapsulate any 8bit message/* subtype, not limited to the
message/utf-8 part in the DSN.

If that fails the DSN is rejected (= lost), tough.  UTF8SMTP senders
should make sure that they don't employ 7BIT relays on any routes
associated with their reverse path.  It's no unheard of situation,
senders will learn to get this right.

Last but not least the (IMO unlikely) 7BIT hop in the reverse path
can be on the side of the receiver.  In that case it's an error of
the receiver, they accepted mail in a form that they can't reliably
return if necessary.  They shouldn't do this, like they shouldn't
accept SPF FAIL / mail worms / spam / ...

As you said elsewhere 7bit hops are supposed to die out really soon
now, especially on routes somehow associated with UTF8SMTP routes.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 04 Apr 2007 11:02:31 +0100

> for UTF8SMTP, and no way to downgrade the message).

Yes, that is the interesting case from a DSN POV. I already commented ion  
it in my earlier response to that DSN draft (Comments on the DSN draft  
(draft-ietf-eai-dsn-00.txt on March 7th).
> yet ready, but no showstopper in sight).

No we're not fine, because the hop after that might be to Non-8BITMIME.
> reverse route.

It's unlikely, but that does not make it impossible.

The easiest solution AFAICS is to send the returned message as a  
message/rfc822 (UTF8SMTP-universe version). We are gong to need a  
downgrade mechanism for that beast in any case (essentially, you  
recursively descend through it and downgrade such UTF8SMTP headers, or  
whatever we decide to call them, as they are found).

If you are just returning headers, then they are sent as a  
text/utf-8-headers (or maybe even the existing text/rfc822-headers if you  
can get away with adding a charset parameter to it). Text/* types are  
already downgradable by current 8BITMIME downgraders.

And for the delivery status itself you need a message/utf8-delivery-status  
(or rather an application/utf8-delivery-status because it is easier to  
write a downgrade for it) or maybe an extended version of the existing  
message/delivery-status (but that extension might be tricky).

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 04 Apr 2007 20:34:31 +0100

> don't know this they can either give up, or use a radical approach like

Yes, you keep saying that it will be downgraded, as if this were a solved
problem.

I have repeatedly asked you to state plainly what you mean by a
"message/utf-8" and exactly how you would propose to downgrade it. It is
no use continuing to discuss it unless you are willing to do that. At
present, it is just vapourware.

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 6 Apr 2007 14:37:38 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 2:17 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#2): 2.1. Framework for theInternationalization Extension

> (7) the maximum length of a MAIL FROM and RCPT TO command line is 
>     increased by 268 characters by the possible addition of the 
>     ALT-ADDRESS keyword and value

according to RFC 2821,

  local-part
      The maximum total length of a user name or other local-part is 64
      characters.

   domain
      The maximum total length of a domain name or number is 255
      characters.

   command line
      The maximum total length of a command line including the command
      word and the <CRLF> is 512 characters.  SMTP extensions may be
      used to increase this limit.

for example,  mail from : <utf8@utf8> alt-address=xtext(local part +@+domain part)
the possible lenght increase may be 
 64*2+1+256=485

is it ok?

YAO Jiankang
CNNIC

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 6 Apr 2007 14:50:13 +0800

----- Original Message ----- 
From: "YAO Jiankang" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, April 06, 2007 2:37 PM
Subject: Re: [EAI] draft-ietf-eai-smtpext-04.txt: (#2): 2.1. Framework fortheInternationalization Extension

> the possible lenght increase may be 
correction, 
should add alt-address length 12

so the total is    "localPart"*2+"@"+"domainPart+alt-address="   equale 64*2+1+255+12=396

YAO Jiankang
 CNNIC

--------------------------------------------------------------------------------

---

From: Chris Newman <[email-masked]>
Date: Mon, 09 Apr 2007 12:01:13 -0700

Charles Lindsey wrote on 3/26/07 14:52 +0100:
> We have already been through this once, and Crhis Newman agreed, On Feb  16th:
>
>     "Ok, I've been convinced application/utf-8-message is a safer label for
>      the type."

While that statement remains true.  I'll also observe that an experiment need 
not choose the safer course.

Regardless, I have passed primary editing responsibility to Alexey and I plan 
to recuse myself during IESG evaluation of this document.

                - Chris