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
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
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.
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.
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
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.
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} )
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 )
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.
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].
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.
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 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-".
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
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.
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
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
[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.
[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>.
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.