Subject: [EAI] #1504: Proposed resolution - UTF8HDR 4.2: Nested encodings avoidable?

From: Harald Alvestrand <[email-masked]>
Date: Fri, 19 Oct 2007 12:14:01 +0200

There has been a little discussion on this subject here, but not that much.

Main points:

- Computational overhead of decoding probably increases approximately 
linearly with the length of the message, and approximately linearly with 
the number of levels of encoding. But multiple levels of encoding will 
occur in only a few situations.
- Implementation complexity increases if multiple mechanisms have to be 
implemented, and new mechanisms will definitely not exist in 
non-UTF8SMTP mail agents.

CURRENT TEXT:

The current text in section 4.2 of UTF8HDR -07 is:

   This specification updates section 6.4 of RFC 2045.  RFC 2045
   prohibits applying a content-transfer-encoding to all subtypes of
   message/.  This specification relaxes the rule, allowing newly
   defined MIME types to permit content-transfer-encoding. (see
   Section 4.6).  Normally, transfer of message/global will be done in
   8-bit-clean channels, and body parts will have 8-bit encodings.  The
   additional complexity of a content-transfer-encoding on "message" is
   therefore acceptable.  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.

Section 4.6 says:

4.6.  message/global

   Internationalized messages, also called UTF8SMTP messages, must only
   be transmitted as authorized by [EAI-SMTP-extension] or within a non-
   SMTP environment which supports these messages.  A message is a
   "message/global message", if
   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.

   The second type, used for content return, is message/global which is
   similar to message/rfc822, except it contains a message with UTF-8
   headers.  This type has profound implications on the email
   infrastructure.  If this type is sent to a 7-bit-only system, it
   could be encoded in [RFC2045].  (Note that a system compliant with
   MIME that doesn't recognize message/global would treat it as
   "application/octet-stream" as described in Section 5.2.4 of
   [RFC2046].)  Alternatively, SMTP servers and other systems which
   transfer a message/global body part MAY choose to down-convert it to
   a message/rfc822 body part using the rules described in
   [EAI-downgrading].
....
   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.

(This section contains an obvious copy/paste error at the top of the 
second paragraph; that will be fixed as an editorial matter.)

SUGGESTED RESOLUTION:

Continue permitting nested encodings. Improve the language slightly.

New text for section 4.2:

   This specification updates section 6.4 of RFC 2045.  RFC 2045
   prohibits applying a content-transfer-encoding to all subtypes of
   message/.  This specification relaxes the rule, allowing newly
   defined MIME types to permit content-transfer-encoding, and permits
   content-transfer-encoding for message/global (see
   Section 4.6).

   Background: Normally, transfer of message/global will be done in
   8-bit-clean channels, and body parts will have "identity" encodings,
   that is, no decoding is necessary.
   In the case where a message containing a message/global is downgraded
   from 8-bit to 7-bit as described in  [RFC 1652], an encoding may be 
applied
   to the message; if the message travels multiple times between a 7-bit
   environment and an environment implementing UTF8SMTP, multiple
   levels of encoding may occur.
   This is expected to be rarely seen in practice, and the potential 
complexity
   of other ways of dealing with the issue are thought to be larger than the
   complexity of allowing nested encodings where necessary.

New text for section 4.6:

   The type message/global is
   similar to message/rfc822, except that it contains a message that can
   contain UTF-8 characters in the headers of the message or body parts.
   headers.  If this type is sent to a 7-bit-only system, it
   has to be encoded in [RFC2045].  (Note that a system compliant with
   MIME that doesn't recognize message/global would treat it as
   "application/octet-stream" as described in Section 5.2.4 of
   [RFC2046].)
....
   Encoding considerations:  Any content-transfer-encoding is permitted.
       The 8-bit or binary content-transfer-encodings are recommended 
where permitted.

Comments?

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Oct 2007 15:07:47 -0400

On Fri, Oct 19, 2007 at 12:14:01PM +0200, Harald Alvestrand wrote:

[nice summary]

> Comments?

I just looked over the document with new text "substituted", and I
think it's a reasonable answer.  So I support the suggested text.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 24 Oct 2007 10:41:52 +0200

> Continue permitting nested encodings. Improve the language slightly.

Okay, I think you can permit it.  But I'm not happy with the way how you

>   content-transfer-encoding for message/global (see

I think that this section in RFC 2045 has to be updated by an "erratum"
as outlined in <http://article.gmane.org/gmane.ietf.ima/2150>.

IMO the EAI charter doesn't  cover "experiments" with MIME 1.0.  

If Ned confirms this issue as "2045 erratum", and if message/global
survives the expert review on the "types list", we're ready for an IETF
Last Call.  To be sure the issue should be mentioned in the "security
considerations" of message/global, i.e. in section 6 of UTF8HDR.

> The type message/global is similar to message/rfc822, except that
> it contains a message that can contain UTF-8 characters in the 
> headers of the message or body parts.  headers.

s/headers of the message or body parts. headers/header/.  Do not
mess with MIME 1.0.  If a future version of MIME allows UTF-8 in
Content-* header fields we'll see what happens.  Let's focus on 
"E-mail Address Internationalization" for now.

> If this type is sent to a 7-bit-only system, it  has to be encoded in
> [RFC2045].

s/in/using a 7-bit Content-Transfer-Encodings as specified in/

> Comments?

Since John talked about a "MIME expert" saying "ugh" some 
months ago I wondered who he had in mind (after all he's the
co-author of 4288, 4289, and 2048).  Please get Keith or Ned
to check #1504 and the unrelated "UTF-8 in Content-*" issue.
(JFTR, that's my 3rd request for an external MIME review).

 Frank