Roy,
You sent a brief response to the 'history' component of my previous
note. I couldn't tell whether that was a concession or whether your reply
to Ned represents current thinking. If, in fact, the issue is now laid to
rest, please forgive what follows since I've no interest in "selling past
the sale".
d/
At 2:52 AM 11/20/95, Roy T. Fielding wrote:
involved in writing the document. There is no technical reason why an
agent should ignore header fields in body parts that do not begin with
"Content-". No existing MIME applications discard these fields -- in fact,
Can you speak with certainty about gateways? Gateways are famous
for throwing away headers.
Roy, there are two approaches to designing system enhancements: No
reason this shouldn't work, versus, they're out to get us so what can we do
to make SURE it will work?
In the Internet interoperability game -- and especially the email
game -- the latter has proved to be the necessary mode of design. I said
necessary.
From the computer science standpoint of designing raw data
structure functionality, MIME is pathetically ugly. All of that apparent
bogosity comes from having the latter attitude. And we didn't choose it
lightly. Hence, MIME works with -- and through -- everything, especially,
gateways. X.400 is an example of the former mode of design.
There is not way to confuse them with "normal" RFC 822 header fields, since
normal RFC 822 header fields wouldn't be in the body part to begin with.
Utlimately, all this leads to the question of your reason for
wanting to deviate from solidly-established convention? What possible
benefit is there?
The only thing that the above section accomplishes is waste bytes.
Roy! We're talking about RFC822 and MIME, here. The byte-counting
war got lost 20 years ago. Honest. I worried about this problem in the
late '70s and discussed it with Postel. Eventually I decided that the only
major win would be to convern header names into something much shorter like
numbers, since most of the data would remain ascii characters.
You're efforts here will save neglibible amounts of data and create
an interoperability risk. It's hard to believe that this is a winning
design tradeoff.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr.
dcrocker(_at_)brandenburg(_dot_)com
Sunnyvale, CA 94086 USA http://www.brandenburg.com