Subject: [EAI] REVIEW: utf8headers-07

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 25 Sep 2007 19:50:25 +0200

1.2:
| This document updates section 6.4 of RFC 2045.

Discussed in a separate issue.  EAI should need no
"experimental update" of MIME.  If it turns out that
the RFC 2045 restriction is in practice obsolete for
other purposes outside of EAI, we might need a "real
update" of MIME.

| This document also updates [RFC2822] and MIME

Ditto, an "experimental update" of RFC 2822 is okay,
but touching MIME (excl. the separate issue above)
is IMO unnecessary and too dangerous.

4.1:
| [Note in draft: Whether normalizing is needed or not
|  will be place in here.]

Please create a real note about this design decision,
and that it might be revised when the experiment is
evaluated.

4.2:
| This specification does not prohibit other
| content-transfer-encodings on nested body parts, so
| double encoding might happen, but is expected to be
| rarely seen in practice.

Quite so.  And if we'd use say an application/message
type for 7bit transport of a message/global, it would
be still a kind of double-encoding for parts "within"
the B64 or QP encoded message/global.  There's no way
around this.  It's only a question of "play it save
and follow the rules using an application subtype"
vs. "the rules are pointless for this application,
because the result is always QP or B64".

BTW, if we follow the rules we could also decree which
encoding should be always used, B64 might be robuster,
QP is nicer for humans, but QP of QP would be horrible.

| To be able to use UTF-8 characters in MIME header field
| paramerer values, the syntax of <value> , as defined in
| [RFC2045], is extended as
|
|  value   =/      utf8-quoted-string

Don't.  s/paramerer/parameter/, but better leave MIME
alone and let's experiment with _addresses_ and 2822
header fields, not with Content-*.

4.3:
| utf8-quoted-pair   = ("\" utf8-text) / obs-qp

Oops, what's the idea here ?  Why not keep quoted-pair
as is ?  You'd get (hex. example for \u+0080) 5C C2 80,
why not simply use C2 80 without backslash ?

| To able to use UTF-8 on Content-Description header field
| on [RFC2045], following syntax is used
|
| description   = "Content-Description:" unstructured CRLF

"To allow the use of UTF-8 in" ... "header fields specified
 in RFC2045, the following syntax is used:" (or similar).

Of course I propose to leave all MIME 1.0 Content-* alone.

| <utext> syntax is extended on next chapter to allow UTF-8
| characters on <unstructured> header fields.

"The <utext> syntax is extended to allow UTF-8 characters
 in <unstructured> header fields, for details see the
 following chapter" (or similar)

4.4:
| alt-address    =  1*FWS "<" addr-spec ">"

Don't get carried away, FWS will do, you don't want more than
one FWS in a row... ;-)

| Below list a few possible <mailbox> representation as example.

"Some examples of <mailbox> representations:" (or similar)

4.6:
s/UTF-8 header values/UTF-8 in header field bodies/ (?)

| o  it contains UTF-8 header values as specified in this document, or
| o  it contains UTF-8 values in the headers fields of body parts.

Remove the second clause and leave MIME part headers alone.

| The second type, used for content return, is message/global

That's no second type, it's the same thing transported a MIME
part of a DSN.  We're always talking about the one and only
message/global here, the derived types are discussed in the
DSN I-D.

| Subtype name:  utf8smtp
s/utf8smtp/global/ (JFTR, already noted by Charles and others)

| Encoding considerations:  The 8-bit or binary content-transfer-
| encoding MUST be used unless this media type is sent over a
| 7-bit only transport.

No, say "unless the message happens to be a 7bit message/rfc822".
That's clumsy, and related to the CTE issue.  If we stick to the
rules without "experimental update" we'd get:

"An 8-bit or binary content-transfer-encoding MUST be used when
 the message contains non-ASCII UTF-8 characters in its header,
 otherwise the encoding considerations for a message/rfc822 are
 applicable."

5:
Remove the first paragraph and remove the 5.1 title, i.e. keep
the second paragraph of 5 as new first paragraph, and add the
text in 5.1 as new second paragraph.

7:
The message/global template in chapter 4.6 are actually "IANA
considerations".  There has to be a review on the MIME type
list before IETF Last Call (ditto for the derived DSN types).

10.2:
At least the RFC 3501 reference isn't used anywhere.

 Frank 

. a we

Without this oddity 

and u100 Why not simply keep those
ugly 

r  

 l(wIf that's
tagged as say application/message it can't cause havoc
for agents believing in RFC 2045.  

  .still include suchhide some kind ofor these  require

  

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 25 Sep 2007 20:41:06 +0200

Frank Ellermann is still learning to tame OE, sorry... :-(

> list before IETF Last Call (ditto for the derived DSN types).

I've checked what happens if an experimental RFC registers a
MIME subtype, apparently that's possible without "variance"
procedure in the standards tree.

RFC 4288 4.2.6 states:
| All subtypes of multipart and message MUST conform to the
| syntax rules and other requirements specified in [RFC2046].

Let's drop the plan of an "experimental RFC 2046 update".
If you insist on it, we have to update RFC 2046 for real.

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 26 Sep 2007 17:54:53 +0100

> is IMO unnecessary and too dangerous.

But cannot be avoided. The whole purpose of our endeavour is to get rid of  
the need for funny encodings (whether RFC 2047 or RFC 2231) in headers,  
and if we exclude the body-part headers ffrom that, then we shall have  
failed utterly in our prime objective.

You cannot say that
   Content-Description: mañana
or
   Content-Disposition: attachment; filename=mañana
are allowed at the top level of a message, but not in MIME objects lower  
down. The world will just never learn to make such non-obvious  
distinctions.

As to whether the particular case of message/global as proposed will pass  
through the existing network, that is a separate technical ISSUE which  
needs to be studied and resolved separately.

-- 
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: "Frank Ellermann" <[email-masked]>
Date: Thu, 27 Sep 2007 12:56:05 +0200

Charles Lindsey wrote:

> The whole purpose of our endeavour is to get rid of the need
> for funny encodings (whether RFC 2047 or RFC 2231) in headers

TINW, I prefer to stick to the WG charter and MIME 1.0 for this
episode.  If that turned out to work and the UTF8SMTP core RFCs
are on standards track tackling MIME 2.0 might be fine.

> are allowed at the top level of a message, but not in MIME
> objects lower down.

Quite so.  I say "leave MIME 1.0 and Content-*" alone everywhere.
All it takes to get this effect is a note in the utf8headers I-D.

And lets please get rid of <utf8-quoted-pair>, if you're looking
for funny encodings that construct should trigger some alarms.

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 28 Sep 2007 10:37:41 +0100

>> is IMO unnecessary and too dangerous.

This is the essential matter behind the new ISSUE 1505. The others are
just details. My opinion is to leave it as in the present drafts, and my
reasons are best summarized by my earlier reply to Frank, repeated below.
If we are trying to allow UTF-8 in headers rather than messy encodings
into 7bit ASCII, then we need to allow them in ALL appropriate headers
WHEREVER they occur:
>
> But cannot be avoided. The whole purpose of our endeavour is to get rid  
> of the need for funny encodings (whether RFC 2047 or RFC 2231) in  
> headers, and if we exclude the body-part headers ffrom that, then we  
> shall have failed utterly in our prime objective.
>
> You cannot say that

As to detecting whether a message uses our extensions (including within
extended MIME objects), there are three alternatives:

1. REQUIRE a special header (e.g. Header-Type) at the top level.
2. REQUIRE a recursive search through the message looking for use of
extensions
3. REQUIRE both of the above

If properly implemented, all those methods are technically correct. The WG
discussed this a while back and the consensus was to speciy #2. Although
that was not my preference, I am not calling for that to be reviwed
(though others may).

> As to whether the particular case of message/global as proposed will  
> pass through the existing network, that is a separate technical ISSUE  
> which needs to be studied and resolved separately.
>

So, for discussion of this thread, let us assume that message/global WILL
magically work, or that it will be made to work somehow. It is a separate
issue which has attracted some discussion (and will undoubtedly arise
again), but it is not officially on our current agenda. So keep it out of
#1505.