Internet Draft                                       Greg Vaudreuil
     Expires in six months                           Lucent Technologies
                                                           July 07, 2004
  
  
                       Voice Messaging Directory Service
  
  
                        <draft-ietf-vpim-vpimdir-07.txt>
  
  
  
  
  
  Status of this Memo
  
  
     This document is an Internet-Draft and is subject to all provisions of
     Section 10 of RFC 2026.
  
  
     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".
  
  
     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html
  
  
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html
  
  
  
  
  
  Intellectual Property Notice
  
  
     By submitting this Internet-Draft, I certify that any applicable
     patent or other IPR claims of which I am aware have been disclosed, or
     will be disclosed, and any of which I become aware will be disclosed,
     in accordance with RFC 3668.
  
  
  Copyright Notice
  
  
     Copyright (C) The Internet Society (2004).  All Rights Reserved.
  
  
     This Internet-Draft is in conformance with Section 10 of RFC2026.
  
  
  Overview
  
  
     This document provides details of the VPIM directory service.  The
     service provides the email address of the recipient given a telephone
     number.  It optionally provides the spoken name of the recipient and
     the media capabilities of the recipient.
  
  
     Please send comments on this document to the VPIM working group
     mailing list <vpim@lists.neystadt.org>
  
  
  
     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
  Working Group Summary
  
  
     This document combines two earlier drafts, one from Anne Brown, and
     one from Greg Vaudreuil defining a voice messaging schema into a
     single working group submission.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Vaudreuil                Expires 1/07/05                   [Page 2]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
  Table of Contents
  
  
  1.   ABSTRACT ..........................................................4
  2.   SCOPE .............................................................4
    2.1  Design Goals ....................................................4
    2.2  Performance Constraints .........................................4
    2.3  Scaling Constraints .............................................4
    2.4  Reliability Constraints .........................................4
  3.   THE VPIMUSER DIRECTORY SCHEMA .....................................5
    3.1  vPIMTelephoneNumber .............................................5
    3.2  vPIMRfc822Mailbox ...............................................5
    3.3  vPIMSpokenName ..................................................6
    3.4  vPIMTextName ....................................................6
    3.5  vPIMSupportedAudioMediaTypes ....................................6
    3.6  vPIMSupportedMessageContext .....................................7
    3.7  vPIMExtendedAbsenceStatus .......................................7
    3.8  vPIMSupportedUABehaviors ........................................7
    3.9  vPIMMaxMessageSize ..............................................8
    3.10  vPIMSubMailboxes ...............................................8
  4.   SECURITY CONSIDERATIONS ...........................................9
  5.   IANA CONSIDERATIONS ...............................................9
  6.   NORMATIVE REFERENCES .............................................10
  7.   INFORMATIVE REFERENCES ...........................................10
  8.   ACKNOWLEDGMENTS ..................................................10
  9.   INTELLECTUAL PROPERTY NOTICE .....................................11
  10.  COPYRIGHT NOTICE .................................................11
  11.  AUTHORS' ADDRESS .................................................11
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Vaudreuil                Expires 1/07/05                   [Page 3]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
  1. Abstract
  
  
     The VPIM directory Schema provides essential additional attributes to
     recreate the voice mail user experience using standardized
     directories.  This user experience provides, at the time of
     addressing, basic assurances that the message will be delivered as
     intended.
  
  
  2. Scope
  
  
  2.1 Design Goals
  
  
     The VPIM directory Schema (VPIMDIR) is accessed from outside the
     enterprise or service provider domain using the recipient's telephone
     number.
  
  
  2.2 Performance Constraints
  
  
     Once the identity of the VPIM directory server is known, the email
     address, capabilities and spoken name confirmation information can be
     retrieved. This query is expected to use LDAP [LDAP], a connection-
     oriented protocol.  The protocol transaction includes multiple packet
     round-trips to execute the query and retrieval and is considered to be
     the highest latency element of the messaging service.  Further,
     retrieval of the confirmation information may require the return of a
     spoken name segment up to 20kbytes (5 seconds at 4kbytes/second).
     Over a sufficiently engineered Internet connection, a 1250 ms response
     time is believed to be achievable over the Internet at large.
  
  
  2.3 Scaling Constraints
  
  
     A service provider's namespace is expected to include entries for tens
     of million subscribers in a flat namespace based on the VPIM inter-
     domain address form: telephone_number@domain_name.  A large
     corporation may have a hundred-thousand entries while a large service
     provider may have tens of millions of entries in a single domain.  It
     is expected that there will be a single public address validation
     service for a given service providers network.  It is believed that
     existing directory technology including horizontal scalability through
     replication will provide sufficient transaction throughput within the
     required latency requirements to address this need.  The only
     fundamental new requirement this application imposes on directory
     servers beyond similar existing services is the ability to return the
     recipient's spoken name.  Preliminary investigation suggests that
     storage and retrieval of spoken name will not add appreciable latency,
     however it will add to the need for storage capacity.
  
  
  2.4 Reliability Constraints
  
  
     DNS provides well-documented redundancy and load-balancing
     capabilities for the VPIMDIR.  However, the latency requirements to
     the end-user may not permit client-side fail-over to a secondary
     server and may require the directory server to be implemented as a
     high-availability service.
  
  
     Vaudreuil                Expires 1/07/05                   [Page 4]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
  
  3. The VPIMUser Directory Schema
  
  
         ( 2.16.840.1.113778.1.9.2.1 NAME 'vPIMUser'
                 SUP 'top'
                 AUXILIARY
                 MUST ( vPIMRfc822Mailbox $
                        vPIMTelephoneNumber )
                 MAY  ( vPIMSpokenName $
                        vPIMSupportedUABehaviors $
                        vPIMSupportedAudioMediaTypes $
                        vPIMSupportedMessageContext $
                        vPIMTextName $
                        vPIMExtendedAbsenceStatus $
                        vPIMMaxMessageSize $
                        vPIMSubMailboxes ) )
  
  
     When present, the vPIMUser object contains information useful for
     verifying that the dialed telephone number corresponds to the intended
     recipient.  This object also provides capability information and
     mailbox status information useful to guide composition by the sender
     and to set delivery expectations at sending time.
  
  
  3.1 vPIMTelephoneNumber
  
  
     The full E.164 form of the telephone number [E164], including any sub-
     addressing portion.  The normal search will be for this attribute.
  
  
     ( 2.16.840.1.113694.1.2.1.1.1 NAME 'vPIMTelephoneNumber'
                         EQUALITY caseIgnoreMatch
                         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
  
  
     Example: A North American telephone number with the sub address of 12
     would be represented as "+12145551212+12".
  
  
     Note vPIMTelephoneNumber is by default a multi-valued attribute.  But
     if an entry has multiple values for this attribute, those values MUST
     be distinct from each other in the telephone number portion.  It is
     expected that each submailbox of a single telephone number will have
     its own vPIMUser entry.
  
  
     The vPIMTelephoneNumber differs from telephoneNumber in [LDAP] in its
     support for sub-addressing information and its use as a voice
     messaging address.  In most cases, these values will be the same.
  
  
     The telephone number is stored with no parenthesis, spaces, dots, or
     hypens.  The leading '+' and the '+' delineating the submailbox are
     required markup.
  
  
  3.2 vPIMRfc822Mailbox
  
  
     The attribute vPIMRfc822Mailbox stores the inter-domain SMTP address
     of the voice mailbox associated with a given telephone number.  It is
     defined as a distinct attribute to distinguish it from the
  
  
     Vaudreuil                Expires 1/07/05                   [Page 5]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
     rfc822Mailbox attribute that may be used for other purposes. Although
     it would be preferable to define vPIMRfc822Mailbox as a subtype of
     rfc822Mailbox, it is defined here as an entirely new attribute because
     some directory implementations do not support sub-typing.
  
  
     ( 2.16.840.1.113694.1.2.1.1.2 NAME 'vPIMRfc822Mailbox'
                       EQUALITY caseIgnoreIA5Match
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
  
  
  3.3 vPIMSpokenName
  
  
     The vPIMSpokenName attribute is an octet string and MUST be encoded in
     32 kbit/s ADPCM exactly as defined by [32KADPCM].  vPIMSpokenName
     shall contain the spoken name of the user in the voice of the user.
     The length of the spoken name segment MUST NOT exceed five seconds.
     Private or additional encoding types are outside the scope of this
     version.
  
  
  
     ( 2.16.840.1.113694.1.2.1.1.3 NAME 'vPIMSpokenName'
                       EQUALITY octetStringMatch
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000}
                       SINGLE-VALUE )
  
  
  3.4 vPIMTextName
  
  
     The text name is designed to be consistent with the unstructured text
     name databases used for calling name delivery service of caller ID.
  
  
     ( 2.16.840.1.113694.1.2.1.1.4 NAME 'vPIMTextName'
                       EQUALITY caseIgnoreMatch
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20}
                       SINGLE-VALUE )
  
  
     The VPIMTextName MUST be a UTF-8 encoded string [UTF8].
  
  
  3.5 vPIMSupportedAudioMediaTypes
  
  
     The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of
     audio encodings that can be received at the address specified in
     vPIMRfc822Mailbox.
  
  
     ( 2.16.840.1.113694.1.2.1.1.5 NAME 'vPIMSupportedAudioMediaTypes'
                       EQUALITY caseIgnoreIA5Match
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
  
  
     The allowable values of DirectoryString for this attribute are the
     MIME audio subtypes registered with IANA.  Non-standard and private
     encoding types must be indicated by prepending the new type name with
     either "X-" or "x-".
  
  
     The audio32kadpcm value must be present if this attribute is present.
  
  
  
  
     Vaudreuil                Expires 1/07/05                   [Page 6]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
  3.6 vPIMSupportedMessageContext
  
  
     The message context provides guidance to the sender about the message
     contexts the recipient is likely to accept.  Message context provides
     less precision about a given recipient's capabilities than a list of
     media types.  However, given the growing role of media-conversion
     gateways, the context indicator provides more useful guidance to a
     sender in a "unified messaging" environment.
  
  
     ( 2.16.840.1.113694.1.2.1.1.6 NAME 'vPIMSupportedMessageContext'
                       EQUALITY caseIgnoreIA5Match
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
  
  
     The set of valid message context values are defined in [CONTEXT].
  
  
  3.7 vPIMExtendedAbsenceStatus
  
  
     It is common to have an attribute to indicate to the subscriber
     whether the recipient is accepting messages during his absence.  This
     feature -- called "extended absence" -- provides an advisory message
     at sending time.  It is similar in concept to "vacation notices"
     common for textual email but has its own cultural and operational
     nuances.
  
  
     ( 2.16.840.1.113694.1.2.1.1.7 NAME 'vPIMExtendedAbsenceStatus'
                       EQUALITY caseIgnoreMatch
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
                       SINGLE-VALUE )
  
  
     The three values defined are:
  
  
                "Off", "On", "MsgBlocked"
  
  
     "Off" indicates the recipient either does not support extended absence
     or has not set such an indicator. "Off" is the default condition if
     this attribute is not returned.
  
  
     "On" indicates the recipient has set an extended absence indicator,
     but the mailbox is still accepting messages for review at an
     unspecified future time.
  
  
     "MsgBlocked" indicates the recipient has set an extended absence
     indicator and the mailbox is currently configured to reject incoming
     messages.  Messages SHOULD NOT be sent to the recipient if this value
     is returned in the vPIMExtendedAbsenceStatus attribute.
  
  
  3.8 vPIMSupportedUABehaviors
  
  
     Internet mail does not provide facilities for the sender to know
     whether the recipient supports a number of optional features that can
     be requested or indicated in the RFC822 headers.  This attribute
     provides a list of the attributes considered optional by VPIM and
     other vendor-specific attributes that may be supported by the
     recipient.  If this attribute is not supported, only those attributes
  
  
     Vaudreuil                Expires 1/07/05                   [Page 7]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
     listed as mandatory in VPIM are assumed to be supported.  Undisclosed
     behaviors may be indicated in the RFC822 message; however there is no
     assurance by the receiving system of their support.
  
  
     ( 2.16.840.1.113694.1.2.1.1.8 NAME 'vPIMSupportedUABehaviors'
                       EQUALITY caseIgnoreMatch
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
  
  
     The following behaviors are defined:
  
  
                 MessageDispositionNotification
                 MessageSensitivity
                 MessageImportance
  
  
     The presence of the MessageDispositionNotification value indicates
     that the recipient will send a MDN in response to an MDN request.
  
  
     MessageSensitivity indicates that the recipient fully supports the
     sensitivity indication as defined in VPIM [VPIMV2].
  
  
     MessageImportance indicates that the recipient fully supports the
     importance indication as defined in VPIM [VPIMV2].
  
  
     These may be further extended without standardization to include
     proprietary user interface functional extensions.  These proprietary
     extension values must be prefixed with an "X-" or "x-".
  
  
  3.9 vPIMMaxMessageSize
  
  
     At the time of composition, the message can be checked for acceptable
     length using the maximum message size attribute.  Maximum message size
     is an attribute usually configured by policy of the receiving system,
     typically in units of minutes.  While ESMTP provides a mechanism to
     determine if a message is too long in bytes, that is an unreliable
     guide to the composer when multiple encodings, multiple media, or
     variable bit-rate encodings are supported.
  
  
     ( 2.16.840.1.113694.1.2.1.1.9 NAME 'vPIMMaxMessageSize'
                       EQUALITY integerMatch
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
                       SINGLE-VALUE )
  
  
  3.10 vPIMSubMailboxes
  
  
     This attribute indicates the presence of sub-mailboxes for the queried
     telephone number.  This information may be used to provide a post-dial
     sub-addressing menu to the sender.
  
  
     ( 2.16.840.1.113694.1.2.1.1.10 NAME 'vPIMSubMailboxes'
                       EQUALITY numericStringMatch
                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} )
  
  
     The allowable values include a list of sub-mailbox numbers with a
     numeric range of 1-9999.  The user interface may use this information
  
  
     Vaudreuil                Expires 1/07/05                   [Page 8]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
     to prompt the sender to select a sub-mailbox.  Spoken names associated
     with each sub-mailbox may be individually retrieved by subsequent
     queries to the recipient's VPIMDIR service.
  
  
  4. Security Considerations
  
  
     The following are known security issues.
  
  
     1) Service provider customer information is very sensitive, especially
     in this time of local phone competition.  Service providers require
     maximum flexibility to protect this data.  Because of the dense nature
     of telephone number assignments, this data is subject to "go fish"
     queries via repeated LDAP queries to determine a complete list of
     current or active messaging subscribers.  To reduce the value of this
     retrieved data, service providers may limit disclosure of data useful
     for telemarketing such as the textual name and disclose only
     information useful to the sender such as the recipient's spoken name,
     a data element much harder to auto-process.
  
  
     2) Service providers operate in a regulated environment where certain
     information about a subscriber must not be disclosed.  Voice Messaging
     is subject to caller-ID blocking restrictions, restrictions enforced
     in the telephony network.  No such protection is curently available on
     the Internet.  The protection of this data is essential, but is up to
     the individual service providers to appropriately limit disclosure of
     this information.
  
  
  5. IANA Considerations
  
  
     The OID specified in this draft for the VPIMUser is from the Lucent
     proprietary branch.  The objects are using OIDs from the Nortel
     proprietary branch.  It anticipated that IANA will provide a
     replacement value from the IANA standards branch and will replace the
     OIDs in this document upon publication as a standards-track document.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Vaudreuil                Expires 1/07/05                   [Page 9]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
  6. Normative References
  
  
  [LDAP] Hodges, J., Morgan, R., "Lightweight Directory Access Protocol
      (v3): Technical Specification", RFC 3377, September 2004.
  
  
  [32KADPCM] Greg Vaudreuil, Glenn Parsons, "Toll Quality Voice - 32
      kbit/s ADPCM:  MIME Sub-type Registration", RFC 3802, June 2004.
  
  
  [CONTEXT] Eric Burger, Emily Candell, Graham Klyne, Charles Eliott,
      "Message Context for Internet Mail", RFC 3458, January 2003
  
  
  [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN
      Operation, Numbering, Routing and  Mobile Service - Numbering Plan
      for the ISDN Era.
  
  
  [UTF8] RFC 2279 UTF-8, a transformation format of ISO 10646. F. Yergeau.
      January 1998.
  
  
  7. Informative References
  
  
  [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet
      Mail, Version 2", RFC 3801, June 2004.
  
  
  
  
  
  8. Acknowledgments
  
  
     This experimental directory builds upon the earlier work of Carl
     Malamud and Marshall Rose in their TPC.INT remote printing experiment
     and the work lead by Anne Brown as part of the EMA voice messaging
     committee's directory effort.  Anne Brown has provided important
     leadership and was a co-author of the original draft of this document.
  
  
     Bernhard Elliot working with the TMIA has provided most of the
     organizational impetus to get this project moving, a substantial task
     given the sometimes slow and bureaucratic nature of the voice mail
     industry and regulatory environment.
  
  
     Dave Dudley and the Messaging Alliance (TMA) for their early work in
     pioneering a shared directory service for voice messaging and their
     continuing efforts to apply that work to this effort.
  
  
     Greg White and Jeff Bouis, both of Lucent Technologies, provided
     invaluable assistance in reviewing and sanity checking.  Countless
     errors and inconsistencies were corrected with their diligent review.
  
  
  
  
  
  
  
  
  
  
  
  
     Vaudreuil                Expires 1/07/05                  [Page 10]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
  9. Intellectual Property Notice
  
  
     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 proprietary rights
     by implementors 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.
  
  
  10. Copyright Notice
  
  
     "Copyright (C) The Internet Society (2004). 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."
  
  
  11. Authors' Address
  
  
  
  
  
  
     Vaudreuil                Expires 1/07/05                  [Page 11]


     Internet Draft           VPIM Directory               July 07, 2004
  
  
  
     Gregory M. Vaudreuil
     Lucent Technologies
     7380 Hilltop Dr.
     Frederick, MD 21702
     Email: GregV@ieee.org
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Vaudreuil                Expires 1/07/05                  [Page 12]