Internet Draft R. Stastny Document: draft-stastny-enum-scenarios-00.txt OeFEG Category: Informational Expires: December 2002 June 2002 Scenarios for ENUM and ENUM-like Systems Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1}. 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 "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document analyzes scenarios for ENUM and ENUM-like Systems, both for ENUM used by End Users and also for ENUM-like Systems used by operators for network-specific or infrastructure purposes. It also gives some examples of ENUM Usage and proposes a new URI scheme to be used with ENUM. This may allow a way forward for the definition of ENUM Services and also for the definition of the required URIs and their parameters. This document therefore deals with information stored in the ENUM and the look-up process and the usage of the information retived in this look up process. It does not deal with the administrative process related to the population of the relevant zones. Stastny Expires - December 2002 [Page 1] Scenarios for ENUM and ENUM-like Systems June 2002 Table of Contents 1. Background.....................................................2 2. ENUM and ENUM-like Systems.....................................3 2.1 User-ENUM and User-ENUM-like Systems..........................3 2.2 ENUM-like Systems for Infrastructure Purposes.................3 3. Abbreviations..................................................4 4. Number ranges to be used in ENUM...............................5 4.1 Geographic, mobile and personal numbers.......................5 4.2 ENUM Tier 3 and extensions (DDI)..............................5 4.3 Service numbers in ENUM.......................................6 5. Scenarios for User ENUM and ENUM-like Systems..................7 5.1 IP-enabled terminal to IP-enabled terminal....................8 5.2 IP-enabled terminal to the GSTN...............................8 5.3 From the GSTN to IP-enabled terminals or to the GSTN..........9 6. Scenarios for Infrastructure ENUM.............................10 6.1 Support of NP services.......................................11 6.2 Support for number translation services......................12 6.3 Support for routing to IP-based PoIs.........................13 6.4 Requirements for Infrastructure ENUM.........................14 7. Examples of Usage and Additional Requirements.................14 7.1 ENUM Client Applications.....................................15 7.2 New URI Scheme enum:.........................................16 7.3 Resource Records to be used in ENUM..........................17 8. Security Considerations.......................................17 9. Acknowlegdements..............................................17 10. References...................................................18 11. Author's Address.............................................18 1. Background The ENUM System as defined in Draft RFC2916bis [2] discusses the use of the DNS for identifying available services connected to an E.164 number. Through the transformation of E.164 numbers into DNS names and the use of existing DNS services, especially the NAPTR records as defined in [3], one can look up what services are available for the related E.164 number. The ENUM System as defined in Draft RFC2916bis deals only with the domain "e164.arpa". This also implies that only full E.164 numbers may be used. To clarify, only this system is called "ENUM", all other systems are called ENUM-like Systems within this document. Stastny Expires - December 2002 [Page 2] Scenarios for ENUM and ENUM-like Systems June 2002 2. ENUM and ENUM-like Systems 2.1 User-ENUM and User-ENUM-like Systems In section 1.2 of Draft RFC2916bis it is suggested, that a similar mechanism can be used for private dialing (and/or numbering) plans in a different domain, well-known for all parties using the same plan and the AUS is to be a number without the leading '+'. This is one example of an "ENUM-like" System. In addition, the following scenario may exist for a User-ENUM-like System: The usage of DNS in an alternate root in an Intranet is called in this document "Private-DNS ENUM-like system". Private-DNS ENUM may be used within a company for private dialing plans as mentioned above. In this case the AUS is a number without the leading '+'. In the case of ENUM and the above mentioned scenarios for ENUM-like Systems the ENUM End User has the right to opt-in into the ENUM or ENUM-like system and the ENUM End User is also responsible for provisioning the NAPTR records (although within companies a different policy may apply). It is also the originating user (or a proxy -e.g. a gateway- on behalf of the originating user, if the terminal of the calling user is not capable of accessing the DNS) who is retrieving and evaluating the NAPTR records prior or during establishing the communication. These systems are therefore called "User ENUM" or "User ENUM-like" Systems within this document. 2.2 ENUM-like Systems for Infrastructure Purposes All systems for infrastructure purposes are ENUM-like Systems. The following scenarios may exist with for infrastructure purposes (Infrastructure ENUM): a) An operator may use a DNS in an Intranet for his own network- specific purposes e.g. for routing, number portability (NP), freephone (+800) or other IN-like services. These are also variants of "Private DNS ENUM-like Systems". b) A (con)-federation of operators may decide to set up an ENUM-like domain for network-specific purposes (federation infrastructure ENUM- like system) either in an extranet (which is also considered "private DNS") or in a "public" DNS domain different from "e164.arpa", but well-known to the (con)-federation. Stastny Expires - December 2002 [Page 3] Scenarios for ENUM and ENUM-like Systems June 2002 c) For global services and global usage, a second "golden tree" different from "e164.arpa" (e.g. "e164infra.arpa"" may be set up for network-specific purposes, holding only infrastructure information not related to the user (global infrastructure ENUM-like System). The domain name holder for the domain related to the E.164 Number is in all? (most?) of these cases the operator hosting the E.164 number. The reason for this is the opt-in principle adopted for User-ENUM. Since not all users will opt-into ENUM, not all numbers required by the operator for his service will be available in User-ENUM. The user will also select his ENUM Tier 2 Name Servers, and the operator may have no access-right to this Name Servers, so he has to provision the infrastructure data in other Name Servers of his choice. This requires different domains to be populated. For the entire network-specific infrastructure purposes mentioned above, ENUM-like systems may be used in three ways: a) Independent of the related IN-services on the existing GSTN. In this case the synchronization of the two databases may be problematic. b) ENUM-like systems as a replacement of existing IN-services, providing also an INAP interface (mediation) to the GSTN. c) Access to an existing IN-database, which is providing an ENUM-like DNS interface to IP (mediation), creating the NAPTR records to be returned on the fly. In case b) and in case c) there is no synchronization problem, since the same repository is used from the IP-side and from the GSTN-side. 3. Abbreviations ASP Application Service Provider AUS Application Unique String CC Country Code CIC Carrier Identification Code DDI Direct dialing-in DN Dialed Number DNS Domain Name System GSTN Global Switched Telephone Network IN Intelligent Network INAP IN Application Part IPTSP IP Telephony Service Provider NAPTR Naming Authority Pointer NP Number Portability Stastny Expires - December 2002 [Page 4] Scenarios for ENUM and ENUM-like Systems June 2002 PoI Point of Interconnection PUA Personal User Agent RN Routing Number SCP Service Control Point SIP Session Initiation Protocol TDM Time Division Multiplex UCI Universal Communication Identifier UPT Universal Personal Telecommunication URI Uniform Resource Identifier URL Uniform Resource Locator VASP Value Added Service Provider VoIP Voice over IP 4. Number ranges to be used in ENUM ENUM according to Draft RFC2916bis is defined to be used in principle for any E.164 number. ITU-T Recommendation E.164 [4] distinguishes between geographic country codes (CC), CC for global services, CC for networks, shared CC and CC for trials. The usage of ENUM for geographic CC will be a national matter, the usage for other types of CC is currently under investigation within ITU-T SG2/Q1. Nevertheless, especially the rationale for the usage for service numbers will be similar for global and national numbers. 4.1 Geographic, mobile and personal numbers ENUM is defined for personal use; it therefore applies in any case in addition to geographic numbers to mobile numbers and to personal numbers (see also below). In all of these cases the ENUM End User is the e164.arpa domain name holder for the related E.164 number and provisioning directly or indirectly his/her NAPTR records in ENUM Tier 2 Name Servers. 4.2 ENUM Tier 3 and extensions (DDI) User ENUM may also be used by companies either having a PBX with direct dialing-in (DDI) and/or a switchboard or Centrex. In all cases the company is the domain name holder of the corresponding pilot number and wants to manage these entries in the ENUM Tier 2 Name Server. On the other hand, the company may want to give the right to Stastny Expires - December 2002 [Page 5] Scenarios for ENUM and ENUM-like Systems June 2002 provision the extension numbers to the individual user. In this case, an additional Tier 3 is necessary. In this case the following scenario applies and the company may provision the Tier 2 Name Servers with the following information: NAPTR Records to point to the switchboard, to e.g. mailto:office@company.com, to the company webpage and NS records pointing to the ENUM Tier 3 Name Servers holding the extensions visible to the public. The company may in addition operate a private ENUM-like system on its intranet holding all extensions. If the company has access to the Internet, clients may distinguish between the private ENUM-like system by entering the extensions without æ+Æ and escape to ENUM with æ+Æ. It is up to the company to make the whole or part of the private ENUM-like system visible to ENUM (e.g. with Split DNS) by linking the private ENUM System to Tier 2 of e164.arpa. 4.3 Service numbers in ENUM UPT Numbers UPT Numbers are personal numbers and may either be implemented nationally or internationally. National UPT numbers may be used like geographic and mobile numbers. International UPT based on +878 is currently not deployed in the GSTN with IN-based systems. The only application of international UPT (+87810) is based on IP. This is one example of a proper GSTN- termination on IP. Providing +87810 in ENUM is therefore not necessarily an alternate-line service, since the same termination (Personal User Agent - PUA) can be reached. If the user is registered on an IP-based terminal or on GSTN-based terminal, an incoming call is forwarded to this terminal. The user may also have the different types of call forwarding active. If +87810 is implemented in ENUM, it will allow incoming calls to the PUA from any IP-based terminal. National IN-based implementations of UPT exist. For these UPT numbers the same requirements on enumservices apply as for geographic and mobile numbers. Freephone Numbers: +800, +1-800, +43-800, ...: Freephone numbers on the GSTN require normally two IN-dips, one NP- dip for the CIC to select the Value Added Service Provider Stastny Expires - December 2002 [Page 6] Scenarios for ENUM and ENUM-like Systems June 2002 (VASP)providing the service and one IN-dip within the network of the VASP for the translation of the number to the DN (depending on origination, time, day, weather). If the assignee decides to enter his number in ENUM, this is a bypass of the operator providing the 800 service (VASP). Question 1: will this be allowed by national regulators or ITU (in case of +800) policy? Question 2: If yes, what are the requirements on the tel URI to provide similar services (origination context, time and day, ...) (see also section 4. Infrastructure ENUM). Even if freephone numbers are not allowed in User-ENUM, the requirements still apply for infrastructure ENUM, either for private- ENUM (the operator replacing his IN-Service by ENUM, or the operator is providing freephone service on an IP-based network (selected by CIC). For freephone numbers additional requirements may be necessary on enumservices and context information (e.g. phone-context, time-of- day). Premium Rate and Shared Cost Numbers: With freephone numbers the loser is the VASP and the winner is the ENUM End User, because he has to pay no charges to the VASP. With premium-rate and shared cost numbers, the loser is the ENUM End User, because he gets no money. But on the other hand, even if ENUM is not used for voice calls, it may be used for e-mail and web-pages with these types of numbers. For the usage in network-specific-ENUM the same applies as for freephone numbers. 5. Scenarios for User ENUM and ENUM-like Systems User-ENUM and User ENUM-like systems provide an end-to-end service. The database is populated by the recipient of a communication (the called user, ENUM End User) and the database is queried by the originator ("calling" user) before establishing the communication. Only if the origination terminal is not able (or willing) to access the DNS (e.g. from a phone on the GSTN), the user may use the service of an agent or proxy (e.g. a VoIP-gateway) to query the DNS on his behalf. It is depending on the service offered by the agent, if the communication is established without any further interaction by the originator, or if the originator may choose between different options. Stastny Expires - December 2002 [Page 7] Scenarios for ENUM and ENUM-like Systems June 2002 Related to voice (or phone) services, User-ENUM is always an alternate line service (this may not be true for infrastructure ENUM- like services). This is because it will be required (e.g. by the ENUM-Forum [5]and also by ETSI TS 102 051 "ENUM Administration in Europe" 6 that the ENUM End User is the assignee of an E.164 Number, and that the related E.164 Number has a termination on the GSTN (a working line or at least an announcement). To clarify, since the GSTN is technology-independent, this does not prevent, that the termination is on an IP-network, as we have seen with UPT. In this case the same terminal or User Agent may be used with ENUM (but not necessarily). The only exception of the above mentioned requirement may be, that special national or international numbering resources are made available for ENUM only usage. But also in this case an announcement may be required on the GSTN. Being an alternate line service implies, that the supplementary services connected to the line terminating on the GSTN (e.g. call forwarding) are not synchronized with the voice services provided by the Application Service Provider (ASP) pointed to with ENUM. This may cause user confusion and should especially be considered in using ENUM for call forwarding purposes. 5.1 IP-enabled terminal to IP-enabled terminal As already mentioned above, one of the most popular usages of User ENUM may be providing an alternate line service to the ENUM End User. There are benefits for both sides: the ENUM End User, if connected to the Internet, may be reached on his IP-enabled terminal, which is either a PC, a laptop or an IP-Phone, from any calling user on the Internet The ENUM End User needs to subscribe to either a SIP or H323 VoIP Service and is provided with a proper sip: or h323 address. He then chooses a domain related to one of his existing E.164 numbers to be entered into the ENUM System and adds a NAPTR record with the above URI into this domain. The calling user on the Internet only needs a proper client SW to query the ENUM System and a compatible VoIP Client or IP-Phone. If this is not available, the calling user may still establish a call via the GSTN. 5.2 IP-enabled terminal to the GSTN This scenario may be valid, if the calling user may not be able to use the information given in ENUM, or the ENUM End User may decide to Stastny Expires - December 2002 [Page 8] Scenarios for ENUM and ENUM-like Systems June 2002 enter an URI pointing to another E.164 Number (e.g. using a tel: URI pointing to his mobile phone). No additional provisions are necessary for the ENUM End User, but the calling user on the Internet needs to have a subscription to a VoIP Service Provider providing a gateway to the GSTN and the proper IP Phone client. 5.3 From the GSTN to IP-enabled terminals or to the GSTN Since calling users on the GSTN (e.g. from a steam phone) may not be able to access ENUM directly, they need a proxy to access ENUM. These proxies may be VoIP gateways provided by IP Telephony Service Providers (IPTSP). The gateway or the device controlling the gateway (e.g. the softswitch) accesses the ENUM System during call setup. It is up to the IPTSP, how this service is provided in detail. Some examples: ENUM Access Numbers: An IPTSP may provide a gateway from the GSTN to the IP network, which can be reached via an access number. The customer dials an access number to reach an IP Telephony Gateway and dials the E.164 number of the B-Subscriber. The gateway queries the ENUM database, if an entry for the E.164 number exists. If yes, the call is completed according the ENUM entry. If not, the call is placed on the IP network as usual, terminating finally on the GSTN. The service could either be open to the public, or requiring a subscription and identification (similar to a phone or credit card service). In the first case the billing would be the same for any type of call, regardless of destination, in the second case the access number would be a freephone number and the billing to the customer account may be dependant on destination. ENUM Portals: The above mentioned access to the gateway could be enhanced by providing a voice portal, allowing the calling customer to select between different choices, if provided by ENUM. So could the customer leave a voice message in a voice-box or send a voice-mail, if none of the voice services can be reached. Stastny Expires - December 2002 [Page 9] Scenarios for ENUM and ENUM-like Systems June 2002 IN trigger for ENUM (similar to "call-by-call" or "preselection"): A customer with a GSTN phone could subscribe to a supplementary service, that all outgoing calls are checked first with ENUM. If there is no entry in ENUM, the call will be completed normally on the GSTN. If the call may be completed via ENUM on IP, the tariff may be lower than a call completion on the GSTN. The subscriber may pay a fixed amount per month for this supplementary service. A simple way to implement this supplementary service is to trigger an IN-query for this subscriber and query ENUM via the SCP. If an entry is found, the call is routed to the next IP telephony gateway. If not, the call is treated by the SCP like a normal call and completed on the GSTN. 6. Scenarios for Infrastructure ENUM All infrastructure ENUM-like scenarios do not provide an end-to-end service. The ENUM-like DNS database is not provisioned by the End User, even if the number used is an E.164 Number, it is provisioned by the operator hosting the number or another entity. Therefore the opt-in principle does not apply and all required numbers may be entered. This implies that no information violating any End User privacy shall be contained in the database, if it is available on the Internet. The infrastructure ENUM-like DNS database is also not queried by the originating user establishing the communication, even if the database is available on the internet. One reason is that the information is of no direct use for the End User. The database is queried by network operators and service providers only during call setup or within the service provided. In some cases an existing IN database may be used as a repository. The ENUM-like database may be internal to an operator, used by a (con)-federation of operators either in an extranet or in a public domain on the Internet or in a second global tree within .arpa. The ENUM-like database may be used for only one specific service or for more than one service. In the latter case it is necessary to define enumservices to distinguish between the services (ala Service ID in IN?) During one call setup, a number of ENUM queries (dips) may be necessary. Stastny Expires - December 2002 [Page 10] Scenarios for ENUM and ENUM-like Systems June 2002 The following scenarios are not exhaustive, but may serve as basis for the necessary requirements for enumservice, tel:URI and parameters. 6.1 Support of NP services Number portability allows the telephone subscribers to keep their telephone numbers when they change service providers, move to a new location or change the the subscribed service (see draft-ietf-enum- e164-gstn-np-03) 7. If services providers use an IP-based infrastructure to provide telephone services, they need to support number portability as well. This can be achieved by either accessing the existing IN-infrastructure via the existing IN protocols, or by providing equivalent services via an ENUM-like DNS database. As already mentioned in 1.2.2, the ENUM-like DNS database may either be separate from the IN-based database, or may use the same repository. The support of ENUM may therefore apply for the following scenarios: Geographic number portability û an E.164 number is ported between to switching systems of the same operator within an geographic area, if the subscriber is changing location. The porting area is dependant on the national numbering plan used. Provider portability for geographic numbers û an E.164 number is ported from one operator to another operator, but staying on the same location. Provider portability for mobile numbers û an E.164 number is ported from one mobile operators to another within the same country. National service portability (freephone, personal numbers, ...) û an E.164 number is ported from one VASP to another within the same country. Global service portability (freephone, UPT, ...) û an E.164 number is ported from one global service provider to another. A quite challenging example for an infrastructure ENUM implementation may be the number portability in UPT. The current UPT implementation provides service provider portability, but only within the confederation using +87810 (VISIONng). If other confederation implement different numbering ranges either on IP or on the GSTN, infrastructure ENUM may be used for portability between confederations. Stastny Expires - December 2002 [Page 11] Scenarios for ENUM and ENUM-like Systems June 2002 Although many different implementations of NP exist in different networks and countries, most require the identification of a PoI of the terminating (hosting) network, either by a CIC or a routing number. For IP-based, the identification of the PoI and the protocol used may be sufficient. For service provider portability it is necessary, to find the service provider (carrier, operator) currently hosting the E.164 number and the Point of Interconnect. This is necessary e.g. for number portability of geographic, mobile and service numbers. For geographic number portability the RN may be necessary. For a given number, the following information needs to be retrieved: Service Provider: (CIC, RN, PoI) Protocol used at PoI: (also IP or TDM) Additional Parameters (e.g. context) What else? What are the requirements for enumservices, URIs and parameters? Note that the information retrieved (e.g. PoI) may be dependent on origination information (context). Remark: In this case the dialed number (DN) does not change. 6.2 Support for number translation services In case of service portability, if the network hosting the service has been reached, it is necessary to translate the dialed service number into another number - the final destination number. This translation may be dependant of origination information (context), date and time of day and other parameters. Also some billing information may be required. The support of ENUM may therefore apply for the following scenarios: Freephone service û the dialed freephone number (e.g. +800) is translated to the final destination number, depending on additional parameters. The same applies for premium rate, shared cost and other service numbers, like emergency numbers, etc. For a given number, the following information needs to be retrieved: Translated Number: New dialed number (DN) Additional Parameters: (e.g. context, date and time of day, etc.) Stastny Expires - December 2002 [Page 12] Scenarios for ENUM and ENUM-like Systems June 2002 What else? What are the requirements for enumservices, URIs and parameters? 6.3 Support for routing to IP-based PoIs Most phone calls currently are traversing at least three networks, the originating network, the transit network and the destination network, even in national calls. With international calls, even more transit networks may be involved. The PoIs between these networks are in all cases TDM-based, since no IP-based PoIs are defined yet. Currently a number of network operators are migrating from TDM-based networks to NGN IP-based networks by replacing parts of their networks with IP-based infrastructure (e.g. IP trunking). If all three of the above mentioned networks are using IP-based infrastructure within their networks, and the PoIs between the networks are TDM-based, a call may cross TDM-IP gateways six times, causing unacceptable delay and QoS. It is therefore necessary to introduce IP-based PoIs as soon as possible, to allow for the reduction of the number of TDM-IP gateways within a call to one or two. If a certain ingress network offers two types of PoI, it is necessary for the egress network to have some means to select between the two types of PoI offered and also to select the appropriate one. It is proposed to use infrastructure ENUM-like services for this purpose. Since the information about the network infrastructure and the optimal PoI to be used for a certain destination number is only known by the ingress (terminating) network, the appropriate information has to be provisioned in the infrastructure ENUM-like system by the terminating network. The information may be similar to the information used for number portability. The information related to the destination number in the infrastructure ENUM-like service is queried by the originating or transit network. If an IP-based PoI is found, the call is routed on the IP-network directly to the given PoI, if an TDM-based PoI or no information is found, the call is routed via the GSTN. The support of ENUM may therefore apply for the following scenarios: Usage of infrastructure ENUM within a network û if an operator has IP- and TDM-based technology within his network, and certain numbers Stastny Expires - December 2002 [Page 13] Scenarios for ENUM and ENUM-like Systems June 2002 may only be reached via IP-based technology (e.g. an GSTN access node connected to an IP-gateway), infrastructure ENUM may support a proper routing to his gateway. Usage of infrastructure ENUM on a global scale between networks - if an operator has IP- and TDM-based technology within his network, and certain numbers may only be reached via IP-based technology, he may provide IP- and TDM-based ingress PoIs to his network. It is now up to this operator to provide information related to the E.164 numbers he his hosting within his network in a global infrastructure ENUM database (e.g. e164infra.arpa). The information will be similar to the information provided for NP. It should be mentioned, that this global infrastructure ENUM database may also serve as basis for a global number protability database. 6.4 Requirements for Infrastructure ENUM It can be assumed, that within infrastructure ENUM mainly NAPTRs with tel: URIs will be used [8] It is therefore necessary to update the definition of the tel: URI accordingly and also define an enumservice to be used in the NAPTR records. For the ongoing discussion see 9 and "The ENUM 'tel' enumservice" 10 7. Examples of Usage and Additional Requirements ENUM was created to allow the mapping E.164 numbers to Internet names (e.g. sip:user@foo) to enable the reachability of VoIP clients (e.g. h323, sip) by E.164 numbers, either from the Internet or from the conventional phone network. In parallel the idea came up to use ENUM as an always up-to-date, public available business card, allowing to point to any URI, but especially to e-mail addresses (at least all ENUM tutorials use a VoIP URI and an e-mail address as an example). If one looks at any business card, one sees normally a name, a street address and/or a postal address, a phone number, a fax number (which is also a phone number), and an e-mail address, and some people now also point to their home-page and eventually to an IM address. Many people also list their mobile phone numbers, indicating intrinsically at least in Europe an sms-enabled number. Stastny Expires - December 2002 [Page 14] Scenarios for ENUM and ENUM-like Systems June 2002 If one wants to send a text document and both a fax and an e-mail address is provided at the business card, it is the choice of the originator (e.g. depending on the currently available device), whether the document is sent by fax or e-mail. Considering ENUM as an electronic business card service, this information is exactly what an ENUM End User wants to provide and what the originator expects to get, if he queries ENUM. Another way to use ENUM may be to provide URLs in documents or on web pages triggering an ENUM query, e.g. mailto:+12345 or fax:+12345 . In this case it is obvious, that either an e-mail or a Fax should be sent. Note: This requires an update to the relevant URI definitions. 7.1 ENUM Client Applications Stand-alone ENUM Client Application The simplest way to trigger an ENUM query from an IP-enabled terminal is to use a stand-alone application. In this case either an E.164 Number +12345 or a non-E.164 Number 12345 is entered. In case of the E.164 Numbers, the client is querying e164.arpa, in the other case a previously defined alternate domain may be used (e.g. a private dialing plan). The application queries ENUM or the ENUM-like System and displays the results (all the NAPTR records) in a human readable format similar to the information displayed on a business card or an e-mail signature, i.e containing the URI and additional information of the type of service. The user may now select a suitable URI and cut and paste or drag and drop the URI in the appropriate application (e.g. MS Outlook or a SIP Phone). The application may also be launched via mouse click, if the results are displayed as URLs. It is therefore necessary to define the enumservices in such a way, that a proper grouping if the information displayed may be possible. From a specific application If the user has already launched a specific application (e.g. an e- mail client or a SIP or H323 phone), the application may have an add- on, that in case of the input of an E.164 Number in the format +12345 an ENUM query is launched. Stastny Expires - December 2002 [Page 15] Scenarios for ENUM and ENUM-like Systems June 2002 In this case only ONE NAPTR record shall be selected, to replace the entered E.164 Number with the appropriate URI. It is therefore necessary to define the enumservices, which allow the application SW to identify in combination with the URI the proper NAPTR record to be used. From an URL containing an E.164 number It will also be useful to extend the definitions of existing URIs or define new URIs, which may be imbedded in documents or web pages to launch an ENUM query and the appropriate application: This will be easy for mailto. If mailto is used in the format mailto:+12345, this should imply, that an ENUM query is launched and the proper client application is provided with the result, namely an mailto:user@host (or the proper client is launched and then the ENUM query is done, if the application is ENUM enabled). 7.2 New URI Scheme enum: An enumservice (e.g. "enum") may be required to indicate that all services for a given E.164 number can be found within the ENUM entry of another E.164 number (instead of using CNAME, which may case problems in general and also within the DDDS algorithm). For example, a user owns three numbers, but wants to administrate his NAPTR records only in one place by pointing all his numbers to one set of services. Since the single NAPTR record requires an URI, which is not linked to a specific service, a new URI scheme "enum:" is required, which points to this E.164 number. It should be noted, that this new URI may also be convenient for usage to trigger an ENUM query from a link in a web-page or document (e.g. in an e-mail signature). The new URI has the format enum:+number and shall trigger the launch e.g. the lauch of the above mentioned ENUM stand-alone application, showing all information stored under this number. Stastny Expires - December 2002 [Page 16] Scenarios for ENUM and ENUM-like Systems June 2002 7.3 Resource Records to be used in ENUM Within the domain e164.arpa NS, NAPTR, CNAME and TXT records may be used. NS Records are used for delegation, the combined usage of NS records and NAPTR records shall be possible (e.g. for announcements, tones or a pointer to a switchboard). CNAME may be used e.g. for avoiding duplication of data, if parallel NDCs are used to reach the same destination during numbering plan modifications (e.g. pointing from 2.2.2.3.4.e164.arpa to 1.3.4.e164.arpa). The usage of CNAME for ENUM End Users is ffs). TXT records may be used within the delegation tree to add information and ALSO to the ENUM End User. Therefore at least the stand-alone clients shall be able to display the information contained in the TXT records. Note: It is one target of the trials to investigate the best way to inform users of invalid or incomplete numbers. This may either be done with NAPTR records pointing to tones or announcements, TXT records or the file (info) enumservice. Also the usage of the possibility to add additional information by the user with TXT records should be investigated. TXT records may also be useful during the trial for maintenance information. 8. Security Considerations This document does not not introduce new security implications other than those associated with the ENUm Service as defined in Draft RFC2916bis. 9. Acknowlegdements The author would like to thank Lawrence Conroy and Rudi Brandner for their comments and invaluable help. Stastny Expires - December 2002 [Page 17] Scenarios for ENUM and ENUM-like Systems June 2002 10. References 1 Scott Bradner, RFC2026, "The Internet Standards Process û Revision 3, "October 1996. 2 P. Faltstrom, "The E.164 to URI DDDS Application", draft-ietf-enum-rfc2916bis-01.txt, Work in Progress, March 2002 3 M.Mealling, "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" draft-ietf-urn-dns-ddds-database-08.txt, Work in Progress, February 2002 4 ITU-T Rec E.164 "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. 5 US ENUM Forum, www.enum-forum.org 6 ETSI Technical Specification TS 102 051 "ENUM Administration in Europe" Work in Progress, April 2002 7 M. Foster, T. McGarry and J. Yu "Number Portability in the GSTN: An Overview", draft-ietf-enum-e164-np-03.txt, Work in Progress, March 2002. 8 Vaha-Sipila, A., "URLs for Telephone Calls", RFC2806, April 2000. 9 J. Yu, "Extensions to the 'tel' and 'fax' URLs to Support Number Portability and Freephone Service", draft-yu-tel-urlù04.txt, Work in Progress, March 2002. 10 R. Brandner and L. Conroy, "The ENUM 'tel' enumservice", draft- brandner-enum-tel-00.txt, Work in Progress, February 2002. 11. Author's Address Richard Stastny OeFEG Postbox 147 Phone: +43-664-420-4100 1103 Vienna, Austria Email: richard.stastny@oefeg.at Stastny Expires - December 2002 [Page 18]