    Network Working Group                                       G. Vaudreuil
    Request for Comments: 4237                           Lucent Technologies
    Category: Standards Track                                   October 2005

                       Voice Messaging Directory Service

    Status of This Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (2005).

    Abstract

       This document provides details of the Voice Profile for Internet Mail
       (VPIM) directory service.  The service provides the email address of
       the recipient that is given a telephone number.  It optionally
       provides the spoken name of the recipient and the media capabilities
       of the recipient.

       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.  This document combines two earlier documents, one from
       Anne Brown and one from Greg Vaudreuil, that define a voice messaging
       schema into a single working group submission.

    Vaudreuil                   Standards Track                     [Page 1]

    RFC 4237           Voice Messaging Directory Service        October 2005

    Table of Contents

       1. Scope ...........................................................2
          1.1. Design Goals ...............................................2
          1.2. Performance Constraints ....................................2
          1.3. Scaling Constraints ........................................3
          1.4. Reliability Constraints ....................................3
       2. The VPIMUser Directory Schema ...................................3
          2.1. vPIMTelephoneNumber ........................................4
          2.2. vPIMRfc822Mailbox ..........................................4
          2.3. vPIMSpokenName .............................................4
          2.4. vPIMTextName ...............................................5
          2.5. vPIMSupportedAudioMediaTypes ...............................5
          2.6. vPIMSupportedMessageContext ................................5
          2.7. vPIMExtendedAbsenceStatus ..................................6
          2.8. vPIMSupportedUABehaviors ...................................6
          2.9. vPIMMaxMessageSize .........................................7
          2.10. vPIMSubMailboxes ..........................................8
       3. Security Considerations .........................................8
       4. IANA Considerations .............................................9
          4.1. Object Identifiers .........................................9
          4.2. Object Identifier Descriptors ..............................9
       5. References .....................................................10
          5.1. Normative References ......................................10
          5.2. Informative References ....................................10

    1.  Scope

    1.1.  Design Goals

       The VPIM directory Schema (VPIMDIR) is accessed from outside the
       enterprise or service provider domain using the recipient's telephone
       number.

    1.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 of 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.

    Vaudreuil                   Standards Track                     [Page 2]

    RFC 4237           Voice Messaging Directory Service        October 2005

    1.3.  Scaling Constraints

       A service provider's namespace is expected to include entries for
       tens of millions of 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 provider's 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 a spoken name
       will not add appreciable latency; however, it will add to the need
       for storage capacity.

    1.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.

    2.  The VPIMUser Directory Schema

          (IANA-ASSIGNED-OID.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 for guiding composition by the
       sender and for setting delivery expectations at sending time.

    Vaudreuil                   Standards Track                     [Page 3]

    RFC 4237           Voice Messaging Directory Service        October 2005

    2.1.  vPIMTelephoneNumber

       The attribute vPIMTelephoneNumber is the full E.164 form of the
       telephone number [E164], including any sub-addressing portion.  The
       normal search will be for this attribute.

          (IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber'
                              EQUALITY caseIgnoreMatch
                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} )

       Example: A North American telephone number with the sub address of 12
       would be represented as "+12145551212+12".

       Note that 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
       hyphens.  The leading '+' and the '+' delineating the submailbox are
       required markup.

    2.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
       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.

          (IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox'
                            EQUALITY caseIgnoreIA5Match
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

    2.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.

    Vaudreuil                   Standards Track                     [Page 4]

    RFC 4237           Voice Messaging Directory Service        October 2005

       Private or additional encoding types are outside the scope of this
       version.

          (IANA-ASSIGNED-OID.2.3 NAME 'vPIMSpokenName'
                            EQUALITY octetStringMatch
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000}
                            SINGLE-VALUE )

    2.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.

          (IANA-ASSIGNED-OID.2.4 NAME 'vPIMTextName'
                            EQUALITY caseIgnoreMatch
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20}
                            SINGLE-VALUE )

    2.5.  vPIMSupportedAudioMediaTypes

       The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of
       audio encodings that can be received at the address specified in
       vPIMRfc822Mailbox.

          (IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes'
                            EQUALITY caseIgnoreIA5Match
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

       This is a multi-value attribute.  The allowable values 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-".

       Because ADPCM is a required format, the audio32kadpcm value must be
       listed if this attribute is present.

    2.6.  vPIMSupportedMessageContext

       The message context provides guidance to the sender about the message
       contexts the recipient is likely to accept.  Message context provides
       less precise information 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.

    Vaudreuil                   Standards Track                     [Page 5]

    RFC 4237           Voice Messaging Directory Service        October 2005

          (IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext'
                            EQUALITY caseIgnoreIA5Match
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

       This is a multi-value attribute.  The set of valid message context
       values is defined in [CONTEXT].

    2.7.  vPIMExtendedAbsenceStatus

       It is common to have an attribute that indicates 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.

          (IANA-ASSIGNED-OID.2.7 NAME 'vPIMExtendedAbsenceStatus'
                            EQUALITY caseIgnoreIA5Match
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
                            SINGLE-VALUE )

       The three values defined are:

                "Off", "On", "MsgBlocked"

       "Off" indicates that 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 that the recipient has set an extended absence
       indicator, but the mailbox is still accepting messages for review at
       an unspecified future time.

       "MsgBlocked" indicates that 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.

    2.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                   Standards Track                     [Page 6]

    RFC 4237           Voice Messaging Directory Service        October 2005

       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.

          (IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors'
                            EQUALITY caseIgnoreIA5Match
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

       The following behaviors are defined:

                MessageDispositionNotification
                MessageSensitivity
                MessageImportance

       The presence of the MessageDispositionNotification value indicates
       that the recipient will send an 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-".

    2.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, it is an
       unreliable guide for the composer when multiple encodings, multiple
       media, or variable bit-rate encodings are supported.

          (IANA-ASSIGNED-OID.2.9 NAME 'vPIMMaxMessageSize'
                            EQUALITY integerMatch
                            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
                            SINGLE-VALUE )

       The attribute indicates the maximum message length in seconds that
       the receiving mailbox may receive.

    Vaudreuil                   Standards Track                     [Page 7]

    RFC 4237           Voice Messaging Directory Service        October 2005

    2.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.

          (IANA-ASSIGNED-OID.2.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
       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.

    3.  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 that is useful for
          telemarketing, such as the textual name, and may disclose only
          information useful to the sender, such as the recipient's spoken
          name, a data element that is much harder to auto-process.

       2) In many countries, there are privacy laws or regulations that
          prohibit disclosure of certain kinds of descriptive information
          (e.g., text names).  Hence, server implementors are encouraged to
          support DIT structural rules and name forms [LDAPMODELS] as these
          provide a mechanism for administrators to select appropriate
          naming attributes for entries.  Administrators are encouraged to
          use these mechanisms, access controls, and other administrative
          controls, which may be available to restrict use of attributes
          containing sensitive information when naming entries.

       3) The LDAP directory service needs to be secured properly for this
          intended use.  [LDAPAUTH] describes a number of considerations
          that apply in this use.  In particular, this service provides
          unauthenticated, public access to directory data, and as such, it
          is vulnerable to attacks that redirect the query to a rogue server
          and offer malicious data.

    Vaudreuil                   Standards Track                     [Page 8]

    RFC 4237           Voice Messaging Directory Service        October 2005

    4.  IANA Considerations

       Reference RFC 3383 "Internet Assigned Numbers Authority (IANA)
       Considerations for the Lightweight Directory Access Protocol (LDAP)"
       [LDAPREG].

    4.1.  Object Identifiers

       IANA has registered an LDAP Object Identifier for use in this
       technical specification, according to the following template:

       Subject: Request for LDAP OID Registration

       Person & email address to contact for further information:

          Greg Vaudreuil (gregv@ieee.org)

       Specification: RFC 4237

       Author/Change Controller: IESG

       Comments:

       The assigned OID will be used as a base for identifying a number of
       schema elements defined in this document.

    4.2.  Object Identifier Descriptors

       IANA has registered the LDAP Descriptors used in this technical
       specification, as detailed in the following template:

       Subject: Request for LDAP Descriptor Registration Update

       Descriptor (vPIM): see comment

       Object Identifier: see comment

       Person & email address to contact for further information:

          GregV@ieee.org

       Usage: see comment

       Specification: RFC 4237

       Author/Change Controller: IESG

       Comments:

    Vaudreuil                   Standards Track                     [Page 9]

    RFC 4237           Voice Messaging Directory Service        October 2005

       The following descriptors have been added:

       NAME                            Type    OID
       --------------                  ----    ------------
       vPIMUser                         O      IANA-ASSIGNED-OID.1.1
       vPIMRfc822Mailbox                A      IANA-ASSIGNED-OID.2.1
       vPIMTelephoneNumber              A      IANA-ASSIGNED-OID.2.2
       vPIMSpokenName                   A      IANA-ASSIGNED-OID.2.3
       vPIMSupportedUABehaviors         A      IANA-ASSIGNED-OID.2.4
       vPIMSupportedAudioMediaTypes     A      IANA-ASSIGNED-OID.2.5
       vPIMSupportedMessageContext      A      IANA-ASSIGNED-OID.2.6
       vPIMTextName                     A      IANA-ASSIGNED-OID.2.7
       vPIMExtendedAbsenceStatus        A      IANA-ASSIGNED-OID.2.8
       vPIMMaxMessageSize               A      IANA-ASSIGNED-OID.2.9
       vPIMSubMailboxes                 A      IANA-ASSIGNED-OID.2.10

       Where Type A is Attribute and Type O is ObjectClass

    5.  References

    5.1.  Normative References

       [LDAP]       Hodges, J. and R. Morgan, "Lightweight Directory Access
                    Protocol (v3): Technical Specification", RFC 3377,
                    September 2002.

       [32KADPCM]   Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32
                    kbit/s Adaptive Differential Pulse Code Modulation
                    (ADPCM) MIME Sub-type Registration", RFC 3802, June
                    2004.

       [CONTEXT]    Burger, E., Candell, E., Eliot, C., and G. Klyne,
                    "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.

    5.2.  Informative References

       [VPIMV2]     Vaudreuil, G. and G. Parsons, "Voice Profile for
                    Internet Mail - version 2 (VPIMv2)", RFC 3801, June
                    2004.

    Vaudreuil                   Standards Track                    [Page 10]

    RFC 4237           Voice Messaging Directory Service        October 2005

       [LDAPREG]    Zeilenga, K., "Internet Assigned Numbers Authority
                    (IANA) Considerations for the Lightweight Directory
                    Access Protocol (LDAP)", BCP 64, RFC 3383, September
                    2002.

       [LDAPAUTH]   Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
                    "Authentication Methods for LDAP", RFC 2829, May 2000.

       [LDAPMODELS] Zeilenga, K., "LDAP: Directory Information Models" Work
                    in Progress, February 2005.

    Acknowledgements

       This directory schema 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 version of this
       document.

       Bernhard Elliot, working with the TMIA, has provided most of the
       organizational impetus to get this project moving, which was a
       substantial task given the sometimes slow and bureaucratic nature of
       the voice mail industry and regulatory environment.

       Thanks to 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.

       As chairman of the VPIM working group, Glenn Parsons has provided
       essential support over the many years this document has been in
       development.

    Vaudreuil                   Standards Track                    [Page 11]

    RFC 4237           Voice Messaging Directory Service        October 2005

    Author's Address

       Please send comments on this document to the VPIM working group
       mailing list <vpim@ietf.org>.

       Gregory M. Vaudreuil
       Lucent Technologies
       9489 Bartgis Ct
       Frederick, MD 21702

       EMail: GregV@ieee.org

    Vaudreuil                   Standards Track                    [Page 12]

    RFC 4237           Voice Messaging Directory Service        October 2005

    Full Copyright Statement

       Copyright (C) The Internet Society (2005).

       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.

       This document and the information contained herein are provided on an
       "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
       OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
       ENGINEERING TASK FORCE DISCLAIM 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.

    Intellectual Property

       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights 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; nor does it represent that it has
       made any independent effort to identify any such rights.  Information
       on the procedures with respect to rights in RFC documents can be
       found in BCP 78 and BCP 79.

       Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
       specification can be obtained from the IETF on-line IPR repository at
       http://www.ietf.org/ipr.

       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights that may cover technology that may be required to implement
       this standard.  Please address the information to the IETF at ietf-
       ipr@ietf.org.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Vaudreuil                   Standards Track                    [Page 13]