[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Better Headers
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: firstname.lastname@example.org (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
I'd suggest that the following field parts (from the RFC 822 grammar) be
*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.