Skip to main content

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)
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state RFC 4237 (Proposed Standard)
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]