IANA Registration for Enumservice UNUSED

The Circuit Switched Network (CSN) of which the Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), and Public Land Mobile Network (PLMN) are part is designed to use E.164 numbers as native global addresses. If a potential caller has an E.164 number, then to place a call using this address he or she needs a way to pass the request either directly or indirectly to systems "in" the CSN for them to forward. ENUM ("E.164 Number Mapping") has introduced a mechanism to find other contact addresses when given an E.164 number. Thus, if the caller (or an agent somewhere in the call path) has access to the global Domain Name System (DNS), they can use ENUM as described in RFC 3761 to find alternative contacts to the E.164 number and place the call using whatever system was indicated in those contacts. In its intended use, an ENUM query would return a set of NAPTR ("Naming Authority Pointer") resource records , and these would be processed to select the appropriate communications contact choices. Each communications contact is held in a URI ("Universal Resource Indicator") generated from the contents of a NAPTR. However, ENUM entries may not exist for a given E.164 number for two reasons. Either the assignee who is entitled to register an ENUM domain associated with the E.164 number they hold has chosen not to request this registration, or the number is not currently allocated or assigned for communications service. In either situation, the caller has no other information and so no alternative to placing the call via the system that uses E.164 numbers as global identifiers; at present, this is the CSN.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This section describes the problems that arise where the ENUM system does not hold full information on all telephone numbers and clients display typical behaviour. The proposed solution to the problems described here is covered in and in the unused Enumservice registration in .

Traditionally, communications service is provided via a network that uses telephone numbers as global addresses. Examples of such networks are the PSTN, ISDN and PLMN. ENUM registrations are normally allowed only to customers who receive communications service via a telephone number. There may or may not be an ENUM registration when such service is provided. An ENUM registration is usually not permitted when no customer receives service via the corresponding telephone number. When considering ENUM registrations associated with telephone numbers, there are six scenarios: The number is not allocated to a service provider, the number is not currently used by that provider for communications service for a customer, the number is used to provide communications service to a customer and either that customer has not chosen to maintain an ENUM registration associated with that number, or the National Regulatory Authority (NRA) responsible for these numbers does not allow ENUM registrations, the number is used to provide communications service to a customer and that customer has an ENUM registration associated with that number. Communications service may alternatively be provided only by recourse to an ENUM lookup. Such numbers are known as "ENUM only" ranges. For these numbers there are two further possibilities: There is an ENUM registration and that number may be used for communications service, there is no ENUM registration and therefore the number is not used for communications service.

Assuming properly configured name servers and protocol conformant software, an ENUM query on a domain associated with a telephone number may elicit one of several outcomes based on the DNS response. In uses cases 1,2,3,and 6, the DNS response will indicate Name Error (RCODE=3, commonly known as NXDOMAIN, signifying that the domain name referenced in the query does not exist). In use cases 4 and 5, the DNS response will indicate No Error (RCODE=0). There are three possibilities here: There may be at least one usable NAPTR (meaning one in which the Enumservice is supported and the URI is resolved), in which case a communications attempt can be made. Even though the DNS response indicates no error, there may not be any usable NAPTRs in that response. This may happen because the domain owner has chosen not to populate the zone with NAPTR records. This response (RCODE=0, Number of Answers=0) is also known as NOHOST, meaning that the queried name exists but not for the record type that was requested. However, even if there are NAPTRs returned, none of the ones present may be usable. For example, the NAPTR RRSet may include only an "h323" Enumservice, whilst the client node is capable only of processing "sip" or "voice:tel" Enumservices. As it cannot know the case it has encountered, if the client receives a DNS response with no usable NAPTRs or one with RCODE=3, it must decide whether or not to attempt to place the call using other means.

Not every customer has an ENUM registration if provided service via a network that uses telephone numbers natively, and until this is the case, a reasonable strategy has been to attempt to place the call via such a network if it receives an ENUM response with RCODE=3. This is especially true if the National Regulatory Authority has chosen not to permit ENUM registrations at all for the telephone numbers under its control. This may also be the chosen strategy if the client receives a response with RCODE=0 (No Error), but with no usable NAPTRs.

In the case of an ENUM client getting a DNS response with RCODE=3, the semantics of that reply are ambiguous. Is this case 1,2,3, or 6? It is useful for the client to know if this is case 3, as in this case the "default" strategy will succeed. In cases 1 and 2, trying to place the call via a network that uses such numbers natively will result in that network returning an error. However, in case 6 even this cannot be guaranteed. Similarly, if the client finds no usable NAPTRs, is this case 4 or case 5? In the latter case the strategy will fail, whilst in the former case it will succeed.

However, for the "ENUM only" cases, there is a further problem. If the call is placed via a network that uses such numbers natively, it can be processed only via an ENUM lookup, and typically this will involve a gateway from that network performing the lookup and delivering the call onwards based on the response. If that gateway receives a response with RCODE=3 or one including no usable NAPTRs, then employing the "default" strategy (attempting the call via a network that uses these numbers natively) will cause a "loop". The call will be redirected to this network, where it will be routed to a gateway, this gateway will perform a lookup, will receive the same response, will attempt to place the call back to that network, and so on.

We propose an explicit indication of this "number unused" state (as described in points 1,2, and 6 in ). This uses a NAPTR in the zone associated with an unused telephone number, with an Enumservice called "unused" that should be taken as an assertion that the associated E.164 number is not assigned to a subscriber for communications service; it's an unused number. This NAPTR can also be used by a National Regulatory Authority (NRA) to indicate number blocks that it has reserved, and has not allocated to a service provider. It is a matter for individual countries whether or not they will support (or require) information giving the identity of the current "owner" of an E.164 number within their responsibility to be made available via IRIS/WHOIS. Thus it may not be possible to use these protocols to find out the entity responsible for a number or number range concerned, particularly where that number or range is not currently "in use". Since the registration and syntax of a terminal NAPTR for "E2U" Enumservices requires at least one URI scheme to be defined, we propose that the Enumservice "unused" will use an "http:" URI. The content referenced in this "http:" URI is a national matter. For example, it may be used to refer to a resource providing additional information about the reason for the existence of this record, and/or (where required by the competent regulatory authority) the identity of the entity responsible for this number.

Enumservice Name: "unused" Enumservice Type: "unused" Enumservice Subtypes: "data" URI Schemes: "http:" Functional Specification: The proposed solution in . Definition of expected action: When an ENUM lookup for a number explicitly returns the "unused" NAPTR, the response indicates to the client that the number is known to ENUM but there are no implicit communication end-points associated with it. The client can then signal an error to the application or end user instead of then trying and failing to terminate the call on the PSTN, which would have been the typical behaviour of an ENUM-aware VoIP/PSTN gateway if the ENUM lookup had returned a DNS response indicating NXDOMAIN or NOHOST. Thus, if a NAPTR with this Enumservice is received and processed, it indicates that there are no possible communication methods that can be used to reach the end point. The queried E.164 number is currently not allocated, or unassigned to a subscriber for communications service. The recipient SHOULD treat this response as if they had received a "number not in service" indication from a terminating network. Note that the generated URI is not a potential target for any current call. The content referred to in the "http:" URI MUST NOT be used in normal call processing but only if there is a non-call related reason. Security considerations: see . Intended usage: COMMON Authors Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact details see Authors' Addresses section). Any other information that the author deems interesting: None

Unassigned number $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 3.8.0 NAPTR 10 100 "u" "E2U+unused:http" "!^.*$!http://www.nra.example/static/numbering/cupid.htm?cupid=001!" . This indicates that the controller of the number block +441632960 does not provide telephony service via the number +441632960083; it is not assigned to a subscriber. Unallocated number $ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa. * NAPTR 10 100 "u" "E2U+unused:http" "!^.*$!http://www.nra.example/static/numbering/sabc.htm?SABC=1154!" This indicates that the number block +441154960 is not allocated by the NRA to any service provider and therefore no number in this block provides any communication service.

DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public. An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC ("Domain Name Security") to these, is provided in .

This document requests registration of the "unused" Enumservice with the sub-type "unused:http" according to the guidelines and specifications in RFC 3761 and the definitions in this document. This Enumservice is intended for use with the "http:" URI scheme.

Thanks to Patrik Faltstrom, Michael Mealling and Peter Koch for their thorough feedback, and colleagues in ETSI TISPAN who helped to clarify the operational features during the development of . Thanks also to the members of the ENUM working group for their wide ranging discussions. These have helped to indicate where changes were needed in this document to help explain what is an intrinsically difficult subject. Finally, thanks to Alex Mayrhofer for his useful document review, picking up the remaining issues.