INTERNET DRAFT Anne Brown Category: Standards Track Nortel Date: November 11, 1998 E.164 Resolution Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This paper addresses global access to address information and additional subscriber and equipment information, given a telephone number as input. Table of Contents 1 Introduction 3 1.1 Problem Definition 3 1.2 Terminology 4 1.3 Definition Syntax 4 2 Proposed Solution 5 3 Functional Architecture 5 3.1 Functional Components 5 3.1.1 ITDSP Servers 6 3.1.2 Information Suppliers 6 3.1.3 Information Consumers 6 3.2 Interfaces 7 3.2.1 ITDSP/ITDSP Interface 7 3.2.2 ITDSP/Information Supplier Interface 7 3.2.3 ITDSP/Information Consumer Interface 7 4 Naming 8 4.1 DNS Domain Name 8 4.2 LDAP, X.500 Distinguished Name 8 4.3 Others 8 5 Scope 8 5.1 Representation of Telephone Numbers 8 5.2 Path Selection 8 5.3 Privacy 9 5.4 Lookups -vs- Searching 9 5.5 Application-Specific Schemas 9 5.6 "911" Service 9 5.7 Number Portability 9 5.8 User Configurability 9 6 Example 9 6.1 BigCo as Information Supplier 11 6.2 BigCo as Information Consumer 11 7 Schema 11 7.1 Sub-Tree Node Naming Attribute 12 7.2 Structural Object Class 12 7.3 Name Form 13 7.4 DIT Structure Rules 13 7.5 Summary of Syntax Definitions 14 7.5.1 ASN.1 Definitions 14 7.5.2 BNF Definitions 15 8 Requirements 15 8.1 Geo-Political Boundary Independence 15 8.2 Trusted, Third Party, Top-Level Service Providers 15 8.3 Numbering Plan Independence 16 8.4 Lookups -vs- Searching 16 8.5 Multiple ITDSPs 16 8.6 Distributed Entries 16 8.7 Transparency 16 8.8 Access Methods 17 8.9 Additional Subscriber Information 17 8.10Path Selection (gwloc) 17 8.11Time to Market 17 8.12Dynamic Information 17 8.13Redirection 18 8.14Number Portability 18 8.15User Configurability 18 8.16Quality of Service 18 8.17Capabilities Discovery 18 9 Relationship to Other Protocols and Initiatives 18 9.1 TPC.INT 18 9.2 Path Selection (gwloc) 19 9.3 TIPHON Service Mediation Environment 19 9.4 SIP 19 9.5 Naming Authority Pointer (NAPTR) 19 9.6 Wide Area Service Location 19 9.7 DIAMETER 19 9.8 Global Electronic Directory Assistance 20 9.9 Yellow Pages Directories and Search Engines 20 9.10Directory Enabled Networks (DEN) 20 9.11IN SCP and ss7/Internet gateways 20 9.12TIPHON's Internet Country Code 20 9.13Mail Recipient Capabilities (mailcap) 20 9.14Presence Information Protocol 20 9.15Numbering Plans 21 9.16Common Indexing Protocol 21 10 Commercial Aspects 21 11 Security Considerations 21 12 Acknowledgements 21 13 References 22 1 Introduction 1.1 Problem Definition There are many different scenarios of Internet Telephony communications possible on the Internet, including VoIP, voice messaging (VPIM), Internet fax, and videoconferencing. These applications may be initiated between one or more devices on the Internet (e.g., A and B in Figure 1), between one or more devices on the PSTN (C and D) with the Internet as an intermediary, between an Internet and a PSTN device or a combination of the above. +---------+ ------------ +---------+ | +-----+ | ___( ) | +-----+ | | | | |----------( )-----------| | | | | +-----| | ( TCP/IP ) | +-----| | +---------+ ( ) +---------+ +------------+ ( ) +------------+ | A | ------ ____) | B | +------------+ (_______) +------------+ | | +--------+ | GW | +--------+ | | ------------ ___( ) (-------) ( ) (-------) / \ ( PSTN ) / \ / \----------( )------------/ \ / C \ ( ) / D \ +--------+ ------ ____) +--------+ (_______) Figure 1: Internet Telephony Scenarios For some of these instances of communication, there is a requirement to be able to obtain information before an Internet Telephony interaction can be initiated. Such information might include: - Endpoint Address - address(es) of the intended correspondent(s) (e.g., domain name or IP address, voice, fax or text messaging SMTP address, etc.) - Path Address- endpoint address(es) of gateways, gatekeepers or other equipment that can be used to route the session to the intended recipient. - Additional Subscriber Information - including supported capabilities, preferences, authentication, authorization, etc. It may also include information about equipment, such as a fax machine, that is shared by a group of subscribers. - Server Address - address(es) of servers, such as LDAP directories, SIP servers, gatekeepers, authentication servers, etc., that may be used to obtain some or all of the above information. Along with the ability to be able to retrieve this information, there are a number of additional related requirements, including qualification of the query using additional input information, multiple responses (e.g., return all addresses that apply), security (including mutual authentication, non-repudiation, privacy and integrity) and business grade requirements (including 99.9999% 24/7 availability, updates available within 5 to 15 seconds, and 50 to 100 ms query response times) And fundamental to the provision of Internet Telephony information is some back-end mechanism(s) for storing, maintaining, and distributing this information. Some of the requirements for this backbone infrastructure may include replication and distribution, maintenance, security and business grade requirements such as updates available within 5 to 15 seconds, and billions of entries) 1.2 Terminology CIP Common Indexing Protocol DAP Directory Access Protocol DISP Directory Information Shadowing Protocol DIT Directory Information Tree GW Gateway ITDSP Internet Telephony Directory Service Provider LDAP Light-Weight Directory Access Protocol NAPTR Naming Authority PoinTeR RR Resource Record VPIM Voice Profile for Internet Mail "Must" or "Shall" - Software that does not behave in the manner that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. 1.3 Definition Syntax Attribute type and object class definitions for use with X.500 are written using Abstract Syntax Notation One [ASN.1]. Equivalent attribute type and object class definitions for use with LDAP are written using the BNF form of AttributeTypeDescription and ObjectClassDescription given in [LDAPATTRIB]. Lines have been folded for readability. 2 Proposed Solution A number of solutions, claiming to meet some or all of the above requirements, have been discussed in various forums. These solutions have ranged from using existing, severely limiting mechanisms, to elaborate new schemes that cannot be reasonably implemented and deployed in the near future. The solution proposed in this paper addresses the problem of global access to address information and additional subscriber and equipment information, given a telephone number as input. Retrieval of path address is outside the scope of this paper. The directory structure provides clients with the ability to access directory information, given only a telephone number. The directory is structured according to the E.164 numbering plan, with each node in the tree representing a single digit of an E.164 telephone number. Given a telephone number, an LDAP or DNS query can pinpoint an entry in the global tree. This structure allows Information Consumers to retrieve information without having to perform a global search for a telephone number and without having to understand different numbering plan structures. It can be implemented immediately at the enterprise, carrier and ISP level, followed by a worldwide service with the help of third party, trusted, top-level service providers. Other numbering plans besides E.164, and other alphanumeric identity structures, such as calling cards and user IDs, can also be supported by similar tree structures . 3 Functional Architecture 3.1 Functional Components The solution proposes three functional components. Global E.164 Resolution Service +------------+ | | +------------+ | | | | | ITDSP(s) |--+ / | | \ Single Queries (LDAP, Replication (X.500 or LDAP), / +------------+ \ DAP, DNS, http, [H.323 DNS Zone Transfer, CIP / \ RAS]) or Bulk Transfer Proprietary Mechanisms / \(Replication, DNS, CIP / \Proprietary) +-----------------------+ +-----------------------+ | | | | +-----------------------+ | +-----------------------+ | | | | | | | | Information Suppliers |--+ | InformationConsumers |--+ | | | | +-----------------------+ +-----------------------+ ISPs, Carriers, Enterprises and other service providers Figure 2: Functional Components 3.1.1 ITDSP Servers Internet Telephony Directory Service Providers (ITDSPs) are trusted, third-party top-level service providers who will list information on mapping from a telephony number to an endpoint address and/or address(es) of servers that contain endpoint address and additional subscriber and device information. This information will be mainly collected from carriers, ISPs, enterprises and other entities based on commercial service level agreements. ITDSPs will make this information available to querying clients. ITDSPs will probably initially correspond to geo-political boundaries but the underlying architecture does not preclude this. ITDSPs will not necessarily be the same authorities that arbitrate the assignment and allocation of telephone or other numbers. They are intended to simply provide listing and mapping services. ITDSPs will operate X.500-based directory servers supporting access via X.500 DAP, LDAP, DNS, and http. When LDAP server-to- server protocols have evolved, ITDSPs may also operate LDAP servers. 3.1.2 Information Suppliers Mapping information will be supplied to ITDSPs from carriers, ISPs, enterprises and other entities. Mapping information supplied to ITDSPs must be relatively static. If subscriber information is dynamic in nature, then mapping information may comprise only pointers to private servers that are closer to the subscriber and which are not part of the top level ITDSP infrastructure. If a subscriber has a dynamic E.164 number, they should also have a more persistent E.164 number for storage in an ITDSP. The persistent E.164 number can be mapped to one or more dynamic E.164 numbers on private servers. 3.1.3 Information Consumers Clients such as LDAP, DAP, DNS resolvers and browsers will be able to query the global E.164 directory service for information. H.323 RAS queries are outside the scope of this document. Access should be free and unauthenticated. However, authenticated access may be enforced, based on the requirements of information suppliers, who in turn represent the requirements of the subscribers on whose behalf the listings have been supplied to the ITDSP. Subscribers may also gain access to mapping information indirectly via their Internet telephony service provider. This access may be through queries to the Internet telephony service provider which are in turn chained or referred to an ITDSP. Alternately, Internet telephony service providers may arrange to hold local replicas of ITDSP mapping information. 3.2 Interfaces This section discusses the interfaces between the functional components. 3.2.1 ITDSP/ITDSP Interface Depending on service level agreements, ITDSPs will distribute and/or share (replicate) information using X.500 1993 protocols or other mechanisms. Queries MUST be transparently supported between ITDSPs such that a particular query will result in the same answer, no matter which ITDSP you ask. There is a requirement to support the ability for more than one Information Supplier to be able to provide information for the same telephone number. This capability will be supported when standardization work on distributed entries and multi-master replication is completed for X.500 and LDAP. 3.2.2 ITDSP/Information Supplier Interface Carriers, ISPs, enterprises and other entities will supply information to ITDSPs, based on commercial service agreements. Updates may be based on the following mechanisms: - X.500 replication - LDAP replication (slapd, ldif, changelog, etc.) - DNS zone transfer - Common Indexing Protocol (CIP) - Proprietary means 3.2.3 ITDSP/Information Consumer Interface Information consumers may be clients, including LDAPv3 and X.500 93 clients, DNS resolvers, and http browsers. H.323 RAS queries are outside the scope of this document. Where privacy is not an issue, ITDSPs SHOULD accept unauthenticated, zero-rated queries from Information Consumers. Information consumers may also be Internet telephony service providers who have arranged with their ITDSP to store local replicas of ITDSP mapping information. These replicas may be transferred via the following means: - X.500 replication - LDAP replication (slapd, ldif, changelog, etc.) - DNS zone transfer - Common Indexing Protocol - Proprietary means 4 Naming Queries to ITDSPs will be based on keys that will pinpoint entries in an ITDSP service. Initially, X.500/LDAP distinguished names and DNS domain names will be supported in queries. 4.1 DNS Domain Name DNS queries MUST include a top level domain name of "e164", followed by the full E.164 telephone number listed backwards with each digit separated by dots. For example, a DNS lookup for an NAPTR RR [NAPTR] on +1 613 123 4567 would require the following domain name in the query: 7.6.5.4.3.2.1.3.1.6.1.0.0.e164 4.2 LDAP, X.500 Distinguished Name LDAP and X.500 queries MUST include a distinguished name beginning with the relative distinguished name of "e164", followed by distinguished names consisting of each digit of the E.164 telephone number. For example, an LDAP or X.500 query for information on +1 613 123 4567 would require the following distinguished name in the query: o=e164, ed=0, ed=0, ed=1, ed=6, ed=1, ed=3, ed=1, ed=2,ed=3,\ ed=4, ed=5, ed=6, ed=7 where "o" is organizationName and "ed" is e164Digit. 4.3 Others Other name forms are outside the scope. 5 Scope This section specifies some items that are outside the scope of this document. 5.1 Representation of Telephone Numbers How a user enters a telephone number is between the user and the Information Supplier representing that user. The global E.164 service only responds to queries for fully canonical E.164 numbers. 5.2 Path Selection Path selection and call routing are outside the scope. Path selection requires more than a simple DNS, LDAP, or simple database query because some service logic must be executed to decide the appropriate gateway based on such results as the caller and caller preferences, points of presence and capabilities. Additionally, path selection is highly dynamic considering resource depletion and other metrics. Allowing SIP, H.323/RAS and other URLs to be stored and retrieved supports the existence of other protocols such as SIP, H.323/RAS and gwloc for path selection. 5.3 Privacy Privacy, and especially non-listing of a number, is between a user and their Information Supplier. ITDSPs MUST, however, support the access controls set by Information Suppliers in the information they list with ITDSPs. 5.4 Lookups -vs- Searching ITDSPs will provide lookups given an E.164 number. The structure allows a client to pinpoint an entry in the global ITDSP structural hierarchy, thus eliminating the requirement for global searching based on partial information. Searches based on partial information may be able to provided at some point in the future but are beyond the scope of this paper. 5.5 Application-Specific Schemas A general schema is defined in this document to describe how the global E.164 directory is to be structured. In order for an application to know which information to retrieve, given an E.164 number, an application-specific schema must be defined. For example, a draft schema has been defined for use in a voice messaging (VPIM) pilot. Application-specific schemas should be defined in the standards or industry forum that are responsible for those applications and are outside the scope of this paper. 5.6 "911" Service This architecture does not support the emergency "911" service. 5.7 Number Portability Currently number portability is provided locally by regulated authorities. Local and global number portability is outside the scope of this paper. However the architecture MUST be capable of storing and providing access to number portability listings from trusted third parties, if required in the future. 5.8 User Configurability User configurability is outside the scope of this paper, however, it should be facilitated by the architecture. LDAP, X.500 DAP and http support user configurability. However, it is envisioned that this will take place closer to the user. 6 Example Consider a scenario whereby an enterprise, BigCo, has arranged to provide listing information, on behalf of its employees, to an ITDSP. Suppose also that most of BigCo's employees have telephone numbers prefixed with: +1 613 76X XXXX BigCo also has additional employee numbers scattered throughout the E.164 numbering plan: +44 12 55 63 +1 709 123 4567 … The integrated BigCo directory tree will contain a white pages (WP) directory sub-tree, and an E.164 sub-tree, and possibly a sub-tree structured according to BigCo's private numbering plan. These entries may be linked together via aliases whereby there are entries in the WP sub-tree holding employee information and alias entries in the other sub-trees pointing back to WP entries. Alternately, BigCo may store its employees profiles in database tables that can be accessed via LDAP, DAP, or DNS. Regardless of how a company structures its data, it must have some mechanism to allow outside queries to be able to logically point to the data using the naming described in section 4. root | /-----------------------------------------------\ o=BigCo o=e164 | | ------------+------------------------------ | | | | ed=0 cn=John Smith cn=Joe Bloggs cn=… ou=BigCo Priv Numbering Plan | | ------------- … | | ed=0 ed=4 | | ed=1 ed=4 | | ------------- ed=1 | | | ed=6 ed=7 ed=2 | | | ed=1 ed=0 ed=5 | | | ed=3 ed=9 ed=5 | | | ed=7 ed=1 ed=6 | | | ed=6 ed=2 ed=3 | / | DN= o=BigCo, ou=BigCo Priv Numbering Plan <--- ed=3 | (Pointer to private numbering plan sub-tree) / | ed=4 | / | ed=5 | / | ed=6 | / | ed=7 | / | DN= o=BigCo, cn=John Smith <--- DN= o=BigCo, cn=Joe Bloggs <- (Pointer to WP entry) (Pointer to WP entry) o: organizationName ou: organizationalUnitName cn: commonName ed: e164Digit DN: Distinguished Name Figure 3: Example: BigCo's Private Directory Tree Structure 6.1 BigCo as Information Supplier If BigCo wishes to control access to its employees' Internet telephony information, it will only supply mapping information consisting of the IP addresses of its own principal directory servers. If BigCo maintains two directory servers for public queries, say at host names directory1.bigco.ca and directory2.bigco.ca, it may provide the following information to an ITDSP: E.164 Number Mapping Information +1 613 76 Subordinate Refs=directory1.bigco.ca, directory2.bigco.ca +44 12 55 63 Subordinate Refs=directory1.bigco.ca, directory2.bigco.ca +1 709 123 4567 Subordinate Refs=directory1.bigco.ca, directory2.bigco.ca … Subordinate Refs=directory1.bigco.ca, directory2.bigco.ca Anyone querying an ITDSP for Internet telephony mapping information on BigCo employees would get chained or referred to BigCo servers. 6.2 BigCo as Information Consumer BigCo provides access for its subscribers to ITDSP mapping information indirectly by chaining from its own corporate directory servers to the ITDSP servers closest to its own servers. This way subscribers need only discover the location of a local BigCo directory server in order to initiate a query for global information. 7 Schema This section defines an X.500/LDAP object class and attribute for use in a global E.164 resolution directory service. Also defined are X.500 name forms and DIT structure rules. In order for an application to know which information to retrieve, given an E.164 number, additional schemas must be defined for each application . For example, a draft schema has been defined for use in a voice messaging (VPIM) pilot. Application-specific schemas should be defined in the standards or industry forum that is responsible for that application. 7.1 Sub-Tree Node Naming Attribute The E.164 directory is structured in a hierarchy whereby each node in the tree represents a single digit of an E.164 telephone number. The higher in the tree a digit is, the higher its significance in the tree. Since a single digit names the nodes in the tree, the e164Digit attribute shall have a length of one digit. e164Digit will be abbreviated to ed for this document. Some examples of Distinguished Name composed from e164Digits are: A telephone number of +1 613 765 1234 would have the following corresponding Distinguished Name in the E.164 directory: ed=4, ed=3, ed=2, ed=1, ed=5, ed=6, ed=7, ed=3, ed=1, ed=6, ed=1, ed=0,\ ed=0, o=e164 Telephone number +1 613 765 1234 with extension 555 would result in the following Distinguished Name: ed=5, ed=5, ed=5, ed=4, ed=3, ed=2, ed=1, ed=5, ed=6, ed=7, ed=3,\ ed=1, ed=6, ed=1, ed=0, ed=0, o=e164 The ASN.1 definition of e164Digit for X.500 implementations is: e164Digit ATTRIBUTE ::= { WITH SYNTAX NumericString (SIZE(ub-vpim-at-e164Digit)) EQUALITY MATCHING RULE %numericStringMatch ID id-vpim-at-e164Digit} ub-vpim-at-e164Digit INTEGER ::= 1 The BNF definition of e164Digit for use with LDAP is: (2.16.840.1.113694 .1.2 .1 .1 .1 NAME 'e164Digit' EQUALITY %2.5.13.8 SYNTAX %'1 .3.6 .1.4.1.1466.115 .121.1.36 {1}') 7.2 Structural Object Class Structural object classes are used in defining the hierarchical structure of the directory tree. e164Node is the structural object class that will be used in defining the structure of the directory tree. All entries of this type must contain the e164Digit attribute that is used to name entries in the E.164 directory tree. The ASN.1 definition for X.500 implementations is: e164Node OBJECT-CLASS ::= { SUBCLASS OF %top MUST CONTAIN { e164Digit } ID %{ id-vpim-oc-e164node} } The BNF definition for use with LDAP is: (2.16.840.1 .113694.1.2.1.2.1 NAME 'e164Node' SUP top STRUCTURAL %MUST e164Digit) 7.3 Name Form Name forms control how entries are named in the directory tree. They are referenced in the DIT structure rules that are used to define which classes of object may be subordinate to other classes of object in the directory. Object classes of the e164DigitNameForm name form are named using the e164Digit attribute type. e164DigitNameForm %NAME-FORM ::= { NAMES e164Node WITH ATTRIBUTES { e164Digit } ID id-vpim-nf-e164Digitnameform } 7.4 DIT Structure Rules The directory is structured according to the rules illustrated in Figure 4. Structure rule 1 defines entries, that are named according to the orgNameForm (i.e., named with attribute organizationName), to be immediately subordinate to the root of the DIT. Sr1 STRUCTURE-RULE ::= { NAME FORM orgNameForm, -- X.521 ID %1 } root / 1/ / / / / / organziationName \ \2 \ e164Digit / | 3\ / -- Figure 4: DIT Structure Rules Structure rule 2 specifies e164Digit entries placed under organizational entries. Sr2 STRUCTURE-RULE ::= { NAME FORM e164DigitNameform, SUPERIOR RULES { sr1}, ID 2 } Structure rule 3 defines e164Digit entries subordinate to e164Digit entries. Sr3 STRUCTURE-RULE ::= { NAME FORM e164DigitNameform, SUPERIOR RULES { sr2 }, ID 3 } 7.5 Summary of Syntax Definitions 7.5.1 ASN.1 Definitions -- attributes e164Digit ATTRIBUTE ::= { WITH SYNTAX %NumericString (SIZE(ub-vpim-at-e164Digit)) EQUALITY MATCHING RULE numericStringMatch ID %id-vpim-at-e164Digit} -- object classes e164Node OBJECT-CLASS ::= { SUBCLASS OF %top MUST CONTAIN %{ e164Digit } ID %{ id-vpim-oc-e164node} } -- Name Forms e164DigitNameForm %NAME-FORM ::= { NAMES e164Node WITH ATTRIBUTES { e164Digit } ID id-vpim-nf-e164Digitnameform } -- structure rules Sr1 STRUCTURE-RULE ::= { NAME FORM orgNameForm, -- X.521 ID %1 } Sr2 STRUCTURE-RULE ::= { NAME FORM e164DigitNameform, SUPERIOR RULES { sr1}, ID 2 } Sr3 STRUCTURE-RULE ::= { NAME FORM e164DigitNameform, SUPERIOR RULES { sr2 }, ID 3 } -- upper bounds ub-vpim-at-e164Digit %INTEGER ::= 1 -- object identifiers id-vpim OBJECT IDENTIFIER ::= {2.16.840.1.113694.1.2.1} id-vpim-at OBJECT IDENTIFIER ::= {id-vpim 1} id-vpim-at-e164Digit OBJECT IDENTIFIER ::= {id-vpim-at 1} id-vpim-oc OBJECT IDENTIFIER ::= {id-vpim 2} id-vpim-oc-vMNode OBJECT IDENTIFIER ::= {id-vpim-oc 1} id-vpim-nf OBJECT IDENTIFIER ::= {id-vpim 3} id-vpim-nf-e164Digitnameform OBJECT IDENTIFIER ::= { id-vpim-nf 1} 7.5.2 BNF Definitions (2.16 .840 .1.113694.1 .2 .1.1.1 NAME 'e164Digit' EQUALITY %2 .5.13 .8 SYNTAX '1.3.6 .1.4 .1.1466.115.121.1.36 {1}') (2.16 .840 .1.113694.1 .2 .1.2.1 NAME 'e164Node' SUP top STRUCTURAL %MUST e164Digit) 8 Requirements This section discusses the requirements of a global solution for addressing the problem of providing access to server and endpoint information, given a telephone number. 8.1 Geo-Political Boundary Independence Several solutions have been proposed that use a distributed telephone number hierarchy, such as TPC.INT [TPC.INT], for information retrieval. Some have suggested distributing this hierarchy into countries and other sub-components related to the structure of a telephone number. This type of delegation is not suitable because it uses the assumptions of existing infrastructures and could seriously impede new types of scenarios. In the future, authorities and services (e.g., local and global number portability, etc.) may span geo-political boundaries. The E.164 resolution hierarchy described in this document is similar to TPC.INT, whereby a logical tree is patterned after the structure of the E.164 telephone numbering plan. However, instead of breaking the tree into components of the E.164 plan (e.g. country code, etc.), it uses each digit of an E.164 number for a node in the tree. The tree can be logically shared and/or distributed between ITDSPs and does not mandate distribution on a geo-political basis. 8.2 Trusted, Third Party, Top-Level Service Providers The requirement for geo-political boundary independence implies a requirement for the existence of trusted, third party, top- level service providers. ITDSPs will probably initially correspond to geo-political boundaries, but the underlying architecture MUST not preclude this. ITDSPs will not necessarily be the same authorities that arbitrate the assignment and allocation of telephone or other numbers. They are intended to simply provide listing and mapping services. 8.3 Numbering Plan Independence Telephone numbers used to retrieve information on a subscriber may be obtained from business cards, directory assistance or other means. Therefore the client may not have knowledge of how the telephone number is structured. Clients accessing an ITDSP MUST not require any knowledge as to the structure or length of national numbering plans. 8.4 Lookups -vs- Searching ITDSPs will provide lookups given an E.164 number. The structure allows a client to pinpoint an entry in the global ITDSP structural hierarchy, thus eliminating the requirement for global searching based on partial information. Searches based on partial information may be able to provided at some point in the future but it is beyond the scope of this paper. 8.5 Multiple ITDSPs ITDSPs MUST be able to access each other's information such that no matter which ITDSP is queried, the same response is be received. 8.6 Distributed Entries There is a requirement to support the ability for more than one Information Supplier to be able to provide information for the same telephone number. Given the appropriate security credentials of the requestor, a request to a single ITDSP for information on a particular subscriber MUST result in a response containing all listings for that subscriber, even if some of the master listings are held by other ITDSPs. Initially, there will be a small number of ITDSPs available. Their implementations MUST support the ability to handle distributed attributes. This will initially be done using proprietary synchronization mechanisms. The existence of a standard for handling distributed entries is essential to the handling of billions of distributed entries on a global basis. X.500 work is currently being evolved to handle multi-master replication and the existence of distributed attributes to support multiple service providers for the same real-world object. This ITU-T, SG7 WP4, Q.15 work, which is scheduled for approval in June 1999, will be done in collaboration with the IETF for use by LDAP as well. There must be some accountability for the provision of false information. Updates must be authenticated. As well, placing a price on listings may discourage phony listings. How to guarantee that mappings are authorative is for further study. 8.7 Transparency The proposed solution MUST allow for the retrieval of endpoint and server address information without previously knowing where that information is stored. X.500, LDAP and DNS use referrals to support this. As well, ITDSPs SHOULD be able to respond to queries for information held by other ITDSPs as if they themselves held the information. X.500 supports chaining, which allows the client to make only one query and also isolates the client from the underlying distribution of ITDSP servers. 8.8 Access Methods Clients MUST be able to access ITDSP information using a standard access protocol. ITDSPs MUST allow access using X.500 DAP, LDAP, DNS, and http. LDAP allows for more complex and sizeable queries and results. DNS, on the other hand, allows for simpler access and is easier to implement in client devices. The existence of http access to clients facilitates end-user configurability. With LDAP and X.500 DAP, clients may receive different answers based on security credentials and query parameters. 8.9 Additional Subscriber Information ITDSPs MUST be capable of providing access to additional subscriber information. If LDAP or DAP is used by the client, it does not need to switch to another protocol to access this additional subscriber information. In fact, endpoint, server and subscriber information can be accessed via chaining using one query. 8.10 Path Selection (gwloc) Path selection requires more than a simple DNS, LDAP, or simple database query. However, the architecture supports the existence of other protocols such as SIP [SIP], H.323/RAS and gwloc [GWLOC] for path selection, by allowing SIP, H.323/RAS and other URLs to be stored and retrieved. 8.11 Time to Market All that is required for this solution to be deployed is for one or more service providers to start up a service. VPIM vendors have already trialed such a service and several organization have plans to implement a commercial service. Existing clients can be used to request information, however, applications must support these existing access protocols. 8.12 Dynamic Information If a subscriber's mapping information is dynamic, it should be stored on a server closer to the user and the ITDSP should only store the server address. If a subscriber employs dynamic E.164 numbers, they should also have a more persistent E.164 number for storage in an ITDSP. The persistent E.164 number can be mapped to one or more dynamic E.164 numbers on another server. 8.13 Redirection The service MUST be capable of redirecting the E.164 number to another number, which may belong to another subscriber who may have different capabilities and preferences. Supplying a different E.164 address for the endpoint address can provide redirection. Additionally, redirection can be actioned at a private server closer to the user, in which case, the ITDSP should only list the server address for the subscriber. 8.14 Number Portability Currently number portability is provided locally by regulated authorities. Local and global number portability is outside the scope of this paper. However the architecture MUST be capable of storing and providing access to number portability listings from trusted third parties, if required in the future. 8.15 User Configurability User configurability is outside the scope of this paper, however, it should be facilitated by the architecture. LDAP, X.500 DAP and http support user configurability. However, it is envisioned that this will take place closer to the user. 8.16 Quality of Service Quality of service for ITDSP query requests is outside the scope of this paper, however the solution should be able to support it in the future. X.500 standards are evolving to support the request of a particular level of QoS. This work will be liaised to ITEF for possible adoption by LDAP. 8.17 Capabilities Discovery The solution MUST be able to point to servers storing user capabilities. Other groups are handling work on capabilities discovery and negotiation. 9 Relationship to Other Protocols and Initiatives 9.1 TPC.INT TPC.INT [TPC.INT] distributes the E.164 numbering plan hierarchy into countries and other sub-components related to the structure of a telephone number. The TPC.INT idea of a logical telephone number hierarchy was used as a basis for the structure of the E.164 directory tree in this document. However, the geo- political delegation used in TPC.INT was not suitable for the E.164 global tree because it uses the assumptions of existing infrastructures and could seriously impede new types of scenarios. Instead of breaking the tree into components of the E.164 plan (e.g. country code, etc.), the E.164 hierarchy uses each digit of an E.164 number for a node in the tree. This tree can be more easily shared and/or distributed between ITDSPs and does not mandate distribution on a geo-political basis. It also does not require the Information Consumer to have prior knowledge of numbering plan structures and lengths. 9.2 Path Selection (gwloc) Path selection requires more than a simple DNS, LDAP, or simple database query because some service logic must be executed to decide the appropriate gateway based on such results as the caller and caller preferences, points of presence and capabilities. Additionally, path selection is highly dynamic considering resource depletion and other metrics. Allowing SIP, H.323/RAS and other URLs to be stored and retrieved supports the existence of other protocols such as SIP, H.323/RAS and gwloc for path selection. 9.3 TIPHON Service Mediation Environment The ITDSP architecture compliments TIPHON's Service Mediation Environment work by providing a needed E.164 resolution mechanism. How these can work together is for further study. 9.4 SIP SIP [SIP] also provides for multistage address resolution suitable for the enterprise level. This solution compliments SIP by providing a global backbone that can point to SIP servers that are closer to users. E.164 to SIP URL mapping information can be listed by Information Suppliers. 9.5 Naming Authority Pointer (NAPTR) Faltstrom's draft introduces use of NAPTR RRs [NAPTR] to, among other things, support portable numbers and to enable a level of indirection between mapping information and the owner of an E.164 number. The existence of ITDSPs compliments Faltstrom's approach by providing a top-level service that responds to NAPTR queries on the E.164 top level domain. The ITDSPs, as well as Faltstrom's solution, can provide pointers to where more structured information can be stored. 9.6 Wide Area Service Location The relationship of this architecture to wide area service location (wasrv) is for further study. It will become clearer once the work on wasrv advances. It is envisioned that the proposed solution will be one of the services advertised by SLP [SLP]. 9.7 DIAMETER Mapping information may point to directories that store information on subscriber policies. Alternately, mapping information could point to DIAMETER [DIAM] authentication servers serving a particular E.164 number. 9.8 Global Electronic Directory Assistance ITU-T Rec. F.510 [F510] describes a global electronic directory assistance standard. X.500 is currently being enhanced to support F.510 and the work is expected to be approved June 1999. Once this work is completed, it may compliment the services provided by ITDSPs by allowing clients to access information without first knowing a subscriber's E.164 number. 9.9 Yellow Pages Directories and Search Engines Existing yellow pages-type directories and search engines will compliment the ITDSP service by allowing users to obtain information without first knowing a subscriber's E.164 number. 9.10 Directory Enabled Networks (DEN) ITDSPs can store pointers to subscriber policy information. Once DEN evolves, it may be possible to retrieve information on application and network policy information relevant to a particular telephone number and subscriber. 9.11 IN SCP and ss7/Internet gateways IN CS-1R, CS-2 and CS-3 define an X.500 interface for use between the SDF/SDF and SDF/SDF functional units. Additionally, DNS, LDAP and other protocols may be able to be used to access the ITDSP from an SCP. The relationship between ITDSPs and SCPs, and between ITDSPs and ss7/Internet gateways, is beyond the scope of this paper. 9.12 TIPHON's Internet Country Code ETSI's TIPHON is in the process of trying to register an Internet country code to facilitate non-geopolitically-based, flat allocation of telephone numbers for use over the Internet. ITDSPs will support access to E.164 numbers assigned with an Internet country code. 9.13 Mail Recipient Capabilities (mailcap) Work on store and forward capabilities discovery, and possibly session-based capabilities discovery is currently being studied in other groups. Once this work evolves, ITDSPs may point to information on user capabilities. 9.14 Presence Information Protocol Presence information protocols could be used to populate databases used by Information Suppliers to provide information to ITDSPs, however, such interaction would be outside the scope of this document. It is also possible that ITDSPs could point to servers containing presence information. 9.15 Numbering Plans The architecture both recognizes and supports the different numbering plans that exist today. The relationship between ITDSPs and the numbering plan administrations in the different countries is for further study. 9.16 Common Indexing Protocol Common Indexing Protocol (CIP) [CIP], facilitates searching between directory servers and could be used to distribute queries between ITDSPs. 10 Commercial Aspects It is envisioned that information will be supplied to ITDSPs by other entities, based on service level agreements. Sharing and/or distribution of information between ITDSPs will also be based on service level agreements. The ideal scenario would be authenticated, fee based listing services, along with free, unauthenticated single query access to the information. Local storage of replicas of ITDSP mapping information should be fee- based as well. 11 Security Considerations Privacy, and especially non-listing of a number, is between a user and their Information Supplier. ITDSPs MUST, however, support the access controls set by Information Suppliers in the information they list with ITDSPs. For the directory service, access control should be such that anonymous reads are allowed for all non-private attributes. The directory was designed for single X.500 read operations (base object searches in LDAP). Multiple multilevel searches may degrade performance and should be discouraged. To prohibit access to entries without explicitly providing the name of an entry, denyBrowse should enforced for anonymous users. There must be some accountability for the provision of false information. Updates must be authenticated. As well, placing a price on listings may discourage phony listings. How to guarantee that mappings are authorative is for further study. 12 Acknowledgements Input from Mark Wahl, Mike Sutter, Richard Shockey and discussions on the iptel list, greatly contributed to the information contained in this report. 13 References This section to be completed. [TPC.INT] [SIP] [GWLOC] [CIP] [X500] [LDAP] [NAPTR] RFC 2168: Daniel, R., Mealling, M., "Resolution of Uniform Resource Identifiers using the Domain Name System", June 1997. [SLP] [DIAM] [F510]