Subject: [EAI] ISSUE - draft-ietf-eai-utf8headers-07

From: Bill McQuillan <[email-masked]>
Date: Fri, 21 Sep 2007 11:34:25 -0700

This discussion of how to handle Content-Transfer-Encoding for composite
types leads me to consider that what we probably should be proposing
instead is a *new* MIME header field: Content-Header-Encoding which only is
meaningful for composite types and only affects the HEADER of a message/*
or the PART-HEADERS of a multipart/*.

This avoids the "double encoding" problem and also preserves MIME structure
visibility. (We might need to warn about the problem of specifying a
non-ASCII multipart separator string to a non-EAI-aware program.)

Since any relaxation of the "blanket ban" of Content-Transfer-Encoding for
composite types would probably require *some* updating of code in EAI-aware
programs, the addition of a Content-Header-Encoding field should be of
similar effort and would narrow this solution to only the portion of the
data where it is needed.

Sorry if I have missed a discussion of this possibility previously in this
group.

-- 
Bill McQuillan <[email-masked]>

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 26 Sep 2007 17:07:13 +0200

Bill McQuillan wrote:

> instead is a *new* MIME header field: Content-Header-Encoding which only
> is meaningful for composite types and only affects the HEADER of a
> message/* or the PART-HEADERS of a multipart/*.
 
> This avoids the "double encoding" problem and also preserves MIME
> structure visibility. (We might need to warn about the problem of
> specifying a non-ASCII multipart separator string to a non-EAI-aware
> program.)

An interesting idea.  Slight variation:

For a Content-Type: message/global (and its DSN-variants) we normally
expect CTE 8bit and a header charset UTF-8.  If we could get away with
7bit and header charset ASCII a message/global in essence degenerates
into an ordinary message/rfc822.

IOW we could decree that a message/global in the context of a CTE 7bit
is "by definition" a QP-encoded UTF-8 header followed by a 7bit body
as specified in the CTE header field of the QP-encoded UTF8-header.

That would be still a kind of "double encoding" for any 2231-Q word in
the original message/global header.  If you pick something better than
QP like B64 you'd lose the "visibility".

>From my POV your "issue" affects the following statement in section
4.6 of the I-D:

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

What exactly is a message/global in the context of 7-bit transport ?

 Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Sep 2007 14:59:36 +0200

I've lumped this together with the double encoding issue - #1504.

Please keep the number in the subject line when responding.