Re: Better Headers

[Craig_Everhart@xxxxxxxxxxxx]

Excerpts from transarc.system.ietf-smtp: 5-Apr-91 Re: Better Headers
Keld J|rn Simonsen@dkuug (904)

> Actually it looks quite nice on my screen, and I think it looks
> OK on many other Scandinavians' screens too. Anyway I have gotten used
> to it, I have had it most of my life.

Just another indication that some indication of character set would be
appropriate in the strictly-7-bit world as well, in Content-Type: or
Content-Encoding:.  As if Keld wondered, the second letter in his middle
name displays as a vertical bar on many readers on this side of the
pond.  One wonders how it displays in non-Scandinavian countries.

> NETF decided to use TEXT-HEX on 10646 on the comment fields in headers.

This seems to diminish, rather than promote, interoperability.
- How will your message readers know that a name like
	From: cfe+@transarc.com (Craig F. Everhart)
doesn't have its comment field in TEXT-HEX?

- How could my message reader know to decode your comment fields as
TEXT-HEX versions of 10646?

Is the proper interpretation of the text fields tagged in the message
header in any way, by those agents that compose them in TEXT-HEX/10646? 
If not, may I encourage such an encoding, along with strict rules for
what's encoded and what's not?

That is, we could invent an 822 header, something like
	Header-text-encoding: ---10646--, text-hex
that would be defined as applying to a whole collection of parts of RFC
822 headers.  Clearly, that collection would have to be defined in
advance, if the Header-text-encoding: solution would work, but this is
possible.  The Header-text-encoding: header would apply only to those
headers composed by informed agents, so you'd leave alone everything in
Received:/Message-ID:/Return-path:.  (And if your local sendmail adds
From:, it would have to add the From: form that was encoded in the named
Header-text-encoding!)

I'd suggest that the following field parts (from the RFC 822 grammar) be
so encoded:
    *text after Subject:
    *text after Comments:
    phrase (in mailbox, the name preceding the route-addr)
    phrase (in group, the name of the group)
I'm not sure about:
    ctext (the text within parentheses in any field, except in Received:
    fields; Date: fields also?)
I'd recommend that ``local-part'' NOT be encoded.  It will confuse
automatic agents hugely, and agents that add FOR clauses to their
Received: lines will probably not encode the strings properly.  Also,
``domain'' should probably NOT be encoded either.

My apologies if NETF has done this already.

		Craig