One document matched: draft-ema-vpim-um-00.txt


     Internet Draft                                       Greg Vaudreuil
     Expires in six months                           Lucent Technologies
     Obsoletes: RFC 1911, RFC 2423                         Glenn Parsons
                                                         Nortel Networks
                                                        February 1, 1999


                          MIME Sub-type Registrations 
                             for unified messaging


                           <draft-ema-vpim-um-00.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), ftp.ietf.org (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.
     
     
   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.
     

     Vaudreuil, Parsons       Expires 8/1/99                    [Page 1]
     Internet Draft               VPIM UM               February 1, 1999
     
     
   1.  Abstract
     
     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 
     [VPIM3].  This document revises earlier sub-type registrations in 
     RFC 2423 [V-MSG] for [VPIM2] and RFC 1911 [VPIM1].
     
     
   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.
     
     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].
     
     
   3. Unified Messaging Interchange
     
     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.
     
     Vaudreuil, Parsons       Expires 8/1/99                    [Page 2]
     Internet Draft               VPIM UM               February 1, 1999
     
     
     Additionally, the use of this content type 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..
     
   3.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), a appropriate non-delivery 
     message MUST be sent to the originator indicating that contents 
     were deleted to deliver the primary voice content.
     
     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).
      
     Vaudreuil, Parsons       Expires 8/1/99                    [Page 3]
     Internet Draft               VPIM UM               February 1, 1999
     
     
   3.2 multipart/fax
     
     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).
     
     If a receiving system downgrades an incoming message (i.e., drops 
     non-voice contents for delivery), a appropriate non-delivery 
     message MUST be sent to the originator indicating that contents 
     were deleted to deliver the primary voice content.
     
     
   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
     
     Vaudreuil, Parsons       Expires 8/1/99                    [Page 4]
     Internet Draft               VPIM UM               February 1, 1999
     
     
          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.
     
          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
     
     Vaudreuil, Parsons       Expires 8/1/99                    [Page 5]
     Internet Draft               VPIM UM               February 1, 1999
     
     
   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
     
          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.
     
     Vaudreuil, Parsons       Expires 8/1/99                    [Page 6]
     Internet Draft               VPIM UM               February 1, 1999
     
     
          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
     
     
   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 
     
     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.
     
     Vaudreuil, Parsons       Expires 8/1/99                    [Page 7]
     Internet Draft               VPIM UM               February 1, 1999
     
     
     [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.
     
     [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.
     
   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       Expires 8/1/99                    [Page 8]

PAFTECH AB 2003-20262026-04-23 06:04:41