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

                Voice Profile for Internet Mail - Version 3
                           A Simple Approach
                    <draft-ema-vpim-simplev3-00.txt>

   Status of this Memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

     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 proposes an alternative simple approach to VPIM v3.

   2.  Introduction
     Voice messaging transport over Internet Mail is defined by VPIM v2 
     (RFC 2421)[1].

     The original detailed proposal for VPIM v3 is contained in [10].

     This Internet Draft details a proposed simpler approach at VPIM v3. 
     It is intended to follow the baseline goals described in [5].  Given 
     that VPIM v2 [1] is a well defined (or will be when it is revised for 
     clarity and maturity elevation) description of networking voice-only 
     systems using Internet Mail, and that Internet Mail is being used as-is 
     for multimedia messaging, there is minimal need for a detailed 
     revision.of VPIM to support Unified Messaging.
     
     It is proposed, that all that is needed is an agreement to use 
     Internet Mail without modification and profile a minimal set of Internet 
     Mail standard features that a VPIM v3 compliant system MUST support.  As 
     all devices become connected with email, VPIM v3 compliance will ensure 
     the ability to communicate voice messages between these devices. 


Parsons                 Expires 12/25/99                    [Page 1]

Internet Draft               IMAP Voice                  June 25, 1999

     For more information see http://www.ema.org/vpim/.

   3.  Conventions Used in this Document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as defined in "Key words for
     use in RFCs to Indicate Requirement Levels" [2].

   4.  Message Format

     All messages MUST conform with the Internet Mail format as 
     described in DRUMS [12].  Any content type is allowed to be in a 
     message.
     
     The top level content type on origination of a new, forwarded or 
     reply message SHOULD typically be either multipart/mixed or 
     multipart/voice-message.
     
     The top level content type on origination of a delivery 
     notification message MUST be either multipart/report.
     
     An implementation MAY use the multipart/voice-message content type 
     as described in [6] to package audio content together as a voice 
     message.

   5.  Transport

     All transport MUST support Internet Mail transport (SMTP/ESMTP) as 
     described in DRUMS [11].

   6.  Addressing

     Any valid Internet Mail address MAY be used.  

     However, VPIM onramp and offramp implementations MAY require a 
     stricter addressing structure [7].  As a result, the VPIM addressing 
     structure of [7] MUST be supported for recipient addresses in inbound 
     messages and SHOULD be supported for the originator address if required.
     
     Discovery of an Internet Mail address for a recipientØs voice mail 
     box (if applicable) SHOULD be supported by only knowing the E.164 phone 
     number of the recipient.  (Details of the DNS/LDAP mechanism TBD) 

   7.  Notifications

     DSN MUST be supported.  All non-delivery of messages MUST result 
     in a NDN. Partial DSNs (to indicate that one or more contents could not 
     be stored/relayed by the receiving MTA) SHOULD be supported.
     
     MDN MUST be supported.  Partial MDNs (to indicate that one or more 
     contents could not be rendered) SHOULD be supported.


Parsons                 Expires 12/25/99                    [Page 2]

Internet Draft               IMAP Voice                  June 25, 1999

   8.  Voice Contents

     Voice messages may be contained at any location within a message and 
     MUST be contained in an audio/* content-type.  The parameters described 
     in [1] MUST be used to identify them as voice messages or spoken names. 
     
     The originators spoken name SHOULD be included with a message.  
     Spoken names (for originators and recipients) MAY be included as 
     separate audio contents.  These MAY be referenced from the message 
     header or a vCard.   Spoken names MAY also be included inline with a 
     vCard.  External references SHOULD NOT be used.
     
     Any voice codec may be used.  An implementation SHOULD determine the 
     recipient capabilities before the sending of a message if possible and 
     choose a codec accordingly (a CONNEG and RESCAP profile is needed).  In 
     the absence of recipient knowledge, implementations:
     
     MUST play:     G.726  - audio/32kadpcm or audio/wav; codec=64
                    G.711  - audio/basic or audio/wav; codec=7 
                    MS-GSM - audio/msgsm or audio/wav; codec=31
     
     SHOULD encode: G.726  - audio/32kadpcm or audio/wav; codec=64
                    G.711  - audio/basic or audio/wav; codec=7 
                    MS-GSM - audio/msgsm or audio/wav; codec=31
     
     An implementation MUST be able to play either of the three codecs 
     (either natively or via transcoding) and MUST be able to record and 
     encode messages in at least one of them.  Note that the codecs may 
     appear natively or with a WAVE RIFF header (the codec parameter SHOULD 
     be used on origination so cannot be guaranteed for the recipient).

    9.  IMAP 

     Implementations SHOULD support access to the voice message store using 
     IMAP [3].  The voice extensions described in [9] SHOULD be supported.

   10.  Backwards compatibility with VPIM v2 

     Because of the wide deployed base of VPIM v2, implementations are 
     encouraged to send messages in a format compatible with VPIM v2 systems 
     as described in [1].  Simply, record and encode audio/32kadpcm under a 
     top level multipart/voice-message.  
     
     If a VPIM v3 system has knowledge that the recipient system is 
     VPIM v2 (via CONNEG, RESCAP, LDAP, etc.) it MUST send a VPIM v2 message.
     
     A VPIM v2 system SHOULD reject a message it cannot render with a 
     DSN indicating the media is unsupported.  A VPIM v3 compliant system 
     SHOULD record this information for future sending, and SHOULD resend the 
     original message in a VPIM v2 format. 


Parsons                 Expires 12/25/99                    [Page 3]

Internet Draft               IMAP Voice                  June 25, 1999

   11.  References

   [1]  Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail - 
        version 2", RFC 2421, September 1998.

   [2]  Bradner, S., "Key Words for use in RFCs To Indicate Requirement 
        Levels", RFC 2119, March 1997.

   [3]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 
        RFC 2060, December 1996.

   [4]  Freed, N., Borenstein, N., "Multipurpose Internet Mail 
        Extensions (MIME) Part One: Format of Internet Message Bodies", 
        RFC 2045, November 1996.

   [5] Di Silvestro, Laile, "Goals for VPIM v3", 
       <draft-ema-vpimv3-goals-00.txt>, Work in Progress.

   [6] G. Vaudreuil and G. Parsons, "VPIM Voice Message:  
       MIME Sub-type Registration", RFC 2423, September 1998.

   [7] G. Parsons, G., "VPIM Addressing", 
       <draft-ema-vpim-address-00.txt>, Work in Progress.

   [8]  Parsons, G., Cohen, M., Vaudreuil, G., "VPIM Unified Message 
        MIME Sub-Type Registration", <draft-ema-vpim-um-01.txt>, Work In 
        Progress.

   [9] Parsons, G., "IMAP Voice Extensions", <dravt-ema-vpim-imap-01.txt>,
       Work in Progress. 

   [10]  Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail - 
         version 3", <draft-ema-vpimv3-00.txt>, Work in Progress.

   [11]  Klensin, J,. "Simple Mail Transfer Protocol",  
         <draft-ietf-drums-smtpupd-10.txt>, Work in Progress.

   [12]  Resnick, P., "Internet Message Format Standard",  
         <draft-ietf-drums-msg-fmt-07.txt>, Work in Progress.

   12.  Security Considerations

   TBD

   13.  Author's Address

     Glenn W. Parsons
     Nortel Networks
     P.O. Box 3511, Station C
     Ottawa, ON K1Y 4H7

     Phone: +1-613-763-7582
     Fax: +1-613-763-4461
     Email: gparsons@nortelnetworks.com
   
   
Parsons                 Expires 12/25/99                    [Page 4]

Internet Draft               IMAP Voice                  June 25, 1999

   14.  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 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."





















     Parsons                 Expires 12/25/99                    [Page 5]