Subject: draft-burger-vpim-pc-00.txt

From: [email-masked]
Date: Tue, 6 Jun 2000 08:39:00 -0400

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: [email-masked]
   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
   [email-masked]

   Intended usage: COMMON

  6.2. Primary Content Type Registrations

     6.2.1. voice-message

   To: [email-masked]
   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
   [email-masked]

   Intended usage: COMMON

     6.2.2. fax-message

   To: [email-masked]
   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
   [email-masked]

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: [email-masked]
   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
   [email-masked]

   Intended usage: COMMON

     6.2.4. text-message

   To: [email-masked]
   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
   [email-masked]

   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: [email-masked]

   Emily Candell
   Comverse Network Systems
   200 Quannapowitt Pkwy.
   Wakefield, MA  01880
   USA

   Phone: +1 781/213-2324
   Email: [email-masked]

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]

---

From: Keith Moore <[email-masked]>
Date: Tue, 06 Jun 2000 19:22:13 -0400

some immediate reactions:

1. given that the recipient's UA isn't supposed to indicate an error
   if the message is mislabeled (which I presume means that the message
   is supposed to be presented properly even if the primary-content
   field is incorrect or missing), is the entire purpose of this header 
   field to make it easy to put an icon that shows the recipient the 
   message type?   

   what is this really supposed to convey to the recipient?
   - the kind of device that originated the message?
   - (more abstractly) the context in which this message is sent,
     or in which the sender expects it to be interpreted?
   - hints about possible modes of reply?
   - importance/urgency?  (to some people, a fax inherently has 
     a different importance/urgency than say, voice mail)
   - capabilities you need to be able to display/present this?

2. "primary content" doesn't really seem to capture what this is about.
   then again, I'm not sure what this is about...

3. the available types seem poorly defined, or at least, incomplete.
   either that or they seem to be oriented toward labelling the
   type of device that originated the message.

   what is a "voice message" anyway?  is it any message that contains
   audio or for which the primary content is audio?  is it limited
   to VPIM-compatible audio types.  why not "audio message"?  is 
   music excluded?

   what is the difference between a "fax message" and an ordinary
   message for which the primary content is one or more images?
   are "fax messages" limited to internet fax content-types?
   are they expected to fit on letter or A4 size pages?  etc.

   aren't there a large number of messages which don't fit into
   any of these categories?

---

From: "Milt Roselinsky" <[email-masked]>
Date: Tue, 6 Jun 2000 16:57:07 -0700

I have one comment about this draft.  

Have you thought about using the IMAP annotate draft?
draft-daboo-imapext-annotate-00.txt
Then the VPIM spec could just define the entries and 
attributes that identify a "voicemail" or "fax"message.

Milt

---

From: [email-masked]
Date: Fri, 09 Jun 2000 01:56:16 -0700 (PDT)

> attributes that identify a "voicemail" or "fax"message.

IMAP annotations only apply to messages in message stores, not to messages
being transported. The intent of this mechanism is to allow a message sender to
indicate the type of a message to a recipient, which means a mechanism that
works across message transports has to be used.

				Ned