--On Wednesday, 30 November, 2005 08:28 -0800 Dave Crocker
<dhc2@dcrocker.net> wrote:

> 
>>> Q10:[Dave Crocker]: Should we follow the "PR" 2282 object &
>>> pseudo push? The presentation layer is worrisome, no details
>>> documented, object  needs to be labelled.
>>> <this question was unclear in the notes>
>> 
>> My understanding is that Dave want to be able to recognize a
>> "stored" message be of new format(i.e. IEE compliant) or old
>> one (i.e. RFC 822 compliant).
> 
> 
> I do not recall my words, but you the gist of my concern is
> approximately what you understood.
> 
> The general form of my concerns:
> 
>       When there are multiple choices in content form, the
> choice that applies for a given message needs to be labeled
> explicitly within the message.  Messages need to be
> self-contained, rather than relying on their context for
> interpretation.   This is during transit, as well as storage.

Dave,

While this clearly belongs in the minutes since it was
discussed, I want to open a bit of discussion on this topic.  I
want to stress that I don't have a strong position on it; I'm
just trying to understand the claimed requirement and what would
satisfy it a little better.

In theory, the content of messages in transit is not examined at
all, so it makes little difference what is in the headers except
at the endpoints.  

I'm also reminded of the famous "MIME-Version: 1.0" header
field, which was supposed to denote a new way of identifying
headers (particularly the presence and interpretation of
"Content-type:") as well as a formatted body.  Now, it was
arguably necessary because "Content-type:" was already in use
for slightly different information in a slightly different
format -- only if "MIME-version:" was also present could one be
reasonably assured that 
"Content-type:" could safely be interpreted according to MIME
rules.   But, for all the other good it has done us -- and, in
particular, our inability to change the version number in a
meaningful way -- we could have named the Content-type field
"MIME-Content-Type:", required it, and saved the extra header
line.

So, first, for amusement value, is this "MIME-Version: 2.0"?
My gut tells me this isn't a good idea, but at least the odds of
some intermediary filter discarding the message would be reduced.

More generally, is this a header that should be required to be
pushed into the message on final delivery or as part of a
gateway process, not unlike "Return-path:".  And, if not, what
is the value of having it in transit?

It also seems to me that the _real_ point at which this is most
important is in the message store and in the mechanisms used to
pick the message up from the store and deliver them to, e.g., a
POP server or client.   If that is the case, are we going to
start specifying message store formats now?  We have carefully
avoided it in the past and, as you know better than anyone else,
822 is specified as the format of headers on delivery, not the
format that has to be used in message stores and otherwise
within systems.

    john


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima