Greg (gregv@lucent.com)
Thu, 21 Jun 2001 16:35:43 -0600
I am not ready to concede. Orthogonal or not, how do we label an MDN/NDN so
that:
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. 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?
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. 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?
After all, the difficulties in processing the existing
multipart/voice-message is exactly why we developed message context today.
(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. )
Greg V.
-----Original Message-----
From: Glenn Parsons [mailto:gparsons@nortelnetworks.com]
Sent: Thursday, June 21, 2001 5:04 PM
To: Vaudreuil, Greg M (Greg); 'Jutta Degener'
Cc: 'IETF VPIM List'; 'Ned Freed'; 'paf@cisco.com'; 'John W. Noerenberg'
Subject: RE: [VPIM] WG Last Call on Message Context & Critical Content
I think I would side with your original assessment that this is orthogonal.
..and Jutta makes a good case for that.
Should I consider this closed?
Glenn.
----------
From: Jutta Degener
Sent: Tuesday, June 12, 2001 5:54 pm
To: Vaudreuil, Greg M (Greg)
Cc: 'IETF VPIM List'; 'Ned Freed'; 'paf@cisco.com'; 'John W. Noerenberg'
Subject: Re: [VPIM] WG Last Call on Message Context & Critical
Content
[Greg V. wants to make DSN/MDN a Message-Context]
> My initial thought was that DSN is orthogonal to context, that is, a
message
> may be both a failure and a pager message, but upon further reflection, I
> believe a failure is a context in and of itself, sent in response to a
> message of any context, and treated primarily as a failure, not as a
message
> in the original context.
My knee-jerk reaction is to disagree; I think that on an abstract
application
level, a failure is primarily an attribute of the message that failed. (It
is
not a "fax message" because a fax message failed, but it is the negative
confirmation coming out of your fax machine, or a voice announcement after
the voice mail you sent bounced, or ...)
Two other arguments against:
* The current draft begins:
> This document describes a mechanism to allow senders of an
Internet
> mail message to convey the message's contextual information. Taking
> account of this information, the receiving user agent (UA) can make
> decisions that improve message presentation for the user in the
> context the sender and receiver expects.
MDNs and DSNs are usually not sent by a human sender. There are
no
expectations. There's just an e-mail system that can't deliver an
email message.
* MDNs and DSNs are already completely and reliably distinguishable
by
Content-Type. This mechanism would be at best superfluous.
If there is a need to change things, I would prefer to change the
draft
to more strongly point out that the Context's aim is _not_ to tag _all_
possible e-mail messages with the expectations of their human sender,
but to merely express those expectations where they obviously exist.
Jutta
This archive was generated by hypermail 2.0b3 on Fri Jun 22 2001 - 01:35:52 IDT