Voice Messaging Directory Service
draft-ietf-vpim-vpimdir-11
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4237.
|
|
|---|---|---|---|
| Author | Gregory Vaudreuil | ||
| Last updated | 2020-01-21 (Latest revision 2005-04-08) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4237 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Scott Hollenbeck | ||
| Send notices to | (None) |
draft-ietf-vpim-vpimdir-11
Internet Draft Greg Vaudreuil
Expires in six months Lucent Technologies
April 8, 2005
Voice Messaging Directory Service
<draft-ietf-vpim-vpimdir-11.txt>
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet
Drafts as reference material or to cite them other than as 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 (2005). All Rights Reserved.
Internet Draft VPIM Directory April 8, 2005
Abstract
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.
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 drafts,
one from Anne Brown, and one from Greg Vaudreuil defining a voice
messaging schema into a single working group submission.
Please send comments on this document to the VPIM working group
mailing list <vpim@ietf.org>
Vaudreuil Expires 9/8/05 [Page 2]
Internet Draft VPIM Directory April 8, 2005
Table of Contents
1. SCOPE.............................................................4
1.1 Design Goals....................................................4
1.2 Performance Constraints.........................................4
1.3 Scaling Constraints.............................................4
1.4 Reliability Constraints.........................................4
2. THE VPIMUSER DIRECTORY SCHEMA.....................................5
2.1 vPIMTelephoneNumber.............................................5
2.2 vPIMRfc822Mailbox...............................................6
2.3 vPIMSpokenName..................................................6
2.4 vPIMTextName....................................................6
2.5 vPIMSupportedAudioMediaTypes....................................6
2.6 vPIMSupportedMessageContext.....................................7
2.7 vPIMExtendedAbsenceStatus.......................................7
2.8 vPIMSupportedUABehaviors........................................8
2.9 vPIMMaxMessageSize..............................................8
2.10 vPIMSubMailboxes..............................................9
3. SECURITY CONSIDERATIONS...........................................9
4. IANA CONSIDERATIONS..............................................10
4.1 Object Identifiers.............................................10
4.2 Object Identifier Descriptors..................................10
5. REFERENCES.......................................................12
5.1 Normative References...........................................12
5.2 Informative References.........................................12
6. ACKNOWLEDGMENTS..................................................13
7. INTELLECTUAL PROPERTY NOTICE.....................................14
8. COPYRIGHT NOTICE.................................................14
9. AUTHORSÆ ADDRESS.................................................14
Vaudreuil Expires 9/8/05 [Page 3]
Internet Draft VPIM Directory April 8, 2005
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 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.
1.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.
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.
Vaudreuil Expires 9/8/05 [Page 4]
Internet Draft VPIM Directory April 8, 2005
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 to guide
composition by the sender and to set delivery expectations at
sending time.
2.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.
(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 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.
Vaudreuil Expires 9/8/05 [Page 5]
Internet Draft VPIM Directory April 8, 2005
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. 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 )
Vaudreuil Expires 9/8/05 [Page 6]
Internet Draft VPIM Directory April 8, 2005
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 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.
(IANA-ASSIGNED-OID.2.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].
2.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.
(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 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.
Vaudreuil Expires 9/8/05 [Page 7]
Internet Draft VPIM Directory April 8, 2005
"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.
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 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 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-
".
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
Vaudreuil Expires 9/8/05 [Page 8]
Internet Draft VPIM Directory April 8, 2005
in bytes, that is an unreliable guide to 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 the
recieving mailbox may receive.
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 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) In many countries, privacy laws or regulations exist which
prohibit disclosure of certain kinds of descriptive information
(e.g., text names) Hence, servers 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
Vaudreuil Expires 9/8/05 [Page 9]
Internet Draft VPIM Directory April 8, 2005
use these mechanisms, access controls, and other administrative
controls which may be available to restrict use of attributes
containing sensitive information in naming of 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 is vunerable to attacks that redirect the query
to a rogue server and offer malicious data.
4. IANA Considerations
Reference RFC 3383 "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Protocol
(LDAP)"[LDAPREG].
4.1 Object Identifiers
It is requested that IANA register an LDAP Object Identifer 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 XXXX
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
It is requested that IANA register the LDAP Descriptors used in
this technical specification as detailed in the following
template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Vaudreuil Expires 9/8/05 [Page 10]
Internet Draft VPIM Directory April 8, 2005
GregV@ieee.org
Usage: see comment
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
The following descriptors should be 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, Type O is ObjectClass
Vaudreuil Expires 9/8/05 [Page 11]
Internet Draft VPIM Directory April 8, 2005
5. References
5.1 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.
5.2 Informative References
[VPIMV2] Vaudreuil, Greg, Parsons, Glenn, "Voice Profile for
Internet Mail, Version 2", RFC 3801, June 2004.
[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 (RFC Editors Queue), February 2005.
Vaudreuil Expires 9/8/05 [Page 12]
Internet Draft VPIM Directory April 8, 2005
Acknowledgments
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
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.
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.
Glenn Parsons has provided essential support over the many years
this document as been in development as chairman of the VPIM
working group.
Vaudreuil Expires 9/8/05 [Page 13]
Internet Draft VPIM Directory April 8, 2005
6. 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.
7. Copyright Notice
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.
8. AuthorsÆ Address
Gregory M. Vaudreuil
Lucent Technologies
9489 Bartgis Ct
Frederick, MD 21702
Email: GregV@ieee.org
Vaudreuil Expires 9/8/05 [Page 14]