Excerpts from transarc.system.ietf-822: 4-Jun-91 re: comments on may
draft Neil Katin(_at_)eng(_dot_)sun(_dot_)com (3633)
We want these sizes in order to standardize some communication
between the message store and the UA, *NOT* between the sending
UA and the receiving UA. While we could add these things as X-Sun-length
fields, we thought that this would be a very common thing to want
to do, and therefore should appear in the standard. We expect to
generate these fields upon receipt; we would even be willing to
insist that a sending UA needs to strip these fields off of a
message to ensure that they couldn't cause problems upon receipt.
Thanks very much for the clarification.
As we've argued, the function you describe is of questionable utility as
passed between different UAs. I'd suggest one of two routes:
- modifying the protocol between the message store and the UA so as
to specify the length of the stored message, in any way you'd like,
outside the RFC822 header; or
- reserving an RFC822 header for private communication between
message stores and UAs, where the header is always ignored, and may
be overwritten, as a message is received into a message store.
Reserving the header name simply prevents this header-overwriting
from bashing any otherwise-valid header.
I don't have any big problems with either of these two solutions. But
if the second of these alternatives is what you're proposing, I like
this formulation far better than specifying the Content-size: header as
something meaningful for communication between UAs. I myself have only
slight problems with specifying a header for messagestore-UA
communication in a document that purports to be about UA-UA
communication; doing so smacks of bad protocol layering.
Craig