Greg (gregv@lucent.com)
Mon, 19 Feb 2001 10:57:43 -0600
The document looks good. I would like to suggest an addition, a deletion,
and some changes to the pre-registered message context indications.
I suggest deleting the video message context. The registration includes a
list of "none" attributes, which suggests to me that this is good fodder for
a future registation. It is clearly less mature than the other context's
listed, and less mature than other deployed contexts like greeting-card, and
meeting-request that are not listed. I do not generally support
place-holders for not-well-understood futures.
I do suggest adding a new context for "multi-media message". We have
existing, standardized applications like that of the multipart/related
bather=html and the like which truely do present a multi-media message
context. These message do make up a high percentage of messages in my
personal inbox, mostly mass-solicitations!
I would suggest refining the definition of mail-message to conform to the
older, more traditional use of email, that is, text, possible richly
formatted, plus attachments. This is a clear context in widespread use that
is materially different from the newer "multi-media" context. Use of this
mail-message context would then add value over a message with no context
specified or with a context of "none". Might I even propose renaming the
value to "text message" rather than "mail message" given that all the other
listed context indcations are also mail messages.
Also, I don't know wheter it is an artifact of cut-and-paste, or intentional
to note that short-message and mail-message are used by FPIM and VPIM. Both
explicitly prohibit, or strongly discourage sending textual media.
Good work. We've come a long way!
Greg V.
-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com]
Sent: Friday, February 16, 2001 8:33 AM
To: vpim@lists.neystadt.org
Subject: [VPIM] draft-ietf-vpim-hint-03.txt Changes
I've submitted a new version of vpim-hint (critical context). It should
appear in the archives shortly.
The changes are as follows:
---------------------------------------------
Section 4 (Motivation):
Delete last bullet that said you could filter the message list for
presentation based on message-context.
---------------------------------------------
Section 5 (Functional Requirements):
Added informative paragraph stating that the document purposely DOES NOT
specify what message-context the user agent should specify when forwarding a
message.
This is the new text:
NOTE: We specifically do not specify user agent behavior when the user agent
forwards a message. Clearly, the user agent, being message-context-aware,
should provide a meaningful message-context. It is obvious what to do for
the easy cases. Messages that the user simply forwards will most likely
keep the context unchanged. However, it is beyond the scope of this
document to specify the user agent behavior for any other scenario.
---------------------------------------------
Section 7 (Message-Context Reference Field):
Expanded upon why we have strict send, loose receipt rules.
This is the new text:
One can envision situations where a well-formed message ends up not
including a media type one would expect from the message-context. For
example, consider a voice messaging system that records a voice message and
also performs speech-to-text processing on the message. The message then
passes through a content gateway, such as a firewall, that removes
non-critical body parts over a certain length. The receiving user agent
will receive a message in the voice-message context that has only a text
part and no audio. Even though the message does not have audio, it is still
in the voice message context.
Said differently, the receiving UA can use the message-context to determine
whether, when, and possibly where to display a message. However, the
message-context should not affect the actual rendering or presentation. For
example, if the message is in the voice-message context, then don't try to
send it to a fax terminal. Conversely, consider the case of a message in
the voice-message context that gets delivered to a multimedia voice terminal
with a printer. However, this message only has fax content. In this
situation, the "voice-message" context should not stop the terminal from
being properly rendering the message.
---------------------------------------------
Section 7.2 (message-context-class Syntax):
Fixed ABNF
---------------------------------------------
Section 7.2.x (the message enumeration section):
I changed NOTHING from -01 to -03. The reason I'm pointing this out is that
Laile and Graham were thinking about putting more information in the
document about putting more detailed definitions of just what is a
xxxxx-message. You will recall that -00 had detailed definitions, and we
decided to pull them as being too confusing.
Does not section 10 suffice?
---------------------------------------------
Section 9 (IANA Considerations):
Added paragraph describing what we'd expect a context to look like. Since
if we knew the context, we'd register it now (like video-message), I was
rather vague:
This is the added text:
We would expect new registrations to reflect sensible message contexts that
will arise in the future. For example, we include video-message as an
expected message type.
This archive was generated by hypermail 2.0b3 on Mon Feb 19 2001 - 20:03:07 IST