Eric Burger (eburger@snowshore.com)
Fri, 16 Feb 2001 09:32:51 -0500
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 Fri Feb 16 2001 - 16:32:31 IST