idnits 2.17.1 draft-ietf-enum-3761bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2010) is 5018 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 2916 (Obsoleted by RFC 3761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM Scott Bradner 3 Internet-Draft Harvard University 4 Obsoletes: 3761 Lawrence Conroy 5 Intended status: Standards Track Roke Manor Research 6 Expires: December 25, 2010 Kazunori Fujiwara 7 Japan Registry Service Co., Ltd. 8 June 23, 2010 10 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation 11 Discovery System (DDDS) Application (ENUM) 12 14 Abstract 16 This document discusses the use of the Domain Name System (DNS) for 17 storage of data associated with E.164 numbers, and for resolving 18 those numbers into URIs that can be used (for example) in telephony 19 call setup. This document also describes how the DNS can be used to 20 identify the services associated with an E.164 number. This document 21 obsoletes RFC3761. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 25, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Use of These Mechanisms for Private Dialling Plans . . . 4 60 3. The ENUM Application Specifications . . . . . . . . . . 4 61 3.1. Application Unique String . . . . . . . . . . . . . . . 4 62 3.2. First Well Known Rule . . . . . . . . . . . . . . . . . 5 63 3.3. Expected Output . . . . . . . . . . . . . . . . . . . . 5 64 3.4. Valid Databases . . . . . . . . . . . . . . . . . . . . 5 65 3.4.1. Optional Name Server Additional Section Processing . . . 6 66 3.4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.4.3. Service Parameters . . . . . . . . . . . . . . . . . . . 7 68 3.4.3.1. ENUM Services . . . . . . . . . . . . . . . . . . . . . 7 69 3.4.3.2. Compound NAPTRs and Implicit ORDER/PREFERENCE Values . . 8 70 3.5. The ENUM Algorithm Always Returns a Single Rule . . . . 8 71 3.6. Case Sensitivity in ENUM . . . . . . . . . . . . . . . . 8 72 3.7. Collision Avoidance . . . . . . . . . . . . . . . . . . 9 73 4. ENUM Service Example . . . . . . . . . . . . . . . . . . 9 74 5. Clarification of DDDS Use in ENUM . . . . . . . . . . . 10 75 5.1. Collected Implications for ENUM Provisioning . . . . . . 10 76 5.2. Collected Implications for ENUM Clients . . . . . . . . 13 77 5.2.1. Non-terminal NAPTR Processing . . . . . . . . . . . . . 15 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . 16 80 7.1. DNS Security . . . . . . . . . . . . . . . . . . . . . . 16 81 7.2. Caching Security . . . . . . . . . . . . . . . . . . . . 17 82 7.3. Call Routing Security . . . . . . . . . . . . . . . . . 18 83 7.4. URI Resolution Security . . . . . . . . . . . . . . . . 18 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . 19 85 9. Changes from RFC 3761 . . . . . . . . . . . . . . . . . 19 86 9.1. Draft Change Log . . . . . . . . . . . . . . . . . . . . 19 87 10. References . . . . . . . . . . . . . . . . . . . . . . . 21 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 10.2. Informative References . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 This document discusses the use of the Domain Name System (DNS, 94 [RFC1034],[RFC1035]) for storage of data associated with E.164 95 [E.164] numbers, and for resolving those numbers into URIs that can 96 be used (for example) in telephony call setup. This document also 97 describes how the DNS can be used to identify the services associated 98 with an E.164 number. This document includes a Dynamic Delegation 99 Discovery System (DDDS) Application specification, as detailed in the 100 document series described in [RFC3401]. This document obsoletes 101 [RFC3761]. 103 Using the process defined in this document, International Public 104 Telecommunication Numbers in the international format defined in 105 International Telecommunications Union (ITU) Recommendation E.164 106 [E.164] (called here "E.164 numbers") can be transformed into DNS 107 names. Using existing DNS services (such as delegation through NS 108 records and queries for NAPTR resource records), one can look up the 109 services associated with that E.164 number. This takes advantage of 110 standard DNS architectural features of decentralized control and 111 management of the different levels in the lookup process. 113 The domain "e164.arpa" has been assigned to provide an infrastructure 114 in the DNS for storage of data associated with E.164 numbers. To 115 facilitate distributed operations, this domain is divided into 116 subdomains. Holders of E.164 numbers who want the numbers to be 117 listed in the DNS should contact the appropriate zone administrator 118 as listed in the policy attached to the zone. One should start 119 looking for this information by examining the SOA resource record 120 associated with the zone, just like in normal DNS operations. 122 Of course, as with other domains, policies for such listings will be 123 controlled on a subdomain basis and may differ in different parts of 124 the world. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in BCP 14, RFC 2119 131 [RFC2119]. 133 DNS Resource Record types mentioned in this document are defined, 134 respectively, in [RFC1035] (NS, SOA, A, MX), [RFC3403] (NAPTR), and 135 [RFC2782] (SRV). 137 All other capitalized terms are taken from the vocabulary found in 138 the DDDS algorithm specification found in [RFC3402]. 140 2. Use of These Mechanisms for Private Dialling Plans 142 Similar mechanisms might be used for other kinds of digit strings 143 (such as numbers in private dialling plans). If these mechanisms are 144 used for dialling plans (or for other unrelated digit strings), the 145 domain apex used for such translation MUST NOT be e164.arpa, to avoid 146 conflict with this specification. 148 Also, the Application Unique String (see Section 3.1) used with 149 dialling plans SHOULD be the full number as specified, without the 150 leading '+' character. The '+' character is used to further 151 distinguish E.164 numbers in international format from dialled digit 152 strings or other digit sequences. 154 For example, to address the E.164 number +44-3069-990038 a user 155 might dial "03069990038" or "00443069990038" or "011443069990038". 156 These dialled digit strings differ from one another, but none of 157 them start with the '+' character. 159 Finally, if these techniques are used for dialling plans or other 160 digit strings, implementers and operators of systems using these 161 techniques for such purpose MUST NOT describe these schemes as 162 "ENUM". The initial "E" in ENUM stands for E.164, and the term 163 "ENUM" is used exclusively to describe application of these 164 techniques to E.164 numbers according to this specification. 166 3. The ENUM Application Specifications 168 This template defines the ENUM DDDS Application according to the 169 rules and requirements found in [RFC3402]. The DDDS database used by 170 this Application is found in [RFC3403], which is the document that 171 defines the NAPTR DNS Resource Record type. 173 ENUM is designed as a way to translate from E.164 numbers to URIs 174 using NAPTR records stored in DNS. The First Well Known Rule for any 175 ENUM query creates a key (a fully qualified domain name, or FQDN, 176 within the e164.arpa domain apex) from an E.164 number. This FQDN is 177 queried for NAPTR records and returned records are processed and 178 interpreted according to this specification. 180 3.1. Application Unique String 182 The Application Unique String (AUS) is a fully qualified E.164 number 183 minus any non-digit characters except for the '+' character which 184 appears at the beginning of the number. The '+' is kept to provide a 185 well understood anchor for the AUS in order to distinguish it from 186 other telephone numbers that are not part of the E.164 namespace. 188 For example, the E.164 number could start out as "+44-116-496-0348". 189 To ensure that no syntactic sugar is allowed into the AUS, all non- 190 digits except for '+' are removed, yielding "+441164960348". 192 3.2. First Well Known Rule 194 The First Well Known Rule converts an Application Unique String (AUS) 195 into an initial key. That key is used as an index into the 196 Application's Rules Database. For ENUM, the rules database is the 197 DNS, so the key is a fully qualified domain name (FQDN). 199 In order to convert the AUS to a unique key in this database the 200 string is converted into a domain name according to this algorithm: 202 1. Remove all characters with the exception of the digits. For 203 example, given the E.164 number "+44-20-7946-0148" (which would 204 then have been converted into an AUS of "+442079460148"), this 205 step would simply remove the leading '+', producing 206 "442079460148". 207 2. Reverse the order of the digits. Example: "841064970244" 208 3. Put dots ('.') between each digit. Example: 209 "8.4.1.0.6.4.9.7.0.2.4.4" 210 4. Append the string ".e164.arpa." to the end and interpret as a 211 domain name. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. 213 The E.164 namespace and this Application's database are organized in 214 such a way that it is possible to go directly from the name to the 215 smallest granularity of the namespace directly from the name itself, 216 so no further processing is required to generate the initial key. 218 This domain name is used to request NAPTR records. Each of these 219 records may contain the end result or, if its flags field is empty, 220 produces a new key in the form of a domain name that is used to 221 request further NAPTR records from the DNS. 223 3.3. Expected Output 225 The output of the last DDDS loop is a Uniform Resource Identifier in 226 its absolute form according to the production in the 227 Collected ABNF found in [RFC3986]. 229 3.4. Valid Databases 231 At present only one DDDS Database is specified for this Application. 232 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 233 Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS 234 resource record to contain the rewrite rules. The Keys for this 235 database are encoded as domain names. 237 The character set used for the substitution expression is UTF-8 238 [RFC3629]. The allowed input characters are all those characters 239 that are allowed anywhere in an E.164 number. The characters allowed 240 to be in a Key are those that are currently defined for DNS domain 241 names. 243 3.4.1. Optional Name Server Additional Section Processing 245 Some nameserver implementations attempt to be intelligent about items 246 that are inserted into the additional information section of a given 247 DNS response. For example, BIND will attempt to determine if it is 248 authoritative for a domain whenever it encodes one into a packet. If 249 it is, then it will insert any A records it finds for that domain 250 into the additional information section of the answer until the 251 packet reaches the maximum length allowed. It is therefore 252 potentially useful for a client to check for this additional 253 information. 255 It is also easy to contemplate an ENUM enhanced nameserver that 256 understands the actual contents of the NAPTR records it is serving 257 and inserts more appropriate information into the additional 258 information section of the response. Thus, DNS servers MAY interpret 259 flag values and use that information to include appropriate resource 260 records in the Additional Information section of the DNS packet. 261 Clients are encouraged to check for additional information but are 262 not required to do so. See Section 4.2 of [RFC3403] ("Additional 263 Information Processing") for more information on NAPTR records and 264 the Additional Information section of a DNS response packet. 266 3.4.2. Flags 268 This Database contains a field that contains flags that signal when 269 the DDDS algorithm has finished. At this time only one flag, "U", is 270 defined. This means that this Rule is the last one and that the 271 output of the Rule is a URI [RFC3986]. See Section 4.3 of [RFC3404]. 273 If a client encounters a resource record with an unknown flag, it 274 MUST ignore it and move to the next Rule. This test takes precedence 275 over any ordering since flags can control the interpretation placed 276 on fields. 278 A novel flag might change the interpretation of the Regexp and/or 279 Replacement fields such that it is impossible to determine if a 280 resource record matched a given target. 282 If this flag is not present then this rule is non-terminal. If a 283 Rule is non-terminal then the result produced by its rewrite rule 284 MUST be a FQDN. Clients MUST use this result as the new Key in the 285 DDDS loop (i.e., the client will query for NAPTR resource records at 286 this FQDN). 288 3.4.3. Service Parameters 290 Service Parameters for this Application take the following Augmented 291 Backus-Naur Form (ABNF, specified in [RFC5234]) and are found in the 292 Services field of the NAPTR record that holds a terminal rule. Where 293 the NAPTR holds a non-terminal Rule, the Services field SHOULD be 294 empty, and clients SHOULD ignore its content. 296 service-field = "E2U" 1*(servicespec) 297 servicespec = "+" enumservice 298 enumservice = type 0*(subtypespec) 299 subtypespec = ":" subtype 300 type = 1*32(ALPHA / DIGIT / "-") 301 subtype = 1*32(ALPHA / DIGIT / "-") 303 In other words, a non-optional "E2U" (used to denote ENUM only 304 Rewrite Rules in order to mitigate record collisions) followed by one 305 or more Enumservices which indicate the class of functionality a 306 given end point offers. Each Enumservice is indicated by an initial 307 '+' character. 309 3.4.3.1. ENUM Services 311 Enumservices may be specified and registered via the process defined 312 in "IANA Registration of Enumservices: Guide, Template and IANA 313 Considerations" [SV_GUIDE]. This registration process is not open to 314 any Enumservice that has '-' as the second character in its type 315 string. 317 In particular, this registration process is not open to Enumservice 318 types starting with the facet "X-". This "X-" facet is reserved for 319 experimental or trial use, and any such Enumservices cannot be 320 registered using the normal process. 322 Finally, any Enumservice type that starts with the facet "P-" is 323 intended for use exclusively on private networks. As such, NAPTRs 324 containing Enumservice types starting "P-" should not be seen on the 325 global Internet. Even if an ENUM client recognizes and can engage in 326 the Enumservice, it may be incapable of resolving the URI generated 327 by the containing NAPTR. These Enumservices WILL NOT be registered. 329 Such Enumservices MUST NOT be provisioned in any system that provides 330 answers to DNS queries for NAPTR resource record sets (RRSets) from 331 entities outside the private network context in which these 332 Enumservices are intended for use. Unless an ENUM client is sure 333 that it is connected to the private network for which these NAPTRs 334 are provisioned and intended, it MUST discard any NAPTR with an 335 Enumservice type that starts with the "P-" facet. 337 3.4.3.2. Compound NAPTRs and Implicit ORDER/PREFERENCE Values 339 It is possible to have more than one Enumservice associated with a 340 single NAPTR. These Enumservices share the same Regexp field and so 341 generate the same URI. Such a "compound" NAPTR could well be used to 342 indicate a mobile phone that supports both "voice:tel" and "sms:tel" 343 Enumservices. 344 The Services field in that case would be "E2U+voice:tel+sms:tel". 346 A compound NAPTR can be treated as a set of NAPTRs that each hold a 347 single Enumservice. These reconstructed NAPTRs share the same ORDER 348 and PREFERENCE/PRIORITY field values but should be treated as if each 349 had a logically different priority. A left-to-right priority is 350 assumed. 352 3.5. The ENUM Algorithm Always Returns a Single Rule 354 The ENUM algorithm always returns a single rule. Individual 355 applications may have application-specific knowledge or facilities 356 that allow them to present multiple results or speed selection, but 357 these should never change the operation of the algorithm. 359 3.6. Case Sensitivity in ENUM 361 Case sensitivity was not mentioned at all in [RFC3761] (or 362 [RFC2916]), but has been seen as an issue during interoperability 363 test events since then. There are a lot of case-sensitive clients in 364 current deployment. 366 The only place where NAPTR field content is case sensitive is in any 367 static text in the Repl sub-field of the Regexp field (see Section 368 3.2 of [RFC3402] for Regexp field definitions). In that sub-field, 369 case must be preserved when generating the record output. Elsewhere, 370 case sensitivity is not used. 372 Where ENUM clients can be exposed to NAPTR records that may hold 373 field content of different capitalisation, clients MUST use case- 374 insensitive processing. ENUM clients that operate using the Internet 375 to send their queries, typically called "Public ENUM" scenarios, fall 376 into this category. 378 Some ENUM clients operate within closed networks; for example, within 379 isolated data networks operated by Communication Service Providers. 381 These are typically called "Infrastructure ENUM" scenarios. All 382 zones provisioned within such closed networks usually have a known 383 capitalisation for ENUM record string content, as provisioning 384 systems for such networks are often carefully controlled. In such an 385 environment, clients are never exposed to records with capitalisation 386 that is "unexpected" and so can be (and have been) designed with case 387 sensitive processing. Only if a client is known to operate in an 388 environment in which capitalisation of all ENUM records it will 389 encounter is known and controlled MAY that client use case sensitive 390 processing. 392 3.7. Collision Avoidance 394 An ENUM-compliant application MUST only pass numbers to the ENUM 395 client query process that it believes are E.164 numbers (e.g. it MUST 396 NOT pass dialled digit strings to the ENUM query process). 398 Since number plans may change over time, it can be impossible for a 399 client to know if the number it intends to query is assigned and 400 active within the current number plan. Thus it is important that 401 such clients can distinguish data associated with the E.164 number 402 plan from that associated with other digit strings (i.e. numbers NOT 403 according to the E.164 number plan). 405 It is the responsibility of operators provisioning data into domains 406 to ensure that data associated with a query on an E.164 number cannot 407 be mistaken for data associated with other uses of NAPTRs. 409 Three techniques are used to achieve this: 411 o the domain apex used for purposes other than data associated with 412 the E.164 number plan MUST NOT be e164.arpa. 413 o for use other than with E.164 numbers, the Application Unique 414 String MUST NOT begin with the '+' character, whilst for ENUM use, 415 the AUS MUST begin with this character. 416 o NAPTRs that are intended for other DDDS applications MUST NOT 417 include the E2U token in their service field, whilst NAPTRs 418 intended for ENUM use MUST include this token. 420 4. ENUM Service Example 422 $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. 423 NAPTR 100 50 "u" "E2U+sip" 424 "!^(\\+441632960083)$!sip:\\1@example.com!" . 425 NAPTR 100 51 "u" "E2U+h323" 426 "!^\\+441632960083$!h323:operator@example.com!" . 427 NAPTR 100 52 "u" "E2U+email:mailto" 428 "!^.*$!mailto:info@example.com!" . 430 This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is 431 preferably contacted by SIP, secondly via H.323 for voice, and 432 thirdly by SMTP for messaging. Note that the Enumservice tokens 433 "sip", "h323", and "email" are Enumservice Types registered with 434 IANA, and they have no implicit connection with the protocols or URI 435 schemes with the same names. 437 In all cases, the next step in the resolution process is to use the 438 resolution mechanism for each of the protocols (specified by the URI 439 schemes sip, h323 and mailto) to know what node to contact. 441 In each of the first two records, the ERE sub-field matches only 442 queries that have been made for the telephone number +441632960083. 443 In the last record, the ERE matches any Application Unique String 444 value. The first record also demonstrates how the matched pattern 445 can be used in the generated URI. 447 Note that where NAPTR resource records are shown in DNS master file 448 syntax (as in this example above), each backslash must itself be 449 escaped using a second backslash. The DNS on-the-wire packet will 450 have only a single backslash in each case. 452 5. Clarification of DDDS Use in ENUM 454 ENUM is a DDDS Application. This means that it relies on the DDDS 455 for its operation. DDDS is designed to be flexible, but that opens 456 the possibility of differences of interpretation. This section is 457 intended to cover ENUM-specific interpretation of text within the 458 DDDS specifications. The goal is to ensure interoperability between 459 ENUM clients and provisioning systems used to populate domains with 460 E2U NAPTRs. 462 As part of on-going development work on the ENUM specifications, an 463 analysis has been carried out into the way in which ENUM client and 464 provisioning system implementations behave, and the interoperability 465 issues that have arisen. This (informative) analysis is provided in 466 [RFC5483]. The following recommendations reflect that analysis, and 467 further narrative explaining the issues can be found there. 469 5.1. Collected Implications for ENUM Provisioning 471 ENUM NAPTRs SHOULD NOT include characters outside the printable US- 472 ASCII equivalent range (U+0020 to U+007E) unless it is clear that all 473 ENUM clients they are designed to support will be able to process 474 such characters correctly. If ENUM zone provisioning systems require 475 non-ASCII characters, these systems MUST encode the non-ASCII data to 476 emit only US-ASCII characters by applying the appropriate mechanism 477 (such as those in [RFC3492], [RFC3987]). Non-printable characters 478 SHOULD NOT be used, as ENUM clients may need to present NAPTR content 479 in a human-readable form. 481 The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD 482 NOT be provisioned into the Regexp field of E2U NAPTRs. 484 The Registrant and the ENUM zone provisioning system he or she uses 485 SHOULD NOT rely on ENUM clients solely taking account of the value of 486 the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a 487 Registrant SHOULD place into his or her zone only contacts that he or 488 she is willing to support; even those with the worst ORDER and 489 PREFERENCE/PRIORITY values MAY be selected by an end user. 491 All E2U NAPTRs SHOULD hold a default value in their ORDER field. A 492 value of "100" is recommended, as it seems to be used in most 493 provisioned domains. 495 Some ENUM clients have been known to pre-discard NAPTRs within an 496 RRSet simply because these records do not have the lowest ORDER 497 value found in that RRSet. Other ENUM client implementations 498 appear to have confused ORDER and PREFERENCE/PRIORITY fields, 499 using the latter as the major sort term rather than the former as 500 specified. Conversely, ENUM zones have been provisioned within 501 which the ORDER value varies but the PREFERENCE/PRIORITY field 502 value is static. This may have been intentional, but given the 503 different client behaviour in the face of varying ORDER field 504 values, may not produce the desired response. 506 Multiple NAPTRs with identical ORDER and identical PREFERENCE/ 507 PRIORITY field values SHOULD NOT be provisioned into an RRSet unless 508 the intent is that these NAPTRs are truly identical and there is no 509 preference between them. Implementers SHOULD NOT assume that the DNS 510 will deliver NAPTRs within an RRSet in a particular sequence. 512 An ENUM zone provisioning system SHOULD assume that, if it generates 513 compound NAPTRs, the Enumservices will normally be processed in left- 514 to-right order within such NAPTRs. 516 ENUM zone provisioning systems SHOULD assume that, once a non- 517 terminal NAPTR has been selected for processing, the ORDER field 518 value in a domain referred to by that non-terminal NAPTR will be 519 considered only within the context of that referenced domain (i.e., 520 the ORDER value will be used only to sort within the current RRSet 521 and will not be used in the processing of NAPTRs in any other RRSet). 523 ENUM zone provisioning systems SHOULD use '!' (U+0021) as their 524 Regexp delimiter character. 526 If the Regexp delimiter is a character in the static text of the Repl 527 sub-field, it MUST be "escaped" using the escaped-delimiter 528 production of the BNF specification shown in Section 3.2 of [RFC3402] 529 (i.e., "\!", U+005C U+0021). Note that when a NAPTR resource record 530 is entered in DNS master file syntax, the backslash itself must be 531 escaped using a second backslash. 533 If present in the ERE sub-field of an ENUM NAPTR, the literal 534 character '+' MUST be escaped as "\+" (i.e. U+005C U+002B). Note 535 that, as always, when a NAPTR resource record is entered in DNS 536 master file syntax, the backslash itself must be escaped using a 537 second backslash. 539 Whilst this client behaviour is non-compliant, ENUM provisioning 540 systems and their users should be aware that some ENUM clients have 541 been detected with poor (or no) support for non-trivial ERE sub-field 542 expressions. 544 ENUM provisioning systems SHOULD be cautious in the use of multiple 545 back-reference patterns in the Repl sub-field of NAPTRs they 546 provision. Some clients have limited buffer space for character 547 expansion when generating URIs. These provisioning systems SHOULD 548 check the back-reference replacement patterns they use, ensuring that 549 regular expression processing will not produce excessive-length URIs. 551 ENUM zones MUST NOT be provisioned with NAPTRs according to the 552 obsolete syntax of [RFC2916], and MUST be provisioned with NAPTRs in 553 which the Services field is according to Section 3.4.3 of this 554 document. 556 [RFC2915] and [RFC2916] have been obsoleted by [RFC3401]-[RFC3404] 557 and by this document, respectively. 559 Enumservices in which the Enumservice type starts with the facet "P-" 560 MUST NOT be provisioned in any system that provides answers to DNS 561 queries for NAPTR resource record sets from entities outside the 562 private network context in which these Enumservices are intended for 563 use. 565 As current support is limited, non-terminal NAPTRs SHOULD NOT be 566 provisioned in ENUM zones unless it is clear that all ENUM clients 567 that this environment supports can process these. 569 When populating a set of domains with NAPTRs, ENUM zone provisioning 570 systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 571 such NAPTRs will be processed in an ENUM query. 573 In a non-terminal NAPTR that may be encountered in an ENUM query 574 (i.e., one with an empty Flags field), the Services field SHOULD be 575 empty. 577 A non-terminal NAPTR MUST include its target domain in the (non- 578 empty) Replacement field as this field will be interpreted as holding 579 the FQDN that forms the next key output from this non-terminal rule. 580 The Regexp field MUST be empty in a non-terminal NAPTR intended to be 581 encountered during an ENUM query. 583 5.2. Collected Implications for ENUM Clients 585 If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query 586 to terminate and processing SHOULD continue with the next NAPTR in 587 the returned RRSet. 589 ENUM clients SHOULD NOT discard NAPTRs in which they detect 590 characters outside the US-ASCII printable range (0x20 to 0x7E 591 hexadecimal). 593 ENUM clients MAY discard NAPTRs that have octets in the Flags, 594 Services, or Regexp fields that have byte values outside the US-ASCII 595 equivalent range (i.e., byte values above 0x7F). Clients MUST be 596 ready to encounter NAPTRs with such values without failure. 598 ENUM clients MUST sort the records of a retrieved NAPTR RRSet into 599 sequence using the ORDER and PREFERENCE fields of those records. The 600 ORDER is to be treated as the major sort term, with lowest numerical 601 values being earlier in the sequence. The PREFERENCE/PRIORITY field 602 is to be treated as the minor sort term, with lowest numerical values 603 being earlier in the sequence. 605 ENUM clients SHOULD NOT discard a NAPTR record until it is considered 606 or a record previous to it in the evaluation sequence has been 607 accepted. 609 Notably, if a record has a "worse" ORDER value than others in this 610 RRSet, that record MUST NOT be discarded before consideration 611 unless a record has been accepted as the result of this ENUM 612 query. 614 Where the ENUM client presents a list of possible URLs to the end 615 user for his or her choice, it MAY present all NAPTRs -- not just the 616 ones with the lowest currently unprocessed ORDER field value. The 617 client SHOULD observe the ORDER and PREFERENCE/PRIORITY values 618 specified by the Registrant. 620 ENUM clients SHOULD accept all NAPTRs with identical ORDER and 621 identical PREFERENCE/PRIORITY field values, and process them in the 622 sequence in which they appear in the DNS response. (There is no 623 benefit in further randomizing the order in which these are 624 processed, as intervening DNS Servers might have done this already). 626 ENUM clients SHOULD consider the ORDER field value only when sorting 627 NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be 628 taken into account when processing NAPTRs across a sequence of DNS 629 queries created by traversal of non-terminal NAPTR references. 631 ENUM clients receiving compound NAPTRs (i.e., ones with more than one 632 Enumservice) SHOULD process these Enumservices using a left-to-right 633 sort ordering, so that the first Enumservice to be processed will be 634 the leftmost one, and the last will be the rightmost one. 636 ENUM clients MUST be ready to process NAPTRs that use a different 637 character from '!' as their Regexp Delimiter without failure. 639 ENUM clients SHOULD NOT assume that the delimiter is the last 640 character of the Regexp field. 642 Unless they are sure that in their environment this is the case, 643 in general an ENUM client may still encounter NAPTRs that have 644 been provisioned with a following 'i' (case-insensitive) flag, 645 even though that flag has no effect at all in an ENUM scenario. 647 ENUM clients SHOULD discard NAPTRs that have more or less than 3 648 unescaped instances of the delimiter character within the Regexp 649 field. 651 In the spirit of being liberal with what it will accept, if the 652 ENUM client is sure how the Regexp field should be interpreted, it 653 MAY choose to process the NAPTR even in the face of an incorrect 654 number of unescaped delimiter characters. If it is not clear how 655 the Regexp field should be interpreted, the client MUST discard 656 the NAPTR. 658 ENUM clients MUST be ready to process NAPTRs that have non-trivial 659 patterns in their ERE sub-field values without failure. 661 ENUM clients MUST be ready to process NAPTRs with many copies of 662 back-reference patterns within the Repl sub-field without failure. 664 ENUM clients MUST be ready to process NAPTRs with a DDDS Application 665 identifier other than 'E2U' without failure. 667 When an ENUM client encounters a compound NAPTR (i.e., one containing 668 more than one Enumservice) and cannot process or cannot recognize one 669 of the Enumservices within it, that ENUM client SHOULD ignore this 670 Enumservice and continue with the next Enumservice within this 671 NAPTR's Services field, discarding the NAPTR only if it cannot handle 672 any of the Enumservices contained. These conditions SHOULD NOT be 673 considered errors. 675 ENUM clients MUST support ENUM NAPTRs according to syntax defined in 676 Section 3.4.3. ENUM clients SHOULD also support ENUM NAPTRs 677 according to the obsolete syntax of [RFC2916]; there are still zones 678 that hold "old" syntax NAPTRs. The informational [RFC3824] 679 recommended such support. 681 Unless an ENUM client is sure that it is connected to the private 682 network for which these NAPTRs are provisioned and intended, it MUST 683 discard any NAPTR with an Enumservice type that starts with the "P-" 684 facet. 686 5.2.1. Non-terminal NAPTR Processing 688 ENUM clients MUST be ready to process NAPTRs with an empty Flags 689 field ("non-terminal" NAPTRs) without failure. More generally, non- 690 terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY 691 discard non-terminal NAPTRs they encounter. 693 ENUM clients SHOULD ignore any content of the Services field when 694 encountering a non-terminal NAPTR with an empty Flags field. 696 ENUM clients receiving a non-terminal NAPTR with an empty Flags field 697 MUST treat the Replacement field as holding the FQDN to be used in 698 the next round of the ENUM query. An ENUM client MUST discard such a 699 non-terminal NAPTR if the Replacement field is empty or does not 700 contain a valid FQDN. By definition, it follows that the Regexp 701 field will be empty in such a non-terminal NAPTR. If present in a 702 non-terminal NAPTR, a non-empty Regexp field MUST be ignored by ENUM 703 clients. 705 If a problem is detected when processing an ENUM query across 706 multiple domains (by following non-terminal NAPTR references), the 707 ENUM query SHOULD NOT be abandoned, but instead processing SHOULD 708 continue at the next NAPTR after the non-terminal NAPTR that referred 709 to the domain in which the problem would have occurred. 711 If all NAPTRs in a domain traversed as a result of a reference in a 712 non-terminal NAPTR have been discarded, the ENUM client SHOULD 713 continue its processing with the next NAPTR in the "referring" RRSet 714 (i.e., the one including the non-terminal NAPTR that caused the 715 traversal). 717 ENUM clients MUST be prepared to encounter a referential loop in 718 which a sequence of Non-Terminal NAPTRs are retrieved within an ENUM 719 query that refer back to an earlier FQDN. ENUM clients MUST be able 720 to detect and recover from such a loop, without failure. 722 ENUM clients MAY consider a chain of more than 5 "non-terminal" 723 NAPTRs traversed in a single ENUM query as an indication that a 724 referential loop has been entered. 726 When a domain is about to be entered as the result of a reference in 727 a non-terminal NAPTR, and the ENUM client has detected a potential 728 referential loop, the client SHOULD discard the non-terminal NAPTR 729 from its processing and continue with the next NAPTR in its list. It 730 SHOULD NOT make the DNS query indicated by that non-terminal NAPTR. 732 6. IANA Considerations 734 RFC 2916 and then RFC 3761 (which this document replaces) requested 735 IANA to delegate the E164.ARPA domain following instructions that 736 were provided by the IAB (as described in [RFC3245]). The domain was 737 delegated according to those instructions (which are published at 738 ). 740 Names within this zone are to be delegated to parties consistent with 741 ITU Recommendation E.164. The names allocated should be hierarchic 742 in accordance with ITU Recommendation E.164, and the codes should be 743 assigned in accordance with that Recommendation. 745 The IAB is to coordinate with ITU Telecommunications Standardization 746 Bureau (TSB) if the technical contact for the domain e164.arpa is to 747 change, as ITU TSB has an operational working relationship with this 748 technical contact which would need to be reestablished. 750 See [SV_GUIDE] for Enumservice-related IANA Considerations. 752 7. Security Considerations 754 7.1. DNS Security 756 As ENUM uses DNS, which in its current form is an insecure protocol, 757 there is no mechanism for ensuring that the data one gets back is 758 authentic. As ENUM is deployed on the global Internet, it is 759 expected to be a popular target for various kind of attacks, and 760 attacking the underlying DNS infrastructure is one way of attacking 761 the ENUM service itself. 763 There are multiple types of attacks that can happen against DNS that 764 ENUM implementations should consider. See Threat Analysis of the 765 Domain Name System [RFC3833] for a review of the various threats to 766 the DNS. 768 Because of these threats, a deployed ENUM service SHOULD include 769 mechanisms to mitigate these threats. Most of the threats can be 770 solved by verifying the authenticity of the data via mechanisms such 771 as DNS Security (DNSSEC) [RFC4033]. 773 Others, such as Denial-Of-Service attacks, cannot be solved by data 774 authentication. It is important to remember that these threats 775 include not only the NAPTR lookups themselves, but also the various 776 records needed for the services to be useful (for example NS, MX, SRV 777 and A records). 779 Even if DNSSEC is deployed, it cannot protect against every kind of 780 attack on DNS. ENUM is often used for number or address translation; 781 retrieving an address through an ENUM lookup with DNSSEC support does 782 not, however, ensure that the service is imune to attack. It is 783 unwise for a service blindly to trust that the address it has 784 retrieved is valid and that the entity to which it connects using 785 that address is the service peer it intended to contact. A service 786 SHOULD always authenticate the entity to which it connects during the 787 service setup phase, and not rely on address or identity data 788 retrieved outside that service. 790 Finally, as an ENUM service will be implementing some type of 791 security mechanism, software which implements ENUM MUST be prepared 792 to receive DNSSEC and other standardized DNS security responses, 793 including large responses and other EDNS0 signalling (see [RFC2671]), 794 unknown resource records (see [RFC3597]), and so on. 796 7.2. Caching Security 798 The DNS architecture makes extensive use of cacheing of records at 799 intermediary nodes to improve performance. The propagation time (for 800 changes to resource records to be reflected in query responses to end 801 nodes) approaches the "time to live" value for those records. There 802 may be a number of different resource records involved in the 803 resolution of a communication target. Changes to these records may 804 not be synchronised (particularly if these resource records indicate 805 different times to live). Thus a change in any one of these records 806 may cause inappropriate decisions on communications targets to be 807 made. Given that DNS Update (specified in [RFC2136]) can introduce 808 quite rapid changes in content in different zones, these transient 809 states may become important. 811 Consider a typical set of queries that follow an ENUM query that 812 returns a SIP URI (for details, see [RFC3263]): 814 o Evaluation of the SIP URI triggers a query on the SIP domainpart 815 for D2U/D2T NAPTRs. 816 o This in turn triggers a query on that records's target domain for 817 SRV records. 818 o The SRV records will return the SIP server hostname, which will 819 trigger a further query on that hostname for an A record to get 820 the server's associated IP address. 821 o Finally, the local SIP User Agent Client will then attempt to 822 initiate a communications session to that IP address. 824 The E2U NAPTR may have changed its URI, indicating a new SIP 825 identity. The D2U NAPTR for the SIP URI domainpart may have changed 826 its target. The SRV record pointed to by that D2U NAPTR may have 827 changed its target hostname. The hostname's A record may have 828 changed its IP address. Finally, if the server exists in an 829 environment where IP-addresses are dynamically assigned (for example, 830 when using DHCP [RFC2131]), an unexpected end point may have been 831 allocated to the IP address returned from the SIP resolution chain. 833 In environments where changes to any of the chain of resource records 834 or dynamic assignments to IP addresses occur, those systems 835 provisioning this data SHOULD take care to minimise changes and to 836 consider the respective times to live of resource records and/or DHCP 837 lease times. Users of this data SHOULD take care to detect and 838 recover from unintended communications session attempts; in a 839 transient environment, these may occur. 841 7.3. Call Routing Security 843 There are a number of countries (and other numbering environments) in 844 which there are multiple providers of call routing and number/name- 845 translation services. In these areas, any system that permits users, 846 or putative agents for users, to change routing or supplier 847 information may provide incentives for changes that are actually 848 unauthorized (and, in some cases, for denial of legitimate change 849 requests). Such environments should be designed with adequate 850 mechanisms for identification and authentication of those requesting 851 changes and for authorization of those changes. 853 7.4. URI Resolution Security 855 A large amount of Security Issues have to do with the resolution 856 process itself, and use of the URIs produced by the DDDS mechanism. 857 Those have to be specified in the registration of the Enumservice 858 used, as specified in "IANA Registration of Enumservices: Guide, 859 Template and IANA Considerations" [SV_GUIDE]. 861 8. Acknowledgements 863 This document is an update of RFC 3761, which was edited by Patrik 864 Faltstrom and Michael Mealling. Please see the Acknowledgements 865 section in that RFC for additional acknowledgements. The authors 866 would also like to thank Alfred Hoenes and Bernie Hoeneisen for their 867 detailed reviews. 869 9. Changes from RFC 3761 871 A section has been added to explain the way in which DDDS is used 872 with this specification. These recommendations have been collected 873 from experience of ENUM deployment. Differences of interpretation of 874 the DDDS specifications led to interoperability issues; this document 875 updates RFC 3761 to add many clarifications, intended to ameliorate 876 interoperability. 878 Clarifications include a default value for the ORDER field and for 879 the Regexp delimiter character, required use of Replacement field in 880 non-terminal NAPTRs, and that string matching is case insensitive 881 (Section 3.6). 883 Other substantive changes include removing the discussion of 884 registration mechanisms, (now specified in "IANA Registration of 885 Enumservices: Guide, Template and IANA Considerations" [SV_GUIDE]), 886 correcting an existing error by adding "-" as a valid character in 887 the type and subtype fields specified in Services Parameters 888 (Section 3.4.3) and adding the "P-" private service type 889 (Section 3.4.3.1). 891 9.1. Draft Change Log 893 change log - RFC Editor - please remove this section for publication. 895 version 01 -> 02 896 clean up English - many places 897 removed Registration mechanism for Enumservices section 898 removed IANA considerations - point to draft-ietf-enum-enumservices- 899 guide, 900 replace DNS Security Threats in section 6.1 with pointer to RFC 3833 901 fold in text from the ENUM Experiences ID - many places 903 version 02 -> 03 904 fixed minor typos 905 revised section 2.4.4.1, added P- 906 expanded IANA Considerations - Section 6 908 version 03 -> 04 909 Many changes to bring into sync with RFC 5483 911 version 04 -> 05 912 change "ameliorate" to "mitigate" in 7.1 913 fix reference to IANA Registration of Enumservices 914 clarify ENUM definition of DDDS First Well Known Rule 916 version 05 -> 06 917 fix language in section 2.2 918 add Alfred Hoenes to the acknowledgements section 920 version 06 -> 07 921 major re-structuring, collecting together provisioning and client 922 recommendations into a their own sub-sections within a new section 923 and referring to analysis in RFC 5483 rather than copying text 924 directly 925 corrected typos in the "Collected Implications" items 926 slight rewording of section 1 introductory text and matching abstract 927 rewording in section 1.2 to clarify goal 928 create a separate sub-section for collision avoidance at the end of 929 section 2 (to replace the second paragraph at the start of this 930 specification section). 931 add Bernie Hoeneisen to the acknowledgements section 933 version 07 -> 08 934 Renumbered sections to pull out the old section 1.2 as its own 935 section. 936 Added at end of section 4.1 -- "The informational RFC3824 recommended 937 such support." 938 Changed phrasing of sentence in introduction paragraph 3 to be 939 consistent with abstract and paragraph 1. 940 Corrected spelling in Acknowledgements. 942 version 08 -> 09 943 Response to IESG Evaluation: 944 Correction of error/typo in 3.2 step 3 945 Extensive clarification of 3.6 & addition of MUST requirement 946 Clarification of 5.1 & change of SHOULD to MUST 947 Clarification of 7.1 & SHOULD for service authentication made 948 explicit 949 Extensive clarification of 7.2 & SHOULD actions made explicit 950 Minor clarification text in section 1, section 1.1, 3, 3.2 step 1, 951 3.4, 3.4.2, 3.4.3, and 6. 952 Addition of missing references 953 Slight simplification of IANA section and added ref to RFC3245 955 10. References 957 10.1. Normative References 959 [E.164] ITU-T, "The International Public Telecommunication Number 960 Plan", Recommendation E.164, February 2005. 962 [RFC1034] Mockapetris, P., "Domain names - concepts and 963 facilities", STD 13, RFC 1034, November 1987. 965 [RFC1035] Mockapetris, P., "Domain names - implementation and 966 specification", STD 13, RFC 1035, November 1987. 968 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 969 Part Two: The Algorithm", RFC 3402, October 2002. 971 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 972 Part Three: The Domain Name System (DNS) Database", 973 RFC 3403, October 2002. 975 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 976 Part Four: The Uniform Resource Identifiers (URI)", 977 RFC 3404, October 2002. 979 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 980 for Internationalized Domain Names in Applications 981 (IDNA)", RFC 3492, March 2003. 983 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 984 10646", STD 63, RFC 3629, November 2003. 986 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 987 Resource Identifiers (URI) Dynamic Delegation Discovery 988 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 990 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 991 Resource Identifier (URI): Generic Syntax", STD 66, 992 RFC 3986, January 2005. 994 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 995 Identifiers (IRIs)", RFC 3987, January 2005. 997 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 998 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1000 10.2. Informative References 1002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1003 Requirement Levels", BCP 14, RFC 2119, March 1997. 1005 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1006 RFC 2131, March 1997. 1008 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1009 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1010 RFC 2136, April 1997. 1012 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1013 RFC 2671, August 1999. 1015 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1016 specifying the location of services (DNS SRV)", RFC 2782, 1017 February 2000. 1019 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 1020 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 1022 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, 1023 September 2000. 1025 [RFC3245] Klensin, J. and IAB, "The History and Context of 1026 Telephone Number Mapping (ENUM) Operational Decisions: 1027 Informational Documents Contributed to ITU-T Study Group 1028 2 (SG2)", RFC 3245, March 2002. 1030 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1031 Protocol (SIP): Locating SIP Servers", RFC 3263, 1032 June 2002. 1034 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1035 Part One: The Comprehensive DDDS", RFC 3401, 1036 October 2002. 1038 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1039 (RR) Types", RFC 3597, September 2003. 1041 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 1042 E.164 numbers with the Session Initiation Protocol 1043 (SIP)", RFC 3824, June 2004. 1045 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1046 Name System (DNS)", RFC 3833, August 2004. 1048 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1049 Rose, "DNS Security Introduction and Requirements", 1050 RFC 4033, March 2005. 1052 [RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues 1053 and Experiences", RFC 5483, March 2009. 1055 [SV_GUIDE] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 1056 Registration of Enumservices: Guide, Template and IANA 1057 Considerations", draft-ietf-enum-enumservices-guide (work 1058 in progress), April 2010. 1060 Authors' Addresses 1062 Scott Bradner 1063 Harvard University 1064 29 Oxford St. 1065 Cambridge MA 02138 1066 USA 1068 Phone: +1-617-495-3864 1069 EMail: sob@harvard.edu 1071 Lawrence Conroy 1072 Roke Manor Research 1073 Roke Manor 1074 Old Salisbury Lane 1075 Romsey 1076 United Kingdom 1078 Phone: +44-1794-833666 1079 EMail: lconroy@insensate.co.uk 1080 URI: http://www.sienum.co.uk 1082 Kazunori Fujiwara 1083 Japan Registry Service Co., Ltd. 1084 Chiyoda First Bldg. East 13F 1085 3-8-1 Nishi-Kanda Chiyoda-ku 1086 Tokyo 101-0165 1087 JAPAN 1089 EMail: fujiwara@jprs.co.jp 1090 URI: http://jprs.jp/en/