One document matched: draft-ema-vpim-um-01.txt
Differences from draft-ema-vpim-um-00.txt
MIME Sub-type Registrations
for unified messaging
<draft-ema-vpim-um-01.txt >
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet Drafts as reference material
or to cite them other than as a "work in progress".
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Overview
This document describes the registration of the MIME sub-types
multipart/voice-message and multipart/fax for use with the Voice
Profile for Internet Mail (VPIM) for Unified Messaging. It also
introduces the primary content type concept. A further
description of usage can be found in the VPIM v3 specification.
The VPIM WG home page is: http://www.ema.org/vpim
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 1]
Internet Draft VPIM UM February 26, 1999
1. Introduction
This document describes the registration of the MIME sub-types
multipart/voice-message and multipart/fax-message for use with the
Voice Profile for Internet Mail (VPIM) for Unified Messaging.. It
also introduces the primary content type concept. A further
description of usage can be found in the VPIM v3 specification
[VPIM3]. This document revises earlier sub-type registrations in RFC
2423 [V-MSG] for [VPIM2] and RFC 1911 [VPIM1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [REQ].
2. VPIM v3 Scope
The VPIM v3 specification defines a profile of the Internet Mail
protocols for use between unified or universal platforms. These
platforms are intended to be full Internet Mail platforms with the
ability to handle voice and fax media as well. Historically, voice,
fax and email have existed on separate systems. Recently, email
profiles have been created for both voice [VPIM2] and fax [IFAX] but
these are restrictive to only that media and special-purpose computer
systems they were intended for. VPIM v3 lifts these restrictions, but
to facilitate efficient unified messaging benefits a primary content
type semantic must be provided by multipart/voice-message and
multipart/fax-message.
3. Primary Message Type
In the early days of Internet Messaging, there was only one media type
- text, and a message simply contained one text body. When the user
viewed the text, the message was unequivocally "read".
Today, systems can send and receive messages containing many different
media (as different content types within a multipart/mixed). For
example, a message may contain text with voice, fax and spreadsheet
attachments. It may appear that all the media are given equal
importance, but in fact, the text is given precedence. A typical email
client may display the text in a preview pane. And when the message is
"opened", the text will be displayed in the main window and the
attachments will be iconified. Once the text has been displayed
(within the preview pane, or upon opening the message), the client
determines that the message has been "read", even though none of the
attachments have been "seen".
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 2]
Internet Draft VPIM UM February 26, 1999
This behaviour is particularly problematic if the sender has requested
that a disposition notification (MDN) be issued when the message is
viewed. The sender cannot know if any or all of the attachments have
been viewed. The mechanism is not helpful if the sender is
particularly interested in the disposition of a particular attachment
- a fax attachment, for example.
A solution to this problem is to introduce the concept of a primary
message type. A multipart message has associated primary content type
semantics. The primary content type of a multipart/voice-message is
voice, the primary content type of a multipart/fax-message is fax, and
so on.
A client supporting the primary message type concept will not declare
a message as "read" until the body part containing the primary media
has been "seen".
Only when this attachment has been "seen" will a client issue a
requested MDN.
It may be apparent that most mail clients currently consider the
primary content type of a multipart/mixed message to be text/*.
New mail clients may interpret the multipart/* content type and
display the message appropriately. For example, upon selecting a
multipart/fax-message, the client may display the fax attachment in a
preview pane.
4. Unified Messaging
Though many systems can send and receive messages containing many
different media (as different content types within a multipart/mixed),
all the media are given an equal importance. That is, a message with
a voice, fax and spreadsheet attachment may be sent from a system to
recipients on many different systems (with different capabilities).
If the message was sent to a voice messaging system, and the primary
content of the message was the voice Ð the fax and spreadsheet were
merely FYI Ð the message would not be delivered because the other
contents could not be rendered.
However, if the message was identified as being primarily a voice
message, the receiving voice-only system could detect that and deliver
the voice but discard the informational attachments.
Support of primary content type will differentiate true "unified
messaging systems" from the "media-agnostic" messaging systems widely
deployed today.
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 3]
Internet Draft VPIM UM February 26, 1999
A "media-agnostic" messaging system is capable of rendering many body
types- text, audio, fax, spreadsheets, etc., but text always takes
precedence.
A true "unified messaging system" will recognize the message type
(text, voice, fax, etc.) and may indicate this to the user by
displaying a differentiating icon. When a message is selected,
appropriate action is taken for the type of message. For example, the
fax content is immediately displayed, the audio player is launched and
the voice is immediately played, and so on.
The unified messaging system will change the status of a message from
unread to read once the primary content has been rendered for the
user. For example, this means that a voice message is "read" once the
voice has been played, even if text annotation or an attached fax has
not been seen.
5. Disposition Notification
The message notification mechanism is described in [MDN]. The MDN is
generated by the client (when requested in the message) upon
disposition of the message. Examples of dispositions include:
displayed, deleted, forwarded, or otherwise "processed". The MDN
mechanism does not provide semantics enabling the sender of the
message to determine with certainty which body parts were actually
accessed by the recipient. The MDN mechanism does not allow the user
to tag a specific body part for inclusion in the disposition report.
As we have seen, most likely the user will be notified when the user
has seen the text, even though a fax attachment may be the most
important content.
A client supporting primary message type will also provide the missing
MDN semantics. Clearly, the client should only generate the
disposition report when the primary message content has been seen,
etc. For example, an MDN report when the voice content of a
multipart/voice-message has been played, or when the fax content of a
multipart/fax-message has been displayed or printed.
6. Discard Rules
Existing email servers support messages containing any arbitrary
content type. The email clients may or may not be capable of
processing message attachments. The sender of the message will be
unaware that an attachment could not be rendered unless explicitly
informed by the recipient.
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 4]
Internet Draft VPIM UM February 26, 1999
The VPIM v2 specification, on the other hand, requires different
semantics. Recognizing that legacy voicemail systems do not support
text, the specification does not allow text within a multipart/voice-
message. However, the specification allows inclusion of an image/tiff
attachment. If the recipient system does not support fax, the entire
message must be rejected.
These semantics are insufficient because they do not recognize that a
message has a primary content. A more appropriate behaviour can now be
defined:
If the receiver does not support the primary message type,
reject the entire message and generate an appropriate non-
delivery report (DSN). For example, if a VPIM v3 system
receives a message containing audio content encoded with an
unsupported codec, the entire message must be rejected.
If the receiver supports the primary message type, the message
must be accepted. If the sender requested positive
acknowledgment, the receiver must generate a positive delivery
report.
If the receiver accepts a message but does not support the
media type of some attachments, the attachments may be deleted.
However, if attachments are deleted, the recipient should be
appropriately notified. For example, consider an Internet Fax
device receiving a message with an audio/* body. The server
could add notification to the cover page that there was an
audio attachment that could not be played. If the sender has
requested positive acknowledgment, the delivery report must
contain an appropriate return code indicating some content was
not delivered. If positive acknowledgement was not requested, a
negative acknowledgement report must be returned containing an
appropriate return code indicating that some content was not
delivered.
7. Primary Media Content Types
, As described earlier, the use of primary content types will allow
unified messaging systems to view the message as intended (e.g., as a
voice message using a plug-in). This could give the user the voice
message (or fax message) interface Ð which would likely be slightly
different than the generic view.
Described below are two content types intended as a wrapper to
indicate the semantic of primary content type. When used they MUST be
the top level content of that message..
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 5]
Internet Draft VPIM UM February 26, 1999
7.1 multipart/voice-message
The MIME sub-type multipart/voice-message is re-defined to hold an
audio content and any number of other content type as described in
[VPIM3]. Essentially, the sub-type provides a simple wrapper that
easily identifies the entire content as being the components of a
single voice message. The sub-type is similar in semantics and syntax
to multipart/mixed, as defined in [MIME2]. The difference introduced
in this revision is that the primary content of this multipart is
voice (audio/*). As such, it may be safely interpreted as a
multipart/mixed by systems that do not understand the sub-type (only
the identification as being a voice message would be lost).
If a receiving system downgrades an incoming message (i.e., drops non-
voice contents for delivery), an appropriate non-delivery message MUST
be sent to the originator indicating that contents were deleted to
deliver the primary voice content. A notification SHOULD also be sent
to the recipient indicating that contents were deleted to deliver the
primary voice message.
In addition to the MIME required boundary parameter, a version
parameter is also REQUIRED for this sub-type. This is to distinguish
this refinement of the sub-type from the previous definition in
[VPIM1] and [V-MSG]. The value of the version parameter is "3.0" if
the content conforms to the requirements of [VPIM3]. The default
version value (when the parameter is missing) is 1, indicating the
content conforms to the requirements of [VPIM1].
Note: [VPIM2] describes the restriction that only specific media types
applicable to voice messaging (audio/*, image/*, message/rfc822 and
application/directory), are valid Ônext-levelÕ contents of this sub-
type (when version=2.0).
3.2 multipart/fax-message
The MIME sub-type multipart/fax is defined to hold a fax image as
described in [IFAX] and any number of other content types.
Essentially, the sub-type provides a simple wrapper that easily
identifies the entire content as being the components of a single fax
message. The sub-type is similar in semantics and syntax to
multipart/mixed, as defined in [MIME2]. The difference is that the
primary content of this multipart is fax (image/tiff). As such, it
may be safely interpreted as a multipart/mixed by systems that do not
understand the sub-type (only the identification as being a fax
message would be lost).
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 6]
Internet Draft VPIM UM February 26, 1999
If a receiving system downgrades an incoming message (i.e., drops non-
fax contents for delivery), a appropriate non-delivery message MUST be
sent to the originator indicating that contents were deleted to
deliver the primary fax content. A notification SHOULD also be sent to
the recipient indicating that contents were deleted to deliver the
primary fax message.
4. IANA Registration
4.1 multipart/voice-message
To: ietf-types@iana.org
Subject: Registration of MIME media type
multipart/voice-message
MIME media type name: multipart
MIME subtype name: voice-message
Required parameters: boundary, version
The use of boundary is defined in [MIME2]
The version parameter contains the value "3.0" if the enclosed
content conforms to [VPIM3]. The version parameter contains
the value "2.0" if the enclosed content conforms to [VPIM2].
The absence of this parameter indicates conformance to the
previous version defined in RFC 1911 [VPIM1].
Optional parameters: none
Encoding considerations: 7bit, 8bit or Binary
Security considerations:
This definition identifies the content as being a voice
message. In some environments (though likely not the
majority), the loss of the anonymity of the content may be a
security issue.
Interoperability considerations:
Systems developed to conform with [VPIM1] and [VPIM2] may not
conform to this registration. Specifically, there may be
unrenderable content types received, in this case the
recipient system should NDN the message. Also the VPIM v1
positional identification will likely be lost.
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 7]
Internet Draft VPIM UM February 26, 1999
Published specification:
This document
[VPIM2]
[VPIM3]
Applications which use this media type:
Primarily unified messaging
Additional information:
Magic number(s): ?
File extension(s): .VPM
Macintosh File Type Code(s): VPIM
Person & email address to contact for further information:
Glenn W. Parsons
Glenn.Parsons@NortelNetworks.com
Gregory M. Vaudreuil
GregV@Lucent.Com
Intended usage: COMMON
Author/Change controller:
Glenn W. Parsons & Gregory M. Vaudreuil
4.2 multpart/fax-message
To: ietf-types@iana.org
Subject: Registration of MIME media type
multipart/fax-message
MIME media type name: multipart
MIME subtype name: fax-message
Required parameters: boundary, version
The use of boundary is defined in [MIME2]
The version parameter that contains the value "1.0" if
enclosed content conforms to [IFAX].
Optional parameters: none
Encoding considerations: 7bit, 8bit or Binary
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 8]
Internet Draft VPIM UM February 26, 1999
Security considerations:
This definition identifies the content as being a fax message.
In some environments (though likely not the majority), the
loss of the anonymity of the content may be a security issue.
Interoperability considerations:
Systems developed strictly to conform with [IFAX] may not be
able to receive multipart/fax-message (though this should be
treate as multipart/mixed). In this case, interoperability
would fail.
Published specification:
This document
[IFAX]
[VPIM3]
Applications which use this media type:
Primarily fax capable unified messaging systems.
Additional information:
Magic number(s): ?
File extension(s): .FAX
Macintosh File Type Code(s): FAX
Person & email address to contact for further information:
Glenn W. Parsons
Glenn.Parsons@NortelNetworks.com
Gregory M. Vaudreuil
GregV@Lucent.Com
Intended usage: COMMON
Author/Change controller:
Glenn W. Parsons & Gregory M. Vaudreuil
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 9]
Internet Draft VPIM UM February 26, 1999
5. AuthorsÕ Addresses
Glenn W. Parsons
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1-613-763-7582
Fax: +1-613-763-4461
Glenn.Parsons@NortelNetworks.com
Marty S. Cohen
Nortel Networks
522 University Ave.
Toronto, Ontario,
M5G 1W7
Canada
Phone: +1-416-597-7264
martyc@nortelnetworks.com
Gregory M. Vaudreuil
Lucent Technologies
17080 Dallas Parkway
Dallas, TX 75248-1905
United States
Phone/Fax: +1-972-733-2722
GregV@Lucent.Com
6. References
[MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft,
First Virtual, Nov 1996.
[MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
Innosoft, First Virtual, Nov 1996.
[VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911,
Feb 1996.
[VPIM2] Greg Vaudreuil and Glenn Parsons, "Voice Profile for Internet
Mail - version 2", RFC 2026, September 1998.
[VPIM3] Work in Progress, "Voice Profile for Internet Mail - version
3", <draft-ema.vpim3-00.txt> February 1999.
[V-MSG] Greg Vaudreuil and Glenn Parsons, "VPIM Voice Message: MIME
Sub-type Registration", RFC 2423, September 1998.
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 10]
Internet Draft VPIM UM February 26, 1999
[REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels" ,RFC 2119, March 1997.
[IFAX] Toyoda et al., "A Simple Mode of Facsimile Using Internet
Mail", RFC 2305, March 1998.
[DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, 01/15/1996.
[MDN] Fajman, Roger, "An Extensible Message Format for Message
Disposition Notifications" RFC 2298, March 1998
7. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 06:01:39 |