Network Working Group E. Burger
Internet Draft Centigram Communications
Document: draft-burger-vpim-pc-00.txt E. Candell
Category: Standards Track Comverse Network Systems
Expires in six Months June 6, 2000
Primary Content of Internet Mail
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 draft documents 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 "work in
progress."
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.
1.
Abstract
This document describes a mechanism for identifying the primary
content type of a multi-part Internet mail message.
Expires 12/6/00 [Page 1]
Primary Content of Internet Mail May 2000
Table of Contents
1. ABSTRACT .........................................................1
2. CONVENTIONS USED IN THIS DOCUMENT ................................2
3. INTRODUCTION .....................................................2
4. PRIMARY-CONTENT REFERENCE FIELD ..................................3
4.1. Primary-Content Syntax .........................................4
4.2. content-type Syntax ............................................4
5. SECURITY CONSIDERATIONS ..........................................4
6. IANA CONSIDERATIONS ..............................................4
6.1. Primary-Content Registration ...................................4
6.2. Primary Content Type Registrations .............................5
6.2.1. voice-message ................................................5
6.2.2. fax-message ..................................................6
6.2.3. video-message ................................................7
6.2.4. text-message .................................................7
7. REFERENCES .......................................................8
8. ACKNOWLEDGMENTS ..................................................9
9. AUTHOR'S ADDRESSES ...............................................9
2.
Conventions used in this document
This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or
recipient.
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 RFC-2119 [2].
FORMATTING NOTE: Notes, such at this one, provide additional
nonessential information that the reader may skip without missing
anything essential. The primary purpose of these non-essential
notes is to convey information about the rationale of this document,
or to place this document in the proper historical or evolutionary
context. Readers whose sole purpose is to construct a conformant
implementation may skip such information. However, it may be of use
to those who wish to understand why we made certain design choices.
3.
Introduction
This document describes the Primary Content identification for
multi-part Internet mail.
Burger and Candell Expires 12/6/00 [Page 2]
Primary Content of Internet Mail May 2000
There is a need for a method of indicating to a User Agent (UA) that
the sender or sending system designates that a particular message is
primarily of some type. For example, some clients put a little fax
or telephone icon next to a message header in the client application
to indicate of the message is fax mail or voice mail, respectively.
In addition, some clients will launch helper applications that are
appropriate to a particular type of primary message type. This is a
different approach than the usual method of launching a helper
application based on one of the (many) media types in the message.
One method of indicating the primary media content of a message is
to examine the media types in the message. However, this requires
the UA to scan the entire message before making this determination.
This is particularly burdensome for the multi-media mail situation,
as voice and especially video mail objects are quite large.
Another method of indicating the primary media content of a message
is to register a multipart/* MIME subtype. For example, the VPIM
Work Group has registered multipart/voice-message to indicate that a
message is primarily voice mail [3]. However, multipart/voice-
message is identical in syntax to multipart/mixed. The only
difference is that VPIM mail transfer agents and user agents
recognize that they can perform special handling of the message
based on it being a voice mail message.
We wish to avoid scanning the entire message. In addition, we wish
to avoid having to create multiple aliases for multipart/mixed every
time someone identifies a new primary content type.
Since the Primary Content indicator is an attribute of the entire
message, it is logical to define a new top-level (RFC 822 [4])
message attribute, Primary-Content.
Primary-Content only serves to identify the primary content type of
the message. It does not provide any indication of content that the
UA must be capable of delivering. It does not imply any message
disposition or delivery notification. See the companion document,
Critical Content of Internet Mail [5], for a mechanism to perform
these tasks.
Since Primary-Content is only an indicator, goofy situations, such
as a message marked "voice-message" but without a voice body part,
MUST NOT generate any error report.
4.
Primary-Content Reference Field
The Primary-Content reference field is a top-level header inserted
by the sending UA to indicate the primary content type of the
message.
Burger and Candell Expires 12/6/00 [Page 3]
Primary Content of Internet Mail May 2000
4.1. Primary-Content Syntax
The syntax of the Primary-Content field, formatted according to the
ABNF [6] is as follows. Note that "Primary-Content" is not case
sensitive, per RFC 822.
"Primary-Content" ":" content-type CRLF
4.2. content-type Syntax
The content-type indicates the primary media content type of the
message. This is an IANA registered value. Current values for
Primary-Content are as follows.
content-type = 1 *( [ "voice-message"]
[ "fax-message" ]
[ "video-message" ]
[ "text-message" ] )
5.
Security Considerations
The intention for this header is to indicate media content type
only. One can imagine one creating an "Application" primary content
type, and have a poorly designed user agent blindly execute a mailed
program.
Don't do that!
6.
IANA Considerations
NOTE: We won't send in any registrations until it looks like this
will become a RFC!
Following the policies outlined in [7], IANA assigns values for
Primary-Content as Specification Required.
6.1. Primary-Content Registration
To: ietf-types@iana.org
Subject: Registration of New Top-Level Header Field Primary-Content
Header name:
Primary-Content
Required parameters:
Single 7bit text value
Parameter value:
Burger and Candell Expires 12/6/00 [Page 4]
Primary Content of Internet Mail May 2000
The parameter value specifies the primary media content type for the
message.
Security considerations:
The intention for this header is to indicate media content type
only. One can imagine one creating an "Application" primary content
type, and have a poorly designed user agent blindly execute a mailed
program.
Published specification:
draft-burger-vpim-pc-00.txt
Applications which use this media type:
Mail
VPIM
FPIM
Additional information: none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
6.2. Primary Content Type Registrations
6.2.1. voice-message
To: ietf-types@iana.org
Subject: Registration of New Primary-Content type voice-message
Primary-Content type name:
voice-message
Required parameters:
none
Optional parameters:
none
Encoding considerations:
none
Security considerations:
none
Interoperability considerations:
User agents declaring the primary content to be voice-message SHOULD
conform to VPIMv2.
Burger and Candell Expires 12/6/00 [Page 5]
Primary Content of Internet Mail May 2000
Published specification:
draft-burger-vpim-pc-00.txt
RFC 2421, Voice Profile for Internet Mail - version 2
Applications which use this media type:
VPIM
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
6.2.2. fax-message
To: ietf-types@iana.org
Subject: Registration of New Primary-Content type fax-message
Primary-Content type name:
fax-message
Required parameters:
none
Optional parameters:
none
Encoding considerations:
none
Security considerations:
none
Interoperability considerations:
none
Published specification:
draft-burger-vpim-pc-00.txt
Applications which use this media type:
FPIM
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Burger and Candell Expires 12/6/00 [Page 6]
Primary Content of Internet Mail May 2000
Intended usage: COMMON
6.2.3. video-message
To: ietf-types@iana.org
Subject: Registration of New Primary-Content type video-message
Primary-Content type name:
voice-message
Required parameters:
none
Optional parameters:
none
Encoding considerations:
none
Security considerations:
none
Interoperability considerations:
none
Published specification:
draft-burger-vpim-pc-00.txt
Applications which use this media type:
VPIM, FPIM
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
6.2.4. text-message
To: ietf-types@iana.org
Subject: Registration of New Primary-Content type text-message
Primary-Content type name:
text-message
Required parameters:
Burger and Candell Expires 12/6/00 [Page 7]
Primary Content of Internet Mail May 2000
none
Optional parameters:
none
Encoding considerations:
none
Security considerations:
none
Interoperability considerations:
none
Published specification:
draft-burger-vpim-pc-00.txt
Applications which use this media type:
VPIM, FPIM
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
7.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3 Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type
Registration", RFC 2423, Lucent Technologies and Northern
Telecom, September 1998.
4 Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
5 Burger, E. and Candell, E., "Critical Content of Internet Mail",
draft-burger-vpim-cc-00.txt, Work in Progress.
Burger and Candell Expires 12/6/00 [Page 8]
Primary Content of Internet Mail May 2000
6 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
7 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
8.
Acknowledgments
Coming soon!
9.
Author's Addresses
Eric Burger
Centigram Communications Corporation
Maryland Technology Center
1375 Piccard Dr., MS 150I
Rockville, MD 20850-4311
USA
Phone: +1 301/212-3320
Email: e.burger@ieee.org
Emily Candell
Comverse Network Systems
200 Quannapowitt Pkwy.
Wakefield, MA 01880
USA
Phone: +1 781/213-2324
Email: emily@comversens.com
Full Copyright Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
Burger and Candell Expires 12/6/00 [Page 9]
Primary Content of Internet Mail May 2000
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Copyright (C) 2000 The Internet Society. 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 implementation 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.
Burger and Candell Expires 12/6/00 [Page 10]