Internet Draft Greg Vaudreuil Expires in six months Lucent Technologies October 14, 2002 Voice Messaging Directory Service Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 Copyright Notice Copyright (C) The Internet Society (2002). 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 Internet Draft VPIM Directory October 14, 2002 Working Group Summary This document combines two earlier Internet drafts defining a voice messaging schema into a single working group submission. These documents are Anne Brown's and Greg Vaudreuil's . Vaudreuil Expires 4/14/03 [Page 2] Internet Draft VPIM Directory October 14, 2002 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. REFERENCES .......................................................10 7. ACKNOWLEDGMENTS ..................................................10 8. COPYRIGHT NOTICE .................................................11 9. AUTHORS' ADDRESSES ...............................................11 10. CHANGE HISTORY ...................................................12 11. OPEN ISSUES ......................................................13 Vaudreuil Expires 4/14/03 [Page 3] Internet Draft VPIM Directory October 14, 2002 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, 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 most at-risk element of the infrastructure. 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 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, a record an order of magnitude larger than common textual elements. 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 4/14/03 [Page 4] Internet Draft VPIM Directory October 14, 2002 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 4/14/03 [Page 5] Internet Draft VPIM Directory October 14, 2002 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 4/14/03 [Page 6] Internet Draft VPIM Directory October 14, 2002 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.5 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.6 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 4/14/03 [Page 7] Internet Draft VPIM Directory October 14, 2002 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.7 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.8 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.9 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 4/14/03 [Page 8] Internet Draft VPIM Directory October 14, 2002 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 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. It anticipated that IANA will provide a replacement value from the IANA standards branch and will replace the OID in this document upon publication as a standards-track document. Vaudreuil Expires 4/14/03 [Page 9] Internet Draft VPIM Directory October 14, 2002 6. References [LDAP] Hodges, J., Morgan, R., "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [32KADPCM] Greg Vaudreuil, Glenn Parsons, "Toll Quality Voice - 32 kbit/s ADPCM: MIME Sub-type Registration", work-in-progress. [CONTEXT] Eric Burger, Emily Candell, Graham Klyne, Charles Eliott, "Message Context for Internet Mail", Work-in-progress. (approved as proposed standard, waiting for RFC publication) [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. [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet Mail, Version 2", work-in-progress. 7. 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 4/14/03 [Page 10] Internet Draft VPIM Directory October 14, 2002 8. Copyright Notice "Copyright (C) The Internet Society (2002). 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." 9. Authors' Addresses Gregory M. Vaudreuil Lucent Technologies, 7291 Williamson Rd Dallas, TX 75214 United States Phone/Fax: +1-972-733-2722 Email: GregV@ieee.org Vaudreuil Expires 4/14/03 [Page 11] Internet Draft VPIM Directory October 14, 2002 10. Change History Changes from -00 Changes the schema from a structural object to an auxiilary object under INETPerson. This makes the schema more compatible with other related directory applications while potentially reducing performance by changing accesses based on telephone number from directory reads to directory searches. Changes the schema attributes to all be prefixed by vPIM. This is to reduce the chance of schema collision. Changes from -01 Changed the vPIMsupportedEncodingTypes attribute to vPIMsupportedAudioMediaType to limit the attribute to expressing the supported audio encodings. Added the vPIMmessageContext attribute to indicate the message contexts the recipient is prepared to accept. This replaces the unworkable vPIMSupportedEncodingTypes for communicating the recipient's capabilities. Expanded the vPIMsupportedUABehaviors to include MessagePrivacy and MessageUrgency to indicate client support for the indication of urgency and privacy. Changes from -02 Extraneous whitespace removed from BNF Quotation marks surounding Syntax numericoids removed Corrected syntax of vPIMSupportedMessageContexts Changes requirement level from SHOULD to MUST for ADPCM encoding of vPIMSpokenName. If an alternate encoding is needed, a separate attribute should be defined. Changed the values of the supported UA behaviors to messageSensitivity and messageImportance to align on these more precisely defined terms. Other various spelling and grammer bugs and nits addressed. Aligned the definitions with the LDAPv3 conventions - indicated which elements are single-value - Changed equality rules to desc from numericoid Change the schema to be auxiliary, but not specifically to INETorgPerson. This was not appropriate for all environments. Many other changes. Vaudreuil Expires 4/14/03 [Page 12] Internet Draft VPIM Directory October 14, 2002 11. Open Issues None known at this time. Vaudreuil Expires 4/14/03 [Page 13]