ietf-822
[Top] [All Lists]

New-ish idea on non-ascii headers

1991-09-17 04:08:51
As far as I can tell, the only problem that we don't have a handle on at
all so far is non-ascii header data.  (The people who think they have a
handle on it tend, I think, to underestimate the risks of messing with
crucial header fields like "From".)  I woke up at 4 AM this morning
unable to stop thinking about this issue, so I have yet another proposal.

1.  Existing predefined RFC 822 header fields stay US-ASCII forever.  No
interoperability problems.

2.  We define a set of new header fields that contain the "real" (= in
the right charset) data that corresponds to crucial user-relevant data.
such as the From field:

        REAL-TEXT-HEADERS = RTHDR ":" " CHARSET "/" ENCODING ":"  RTDATA

        RTHDR = "Real-From" / "Real-Subject" / "Real-To" / "Real-CC" / ...

        CHARSET = "ISO646" / ...

        ENCODING = "base64" / "quoted-printable"

        RTDATA = text

Thus, for example, the following is silly but has useful non-ASCII
counterparts:

        Real-From: US-ASCII/base64: TmF0aGFuaWVsIFMuIEJvcmVuc3RlaW4=

3.  The new "Real-XXX" headers have NO delivery semantics.  Indeed,
their only use is to provide human-readable text phrases.  When they
exist, they are intended to override the corresponding non-"Real-"
headers ONLY for purposes of display to the user.

As an added bonus, this finally would give us a standard place to put
the human name, rather than dig it out heuristically from the "From" or
"To" fields.  Thus it actually might make a certain amount of sense to
say the equivalent of the above, but unencoded:

        Real-From: US-ASCII/None: Nathaniel S. Borenstein

A UA can much more easily use this as the name than dig it out from
something like

        From: nsb(_at_)thumper(_dot_)bellcore(_dot_)com (Nathaniel S. 
Borenstein -- Applied Research)


I don't think we're going to find a satisfactory mechanism that puts
non-ASCII text into the established headers.  Would this proposal
satisfy the needs of the people who really want non-ASCII headers?  If
we don't come up with something soon, I feel very strongly that the RFC
should go ahead *without* any mechanism for non-ASCII headers, because I
don't think this is important enough to hold everything else up.  --
Nathaniel

<Prev in Thread] Current Thread [Next in Thread>