ietf-822
[Top] [All Lists]

Re: new-ish idea on non-ascii headers

1991-09-21 17:20:40
In my own, very strong, opinion, I believe that ALL participant-specific
information should be carried around with the address, and definitely,
absolutely , positively NOT factored into separate headers.  

While in the particular debate in question I am against extra headers,
I don't think we can do away with them in general. Perhaps we can
make them more palatable.

The rfc-822 headers are a system for defining name-value pairs.
The Atlanta meeting changed the name-value pair system defined for
Content-type binary (and others) on the very reasonable grounds
that we should only have one name-value system. Also it is not
a good idea to let headers get too big. I agree with both those
points.

The problem is that the headers define a flat space and we now see
that we want a heirarchical one (following from a corollory of
Murphy's law). It would be fun to redefine the whole thing from
scratch, but the world certainly doesn't need a 3rd mail system.
So we are going to end up with a compromise. David Crocker's
"Organization" and "Phone" headers are an interesting case. Most
mail users think there can be only one From source, but of course
a message can come from multiple people as we often see in Letters
to the Editor in newspapers and magazines. 

We like to keep things sensibly terse in rfc822++, and the following
straw proposal goes against that. Something has to give...

I propose that we declare the concept of a sub-header. A header is
a sub-header of a preceding header if it contains the name of that
header as the initial part of its name and so do all intervening
headers [examples below]. This will imply that such header sequences
mustn't be re-organized.

A slightly contrived example:

   From: x(_at_)y(_dot_)z
   From-organization: xyz corp.
   From-organization-phone: 123 4567
   From-phone: +61 3 456 7890

In this example From-phone is a sub-header of From since it includes
"From" as the initial part of its name and so do all the headers between
it and the From. Similarly From-organization-phone is a sub-header of
From-organization which is in turn a sub-header of From. [By the rules
From-organization-phone is also a sub-header of From. If we want to
stress the heirarchical nature we could make some distinction between
parents (closest header of which we are a sub-header) and ancestors].

This isn't going to help us a lot when there are multiple From addresses
unless we declare that

        From: AAA
        From: BBB

means the same as 

        From: AAA, BBB

And similarly for To, CC, etc. That's the way I've always assumed it
should be so I think if we make changes which emphasize the fact that 
mail software should handle repeat headers correctly that may lead to
the spread of correct behaviour. Note that correct behaviour is not
critical in this area: if the user hits "reply" and the mail software
doesn't pick up the correct list of recipients she can compensate by
hand.

The implication of this is that the optional headers for some Content-types
would become Content-type-original-filename, etc.

Bob Smart