idnits 2.17.1 draft-ietf-vpim-vpimdir-11.txt: -(84): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(122): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 33. -- Found old boilerplate from RFC 3978, Section 5.5 on line 565. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 556), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 29 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '... MUST ( vPIMRfc822Mail...' RFC 2119 keyword, line 141: '... MAY ( vPIMSpokenName...' RFC 2119 keyword, line 172: '... values MUST be distinct from ea...' RFC 2119 keyword, line 201: '...tribute is an octet string and MUST be...' RFC 2119 keyword, line 204: '...length of the spoken name segment MUST...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 8, 2005) is 6958 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'LDAPREG' is defined on line 490, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3377 (ref. 'LDAP') (Obsoleted by RFC 4510) -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' -- Obsolete informational reference (is this intentional?): RFC 3383 (ref. 'LDAPREG') (Obsoleted by RFC 4520) -- Obsolete informational reference (is this intentional?): RFC 2829 (ref. 'LDAPAUTH') (Obsoleted by RFC 4510, RFC 4513) Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Greg Vaudreuil 2 Expires in six months Lucent Technologies 3 April 8, 2005 5 Voice Messaging Directory Service 7 9 Status of this Memo 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its Areas, and its Working Groups. Note that 13 other groups may also distribute working documents as Internet 14 Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Intellectual Property Notice 30 By submitting this Internet-Draft, I certify that any applicable 31 patent or other IPR claims of which I am aware have been 32 disclosed, or will be disclosed, and any of which I become aware 33 will be disclosed, in accordance with RFC 3668. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document provides details of the VPIM directory service. 42 The service provides the email address of the recipient given a 43 telephone number. It optionally provides the spoken name of the 44 recipient and the media capabilities of the recipient. 46 The VPIM directory Schema provides essential additional 47 attributes to recreate the voice mail user experience using 48 standardized directories. This user experience provides, at the 49 time of addressing, basic assurances that the message will be 50 delivered as intended.This document combines two earlier drafts, 51 one from Anne Brown, and one from Greg Vaudreuil defining a voice 52 messaging schema into a single working group submission. 54 Please send comments on this document to the VPIM working group 55 mailing list 56 Table of Contents 58 1. SCOPE.............................................................4 59 1.1 Design Goals....................................................4 60 1.2 Performance Constraints.........................................4 61 1.3 Scaling Constraints.............................................4 62 1.4 Reliability Constraints.........................................4 63 2. THE VPIMUSER DIRECTORY SCHEMA.....................................5 64 2.1 vPIMTelephoneNumber.............................................5 65 2.2 vPIMRfc822Mailbox...............................................6 66 2.3 vPIMSpokenName..................................................6 67 2.4 vPIMTextName....................................................6 68 2.5 vPIMSupportedAudioMediaTypes....................................6 69 2.6 vPIMSupportedMessageContext.....................................7 70 2.7 vPIMExtendedAbsenceStatus.......................................7 71 2.8 vPIMSupportedUABehaviors........................................8 72 2.9 vPIMMaxMessageSize..............................................8 73 2.10 vPIMSubMailboxes..............................................9 74 3. SECURITY CONSIDERATIONS...........................................9 75 4. IANA CONSIDERATIONS..............................................10 76 4.1 Object Identifiers.............................................10 77 4.2 Object Identifier Descriptors..................................10 78 5. REFERENCES.......................................................12 79 5.1 Normative References...........................................12 80 5.2 Informative References.........................................12 81 6. ACKNOWLEDGMENTS..................................................13 82 7. INTELLECTUAL PROPERTY NOTICE.....................................14 83 8. COPYRIGHT NOTICE.................................................14 84 9. AUTHORS� ADDRESS.................................................14 85 1. Scope 87 1.1 Design Goals 89 The VPIM directory Schema (VPIMDIR) is accessed from outside the 90 enterprise or service provider domain using the recipient's 91 telephone number. 93 1.2 Performance Constraints 95 Once the identity of the VPIM directory server is known, the 96 email address, capabilities and spoken name confirmation 97 information can be retrieved. This query is expected to use LDAP 98 [LDAP], a connection-oriented protocol. The protocol transaction 99 includes multiple packet round-trips to execute the query and 100 retrieval and is considered to be the highest latency element of 101 the messaging service. Further, retrieval of the confirmation 102 information may require the return of a spoken name segment up to 103 20kbytes (5 seconds at 4kbytes/second). Over a sufficiently 104 engineered Internet connection, a 1250 ms response time is 105 believed to be achievable over the Internet at large. 107 1.3 Scaling Constraints 109 A service provider's namespace is expected to include entries for 110 tens of million subscribers in a flat namespace based on the VPIM 111 inter-domain address form: telephone_number@domain_name. A large 112 corporation may have a hundred-thousand entries while a large 113 service provider may have tens of millions of entries in a single 114 domain. It is expected that there will be a single public 115 address validation service for a given service providers network. 116 It is believed that existing directory technology including 117 horizontal scalability through replication will provide 118 sufficient transaction throughput within the required latency 119 requirements to address this need. The only fundamental new 120 requirement this application imposes on directory servers beyond 121 similar existing services is the ability to return the 122 recipient�s spoken name. Preliminary investigation suggests that 123 storage and retrieval of spoken name will not add appreciable 124 latency, however it will add to the need for storage capacity. 126 1.4 Reliability Constraints 128 DNS provides well-documented redundancy and load-balancing 129 capabilities for the VPIMDIR. However, the latency requirements 130 to the end-user may not permit client-side fail-over to a 131 secondary server and may require the directory server to be 132 implemented as a high-availability service. 134 2. The VPIMUser Directory Schema 136 (IANA-ASSIGNED-OID.1 NAME 'vPIMUser' 137 SUP 'top' 138 AUXILIARY 139 MUST ( vPIMRfc822Mailbox $ 140 vPIMTelephoneNumber ) 141 MAY ( vPIMSpokenName $ 142 vPIMSupportedUABehaviors $ 143 vPIMSupportedAudioMediaTypes $ 144 vPIMSupportedMessageContext $ 145 vPIMTextName $ 146 vPIMExtendedAbsenceStatus $ 147 vPIMMaxMessageSize $ 148 vPIMSubMailboxes ) ) 150 When present, the vPIMUser object contains information useful for 151 verifying that the dialed telephone number corresponds to the 152 intended recipient. This object also provides capability 153 information and mailbox status information useful to guide 154 composition by the sender and to set delivery expectations at 155 sending time. 157 2.1 vPIMTelephoneNumber 159 The full E.164 form of the telephone number [E164], including any 160 sub-addressing portion. The normal search will be for this 161 attribute. 163 (IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber' 164 EQUALITY caseIgnoreMatch 165 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44(20) ) 167 Example: A North American telephone number with the sub address 168 of 12 would be represented as "+12145551212+12". 170 Note vPIMTelephoneNumber is by default a multi-valued attribute. 171 But if an entry has multiple values for this attribute, those 172 values MUST be distinct from each other in the telephone number 173 portion. It is expected that each submailbox of a single 174 telephone number will have its own vPIMUser entry. 176 The vPIMTelephoneNumber differs from telephoneNumber in [LDAP] in 177 its support for sub-addressing information and its use as a voice 178 messaging address. In most cases, these values will be the same. 180 The telephone number is stored with no parenthesis, spaces, dots, 181 or hypens. The leading '+' and the '+' delineating the 182 submailbox are required markup. 184 2.2 vPIMRfc822Mailbox 186 The attribute vPIMRfc822Mailbox stores the inter-domain SMTP 187 address of the voice mailbox associated with a given telephone 188 number. It is defined as a distinct attribute to distinguish it 189 from the rfc822Mailbox attribute that may be used for other 190 purposes. Although it would be preferable to define 191 vPIMRfc822Mailbox as a subtype of rfc822Mailbox, it is defined 192 here as an entirely new attribute because some directory 193 implementations do not support sub-typing. 195 (IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox' 196 EQUALITY caseIgnoreIA5Match 197 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) 199 2.3 vPIMSpokenName 201 The vPIMSpokenName attribute is an octet string and MUST be 202 encoded in 32 kbit/s ADPCM exactly as defined by [32KADPCM]. 203 vPIMSpokenName shall contain the spoken name of the user in the 204 voice of the user. The length of the spoken name segment MUST 205 NOT exceed five seconds. Private or additional encoding types 206 are outside the scope of this version. 208 (IANA-ASSIGNED-OID.2.3 NAME 'vPIMSpokenName' 209 EQUALITY octetStringMatch 210 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000} 211 SINGLE-VALUE ) 213 2.4 vPIMTextName 215 The text name is designed to be consistent with the unstructured 216 text name databases used for calling name delivery service of 217 caller ID. 219 (IANA-ASSIGNED-OID.2.4 NAME 'vPIMTextName' 220 EQUALITY caseIgnoreMatch 221 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} 222 SINGLE-VALUE ) 224 2.5 vPIMSupportedAudioMediaTypes 226 The vPIMSupportedAudioMediaTypes attribute indicates the type(s) 227 of audio encodings that can be received at the address specified 228 in vPIMRfc822Mailbox. 230 (IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes' 231 EQUALITY caseIgnoreIA5Match 232 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 234 The allowable values for this attribute are the MIME audio 235 subtypes registered with IANA. Non-standard and private encoding 236 types must be indicated by prepending the new type name with 237 either "X-" or "x-". 239 Because ADPCM is a required format, the audio32kadpcm value must 240 be listed if this attribute is present. 242 2.6 vPIMSupportedMessageContext 244 The message context provides guidance to the sender about the 245 message contexts the recipient is likely to accept. Message 246 context provides less precision about a given recipient�s 247 capabilities than a list of media types. However, given the 248 growing role of media-conversion gateways, the context indicator 249 provides more useful guidance to a sender in a "unified 250 messaging" environment. 252 (IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext' 253 EQUALITY caseIgnoreIA5Match 254 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 256 The set of valid message context values are defined in [CONTEXT]. 258 2.7 vPIMExtendedAbsenceStatus 260 It is common to have an attribute to indicate to the subscriber 261 whether the recipient is accepting messages during his absence. 262 This feature -- called "extended absence" -- provides an advisory 263 message at sending time. It is similar in concept to "vacation 264 notices" common for textual email but has its own cultural and 265 operational nuances. 267 (IANA-ASSIGNED-OID.2.7 NAME 'vPIMExtendedAbsenceStatus' 268 EQUALITY caseIgnoreIA5Match 269 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 270 SINGLE-VALUE ) 272 The three values defined are: 274 "Off", "On", "MsgBlocked" 276 "Off" indicates the recipient either does not support extended 277 absence or has not set such an indicator. "Off" is the default 278 condition if this attribute is not returned. 280 "On" indicates the recipient has set an extended absence 281 indicator, but the mailbox is still accepting messages for review 282 at an unspecified future time. 284 "MsgBlocked" indicates the recipient has set an extended absence 285 indicator and the mailbox is currently configured to reject 286 incoming messages. Messages SHOULD NOT be sent to the recipient 287 if this value is returned in the vPIMExtendedAbsenceStatus 288 attribute. 290 2.8 vPIMSupportedUABehaviors 292 Internet mail does not provide facilities for the sender to know 293 whether the recipient supports a number of optional features that 294 can be requested or indicated in the RFC822 headers. This 295 attribute provides a list of the attributes considered optional 296 by VPIM and other vendor-specific attributes that may be 297 supported by the recipient. If this attribute is not supported, 298 only those attributes listed as mandatory in VPIM are assumed to 299 be supported. Undisclosed behaviors may be indicated in the 300 RFC822 message; however there is no assurance by the receiving 301 system of their support. 303 (IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors' 304 EQUALITY caseIgnoreIA5Match 305 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 307 The following behaviors are defined: 309 MessageDispositionNotification 310 MessageSensitivity 311 MessageImportance 313 The presence of the MessageDispositionNotification value 314 indicates that the recipient will send a MDN in response to an 315 MDN request. 317 MessageSensitivity indicates that the recipient fully supports 318 the sensitivity indication as defined in VPIM [VPIMV2]. 320 MessageImportance indicates that the recipient fully supports the 321 importance indication as defined in VPIM [VPIMV2]. 323 These may be further extended without standardization to include 324 proprietary user interface functional extensions. These 325 proprietary extension values must be prefixed with an "X-" or "x- 326 ". 328 2.9 vPIMMaxMessageSize 330 At the time of composition, the message can be checked for 331 acceptable length using the maximum message size attribute. 332 Maximum message size is an attribute usually configured by policy 333 of the receiving system, typically in units of minutes. While 334 ESMTP provides a mechanism to determine if a message is too long 335 in bytes, that is an unreliable guide to the composer when 336 multiple encodings, multiple media, or variable bit-rate 337 encodings are supported. 339 (IANA-ASSIGNED-OID.2.9 NAME 'vPIMMaxMessageSize' 340 EQUALITY integerMatch 341 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 342 SINGLE-VALUE ) 344 The attribute indicates the maximum message length in seconds the 345 recieving mailbox may receive. 347 2.10 vPIMSubMailboxes 349 This attribute indicates the presence of sub-mailboxes for the 350 queried telephone number. This information may be used to 351 provide a post-dial sub-addressing menu to the sender. 353 (IANA-ASSIGNED-OID.2.10 NAME 'vPIMSubMailboxes' 354 EQUALITY numericStringMatch 355 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} ) 357 The allowable values include a list of sub-mailbox numbers with a 358 numeric range of 1-9999. The user interface may use this 359 information to prompt the sender to select a sub-mailbox. Spoken 360 names associated with each sub-mailbox may be individually 361 retrieved by subsequent queries to the recipient's VPIMDIR 362 service. 364 3. Security Considerations 366 The following are known security issues. 368 1) Service provider customer information is very sensitive, 369 especially in this time of local phone competition. Service 370 providers require maximum flexibility to protect this data. 371 Because of the dense nature of telephone number assignments, this 372 data is subject to "go fish" queries via repeated LDAP queries to 373 determine a complete list of current or active messaging 374 subscribers. To reduce the value of this retrieved data, service 375 providers may limit disclosure of data useful for telemarketing 376 such as the textual name and disclose only information useful to 377 the sender such as the recipient�s spoken name, a data element 378 much harder to auto-process. 380 2) In many countries, privacy laws or regulations exist which 381 prohibit disclosure of certain kinds of descriptive information 382 (e.g., text names) Hence, servers implementors are encouraged to 383 support DIT structural rules and name forms [LDAPMODELS] as these 384 provide a mechanism for administrators to select appropriate 385 naming attributes for entries. Administrators are encouraged to 386 use these mechanisms, access controls, and other administrative 387 controls which may be available to restrict use of attributes 388 containing sensitive information in naming of entries. 390 3) The LDAP directory service needs to be secured properly for 391 this intended use. [LDAPAUTH] describes a number of 392 considerations that apply in this use. In particular, this 393 service provides unauthenticated, public access to directory 394 data, and as such is vunerable to attacks that redirect the query 395 to a rogue server and offer malicious data. 397 4. IANA Considerations 399 Reference RFC 3383 "Internet Assigned Numbers Authority (IANA) 400 Considerations for the Lightweight Directory Access Protocol 401 (LDAP)"[LDAPREG]. 403 4.1 Object Identifiers 405 It is requested that IANA register an LDAP Object Identifer for 406 use in this technical specification according to the following 407 template: 409 Subject: Request for LDAP OID Registration 411 Person & email address to contact for further information: 413 Greg Vaudreuil (gregv@ieee.org) 415 Specification: RFC XXXX 417 Author/Change Controller: IESG 419 Comments: 421 The assigned OID will be used as a base for identifying a number 422 of schema elements defined in this document. 424 4.2 Object Identifier Descriptors 426 It is requested that IANA register the LDAP Descriptors used in 427 this technical specification as detailed in the following 428 template: 430 Subject: Request for LDAP Descriptor Registration Update 432 Descriptor (short name): see comment 434 Object Identifier: see comment 436 Person & email address to contact for further information: 438 GregV@ieee.org 440 Usage: see comment 442 Specification: RFC XXXX 444 Author/Change Controller: IESG 446 Comments: 448 The following descriptors should be added: 450 NAME Type OID 451 -------------- ---- ------------ 452 vPIMUser O IANA-ASSIGNED-OID.1.1 453 vPIMRfc822Mailbox A IANA-ASSIGNED-OID.2.1 454 vPIMTelephoneNumber A IANA-ASSIGNED-OID.2.2 455 vPIMSpokenName A IANA-ASSIGNED-OID.2.3 456 vPIMSupportedUABehaviors A IANA-ASSIGNED-OID.2.4 457 vPIMSupportedAudioMediaTypes A IANA-ASSIGNED-OID.2.5 458 vPIMSupportedMessageContext A IANA-ASSIGNED-OID.2.6 459 vPIMTextName A IANA-ASSIGNED-OID.2.7 460 vPIMExtendedAbsenceStatus A IANA-ASSIGNED-OID.2.8 461 vPIMMaxMessageSize A IANA-ASSIGNED-OID.2.9 462 vPIMSubMailboxes A IANA-ASSIGNED-OID.2.10 464 Where Type A is Attribute, Type O is ObjectClass 466 5. References 468 5.1 Normative References 470 [LDAP] Hodges, J., Morgan, R., "Lightweight Directory Access 471 Protocol (v3): Technical Specification", RFC 3377, September 472 2004. 474 [32KADPCM] Greg Vaudreuil, Glenn Parsons, "Toll Quality Voice - 32 475 kbit/s ADPCM: MIME Sub-type Registration", RFC 3802, June 2004. 477 [CONTEXT] Eric Burger, Emily Candell, Graham Klyne, Charles 478 Eliott, "Message Context for Internet Mail", RFC 3458, January 479 2003 481 [E164] CCITT Recommendation E.164 (1991), Telephone Network and 482 ISDN Operation, Numbering, Routing and Mobile Service - 483 Numbering Plan for the ISDN Era. 485 5.2 Informative References 487 [VPIMV2] Vaudreuil, Greg, Parsons, Glenn, "Voice Profile for 488 Internet Mail, Version 2", RFC 3801, June 2004. 490 [LDAPREG] Zeilenga, K., "Internet Assigned Numbers Authority 491 (IANA) Considerations for the Lightweight Directory Access 492 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 494 [LDAPAUTH] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, 495 "Authentication Methods for LDAP", RFC 2829, May 2000. 497 [LDAPMODELS] Zeilenga, K., "LDAP: Directory Information Models" 498 Work-in-Progress (RFC Editors Queue), February 2005. 500 Acknowledgments 502 This directory schema builds upon the earlier work of Carl 503 Malamud and Marshall Rose in their TPC.INT remote printing 504 experiment and the work lead by Anne Brown as part of the EMA 505 voice messaging committee's directory effort. Anne Brown has 506 provided important leadership and was a co-author of the original 507 draft of this document. 509 Bernhard Elliot working with the TMIA has provided most of the 510 organizational impetus to get this project moving, a substantial 511 task given the sometimes slow and bureaucratic nature of the 512 voice mail industry and regulatory environment. 514 Thanks to Dave Dudley and the Messaging Alliance (TMA) for their 515 early work in pioneering a shared directory service for voice 516 messaging and their continuing efforts to apply that work to this 517 effort. 519 Greg White and Jeff Bouis, both of Lucent Technologies, provided 520 invaluable assistance in reviewing and sanity checking. 521 Countless errors and inconsistencies were corrected with their 522 diligent review. 524 Glenn Parsons has provided essential support over the many years 525 this document as been in development as chairman of the VPIM 526 working group. 528 6. Intellectual Property Notice 530 The IETF takes no position regarding the validity or scope of any 531 intellectual property or other rights that might be claimed to 532 pertain to the implementation or use of the technology described 533 in this document or the extent to which any license under such 534 rights might or might not be available; neither does it represent 535 that it has made any effort to identify any such rights. 536 Information on the IETF's procedures with respect to rights in 537 standards-track and standards-related documentation can be found 538 in BCP-11. Copies of claims of rights made available for 539 publication and any assurances of licenses to be made available, 540 or the result of an attempt made to obtain a general license or 541 permission for the use of such proprietary rights by implementors 542 or users of this specification can be obtained from the IETF 543 Secretariat. 545 The IETF invites any interested party to bring to its attention 546 any copyrights, patents or patent applications, or other 547 proprietary rights which may cover technology that may be 548 required to practice this standard. Please address the 549 information to the IETF Executive Director. 551 7. Copyright Notice 553 Copyright (C) The Internet Society (2005). This document is 554 subject to the rights, licenses and restrictions contained in BCP 555 78, and except as set forth therein, the authors retain all their 556 rights. 558 This document and the information contained herein are provided 559 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 560 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 561 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 562 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 563 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 564 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 565 FOR A PARTICULAR PURPOSE. 567 8. Authors� Address 569 Gregory M. Vaudreuil 570 Lucent Technologies 571 9489 Bartgis Ct 572 Frederick, MD 21702 573 Email: GregV@ieee.org