ned.freed@mrochek.com
Thu, 21 Jun 2001 17:44:59 -0700 (PDT)
> I am not ready to concede. Orthogonal or not, how do we label an MDN/NDN so
> that:
In the sense of message context, you don't. Message context is a display hint.
If the DSN or MDN gets to the point of being processed by a display engine, in
effect the battle is already lost. Proper handling of DSNs and MDNs ideally
implies correlating them with previously sent messages, and less ideally at
least means converting them into something other than a conventional display
that a message context would apply to.
This can be seen as a layering issue. If anything is broken here it is our
inability to call out DSNs and possibly MDNs as special as part of the message
envelope. Doing this in the message header was a mistake, but one we knew about
and intentionally made due to limitations in our overall messaging
architecture.
Now, if you're willing to ignore the layering issue (and to some extent we
clearly are willing given what we did in DSNs and MDNs to begin with), it would
certainly have been possible to use message context to specify, say, the report
type. (You still need to retain the report subtype to indicate that
multipart has a special structure.)
But we didn't, and the reason for this is simple: We didn't have message
context at the time, and given that DSNs and MDNs were tightly bound to a
specialized sort of multipart structure to begin with and as such we had
subtype and parameter fields there to be used, we didn't need to invent message
context to get the job done.
Had we had message context available I'm sure we could have spent a lot of time
arguing about whether or not to use instead of the report-type parameter. In
fact there would have one real advantage to using message context -- we would
be able to sign a report and still indicate what type of report it was in the
outer message header. (There are, however, security implications associated
with doing this.)
But we didn't have message context, so the issue never arose. And now it is too
late to change, because even if you believe it would be better, widely deployed
running code trumps what passes for architectural purity in the IETF every
time.
> 1) The proper icon is displayed (red X?)
> 2) The proper viewing "form" is displayed rendering the DSN in
> human-readable form
> 3) The proper rules can be triggered so that MDN's can be auto-filed
> into the "CYA" folder
> 4) Failures are ordered in the inbox in a special way, maybe so you
> don't overlook failures when your mailbox is overun by OPES mail.
> These are exactly the stated intent of message context.
Axctually, these things sound more like what a message context label is for.
But then you'd be specifying "display as icon" as the context, not "this is a
DSN". But this doesn't work right since these are all valid ways to handle any
DSN or MDN you receive, regardless of what the report's contents are. A sender
has no way of knowing which of these may be appropriate, and the
appropriateness is dependent on the recipient's environment, not on message
content. Message context, on the other hand, is a statement made by the sender
that provides a hint about what sort of content is there and how best to handle
it.
> Without
> message-context, we have to continue to inspect the top-level (usually)
> content-type to determine the processing rule... is that not what
> message-context was in part trying to avoid?
Certainly not. Aesthetics aside, there is absolutely no value in simply
reiterating what the outermost content-type said in another field in the same
header. The point of message context is that it summarizes the message content
in its entirety and it does so along an axis that isn't the same as a media
type.
In particular, it is nice not to have to look at the content in its entirety,
and it is also quite possible that a single content type may give rise to
multiple message context values, all equally legitimate, and it is very
possible that a single message context could involve all sorts of different
content types.
> The multipart/report is just another example of someplace where we
> overloaded multipart/mixed to communicate a "context" to the application
> that the collection of stuff is different than than a just collection of
> stuff.
Not really. The purpose of the subtype associated with multiparts has always
been to attach additional semantics to something that intrisicly contains
multiple parts. In most cases the parts of a specific subtype are structured in
a specific way for a fairly narrow purpose.
But the subtype of a multipart has never provided a means of attaching
semantics to a message as a whole. Nor is it available to attach semantics to a
single part message. Nor is it available when it is already in use at the top
level to indicate that the message is signed, or encrypted, or consists of a
related part structure, or whatever.
> I don't buy the argument that since we already overloaded
> multipart/mixed for notifications that we don't need to offer the benefit of
> labeling it as a separate message context.
> I note in passing that
> standards-based email clients still do a bad job at presenting DSN/MDNs' to
> end-users... is the difficulty of extracting the context part of the blame?
I doubt it very, very much. I've implemented the code necessary to process
multipart/report, and the hard part isn't recognizing that you have a report.
No, the hard part is processing the contents of the report. (Proper handling of
incorrectly constructed reports is especially joyous, and you don't make that
any easier by providing another label to check.)
> After all, the difficulties in processing the existing
> multipart/voice-message is exactly why we developed message context today.
Yes, but with a report the report type really is all you need to know in order
to process it.
> (I recall all the grief we suffered from VPIM V1 (RFC1911) which used a
> fixed multipart structure with positional significance... the first part was
> the spoken name, the second part the voice message, and the third part an
> optional fax.... sorta just like the three-part multipart/report (RFC1892).
> Ya might think they came from the same thinking. )
Not having processed such things myself, I'm not sure what sort of grief
you're talking about. If it is that the rigid structure wasn't sufficiently
flexible, well, that's not an issue with reports, where if anything additional
flexibility would hurt rather than help. So if that it what you mean, I don't
think it is a valid comparison.
I guess my conclusion is that I do see the identification of reports and
report types as largely orthogonal. And even if I believed otherwise and
wanted to use message context as a means of labelling reports, I believe that
ship has sailed and won't be pulling back into the harbor again.
Ned
This archive was generated by hypermail 2.0b3 on Fri Jun 22 2001 - 05:01:45 IDT