ietf-822
[Top] [All Lists]

Re: Charset compromise (Was Re: Character-set) header

1991-09-06 12:20:56
Well, as I said, I'm pretty sure I'm not understanding what is going on, 
but my understanding was that the prohibition on encoding headers did 
not apply to anything but content-type and content-transport-encoding 
for the body part(s).

I believe that the following is permitted over a seven bit transport.  
If it is not, then "kludge" is probably too mild.

Starting from Greg's rewrite, with his lines that I have replaced marked 
">" and my new lines marked "#"...

    From: <ASCII form>
    Subject:  <ASCII form>
    Content-type:  message/iso-8859-2
#   Content-transport-encoding: quoted-printable
#   X-Comment: that can certainly appear in an outer header for 
#         "message", can't it?  There is no nesting here.

   From: <iso-8859-2-form>     * Untransportable
#    From: phrase-in-iso8859-2-quoted-printable
#       <ascii-local-part(_at_)ascii-domain>
   Subject: <iso-8859-2-form>  * Untransportable
#    Subject: iso8859-2-quoted-printable-form
    Content-type: text/iso-8859-2
    Content-Encoding: Quoted-Printable
        
    Message body in iso-8859-2 character set.
# (in quoted-printable, of course)

This is what I've assumed we are talking about in a "no multiple 
encodings" model.  It follows the model of 
  --main header tells about coding and char set of the inner header
  --inner header tells about the coding and char set of the message
and, at no point does no transport-encode something that is already 
transport-encoded.
  And we have a standing prohibition on anything but ASCII in the 
Content-type and -encoding fields, don't we?  And in the spelling of 
such things as "From:", "Subject:",...?

If that isn't how we have defined it, can we go back and do it that way? 
Even if that means a new content-type in the outermost headers?  All of 
the other solutions, including the multipart one Greg outlined, are too 
horrible to contemplate for merely being able to write one's name or a 
subject field in non-ASCII characters.  The solution above is merely 
disgusting but, for me at least, I can manage to contemplate it.

Note that, over 8bit transport, the arrangement above survives without 
alteration, only the encodings to quoted-printable go away.

  --john