idnits 2.17.1 draft-ietf-enum-enumservices-guide-22.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3761, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2010) is 4907 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 normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM -- Telephone Number Mapping B. Hoeneisen 3 Working Group Ucom.ch 4 Internet-Draft A. Mayrhofer 5 Obsoletes: 3761 (if approved) enum.at 6 Intended status: Standards Track J. Livingood 7 Expires: April 15, 2011 Comcast 8 October 12, 2010 10 IANA Registration of Enumservices: Guide, Template and IANA 11 Considerations 12 draft-ietf-enum-enumservices-guide-22 14 Abstract 16 This document specifies a revision of the IANA Registration 17 Guidelines for Enumservices, describes corresponding registration 18 procedures, and provides a guideline for creating Enumservice 19 Specifications. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 15, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Registration Requirements . . . . . . . . . . . . . . . . . . 6 72 3.1. Functionality Requirements . . . . . . . . . . . . . . . . 6 73 3.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 6 74 3.3. Security Requirements . . . . . . . . . . . . . . . . . . 7 75 3.4. Publication Requirements . . . . . . . . . . . . . . . . . 8 77 4. Enumservice Creation Cookbook . . . . . . . . . . . . . . . . 8 78 4.1. General Enumservice Considerations . . . . . . . . . . . . 8 79 4.2. Classification, Type and Subtype . . . . . . . . . . . . . 10 80 4.2.1. General Type / Subtype Considerations . . . . . . . . 10 81 4.2.2. Protocol-Based Enumservices Class . . . . . . . . . . 11 82 4.2.3. Application-Based Enumservice Classes . . . . . . . . 11 83 4.2.4. Data Type-Based Enumservice Class . . . . . . . . . . 13 84 4.2.5. Other Enumservice . . . . . . . . . . . . . . . . . . 14 86 5. Required Sections and Information . . . . . . . . . . . . . . 14 87 5.1. Introduction (REQUIRED) . . . . . . . . . . . . . . . . . 14 88 5.2. IANA Registration (REQUIRED) . . . . . . . . . . . . . . . 14 89 5.2.1. Enumservice Class () . . . . . . . . . . . . . 14 90 5.2.2. Enumservice Type () . . . . . . . . . . . . . . 15 91 5.2.3. Enumservice Subtype () . . . . . . . . . . . 15 92 5.2.4. URI Scheme(s) () . . . . . . . . . . . . . 16 93 5.2.5. Functional Specification () . . . . . 16 94 5.2.6. Security Considerations () . . . . . . . . . 16 95 5.2.7. Intended Usage () . . . . . . . . . . . . . . . 17 96 5.2.8. Enumservice Specification () . . . . 17 97 5.2.9. Requesters () . . . . . . . . . . . . . . 18 98 5.2.10. Further Information () . . . . . . . . 18 99 5.3. Examples (REQUIRED) . . . . . . . . . . . . . . . . . . . 18 100 5.4. Implementation Recommendations / Notes (OPTIONAL) . . . . 19 101 5.5. Security Considerations (REQUIRED) . . . . . . . . . . . . 19 102 5.6. IANA Considerations (REQUIRED) . . . . . . . . . . . . . . 20 103 5.7. DNS Considerations (REQUIRED) . . . . . . . . . . . . . . 20 104 5.8. Other Sections (OPTIONAL) . . . . . . . . . . . . . . . . 21 106 6. The Process of Registering New Enumservices . . . . . . . . . 22 107 6.1. Step 1: Read This Document in Detail . . . . . . . . . . . 23 108 6.2. Step 2: Write and Submit Registration Document . . . . . . 23 109 6.3. Step 3: Request Comments From the IETF Community . . . . . 23 110 6.3.1. Outcome 1: No Changes Needed . . . . . . . . . . . . . 23 111 6.3.2. Outcome 2: Changes, But No Further Comments 112 Requested . . . . . . . . . . . . . . . . . . . . . . 23 113 6.3.3. Outcome 3: Changes and Further Comments Requested . . 24 114 6.4. Step 4: Submit Registration Document to IANA . . . . . . . 24 115 6.5. Step 5: Expert Review . . . . . . . . . . . . . . . . . . 25 116 6.5.1. Outcome 1: Experts Approve the Registration 117 Document . . . . . . . . . . . . . . . . . . . . . . . 25 118 6.5.2. Outcome 2: Changes Required . . . . . . . . . . . . . 25 119 6.5.3. Outcome 3: Experts Reject the Registration Document . 26 120 6.6. Step 6: Publication of the Registration Document . . . . . 26 121 6.7. Step 7: Adding Enumservice to IANA Registry . . . . . . . 26 123 7. Expert Review . . . . . . . . . . . . . . . . . . . . . . . . 26 124 7.1. Expert Selection Process . . . . . . . . . . . . . . . . . 26 125 7.2. Review Guidelines . . . . . . . . . . . . . . . . . . . . 27 126 7.3. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 28 128 8. Revision of Existing Enumservice Specifications . . . . . . . 28 130 9. Extension of Existing Enumservice Specifications . . . . . . . 28 132 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 133 10.1. Considerations Regarding This Document . . . . . . . . . . 28 134 10.2. Enumservice Security Considerations Guideline . . . . . . 29 136 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 137 11.1. Registry Update . . . . . . . . . . . . . . . . . . . . . 29 138 11.2. Registration Template (XML chunk) . . . . . . . . . . . . 29 139 11.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31 140 11.4. Structure . . . . . . . . . . . . . . . . . . . . . . . . 31 141 11.5. Expert Review Procedure . . . . . . . . . . . . . . . . . 31 142 11.6. Registration Procedure . . . . . . . . . . . . . . . . . . 32 143 11.6.1. Published as RFC . . . . . . . . . . . . . . . . . . . 32 144 11.6.2. Published as a Non-RFC . . . . . . . . . . . . . . . . 33 145 11.7. Change Control . . . . . . . . . . . . . . . . . . . . . . 33 146 11.8. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 33 148 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 151 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 152 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 154 Appendix A. IANA Registration Template Examples . . . . . . . . . 36 156 Appendix B. Changes from RFC 3761 . . . . . . . . . . . . . . . . 40 158 Appendix C. Document Changelog . . . . . . . . . . . . . . . . . 40 160 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . . 48 162 Appendix E. Notes for the RFC Editor Concerning RFC 3761 . . . . 48 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 166 1. Introduction 168 E.164 Number Mapping (ENUM) [I-D.ietf-enum-3761bis] provides an 169 identifier mapping mechanism to map E.164 numbers [ITU.E164.2005] to 170 Uniform Resource Identifiers (URIs) [RFC3986] using the Domain Name 171 System (DNS) [RFC1035]. One of the primary concepts of ENUM is the 172 definition of "Enumservices", which allows for providing different 173 URIs for different applications of said mapping mechanism. 175 This document specifies a revision of the IANA Registry for 176 Enumservices, which was originally described in [RFC3761]. This 177 document obsoletes Section 3 of RFC 3761. 179 The new registration processes, which is detailed in Section 6, have 180 been specifically designed to be decoupled from the existence of the 181 ENUM working group. Compared to RFC 3761, the main changes are: 183 o For an Enumservice to be inserted to the IANA Registry, 184 "Specification Required", which implies the use of a Designated 185 Expert, according to "Guidelines for Writing an IANA 186 Considerations Section in RFCs" [RFC5226] are now sufficient. 188 o The IANA Registration Template has been supplemented with elements 189 for "Enumservice Class" and "Enumservice Specification". 191 The IETF's ENUM Working Group has encountered an unnecessary amount 192 of variation in the format of Enumservice Specifications. The ENUM 193 Working Group's view of what particular information is required 194 and/or recommended has also evolved, and capturing these best current 195 practices is helpful in both the creation of new Enumservice 196 Specifications, as well as the revision or refinement of existing 197 Enumservice Specifications. 199 2. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 For the purpose of this document: 207 o "Registration Document" refers to a draft specification that 208 defines an Enumservice and proposes its registration following the 209 procedures outlined herein. 211 o "Enumservice Specification" refers to a Registration Document that 212 has been approved by the experts and published according to 213 "Specification Required" as defined in [RFC5226]. 215 3. Registration Requirements 217 As specified in the Augmented Backus-Naur Form (ABNF, [RFC5234]) 218 found in Section 2.4.3 of [I-D.ietf-enum-3761bis], an Enumservice is 219 made up of Types and Subtypes. For any given Type, the allowable 220 Subtypes (if any) must be defined in the Enumservice Specification. 221 There is currently no concept of a registered Subtype outside the 222 scope of a given Type. 224 While the combination of each Type and all of its Subtypes 225 constitutes the allowed values for the "Enumservice" field, it is not 226 sufficient to just list their allowed values. To allow for 227 interoperability, a complete Enumservice Specification MUST document 228 the semantics of the Type and Subtype values to be registered, and 229 MUST contain all sections listed in Section 5 of this document. 231 Furthermore, in order for an Enumservice to be registered, the entire 232 Registration Document requires approval by the experts according to 233 "Specification Required", which implies the use of a Designated 234 Expert, as set out in "Guidelines for Writing an IANA Considerations 235 Section in RFCs" [RFC5226] and Section 7.2 of this document. 237 All Enumservice Specifications are expected to conform also to 238 various requirements laid out in the following sections. 240 3.1. Functionality Requirements 242 A registered Enumservice must be able to function as a selection 243 mechanism for choosing one Naming Authority Pointer (NAPTR) [RFC3403] 244 DNS Resource Record (RR) from a set of such RRs. That means the 245 Enumservice Specification MUST define how to use the NAPTR RR and the 246 URI(s) the NAPTR RR resolves to. 248 Specifically, a registered Enumservice MUST specify the URI Scheme(s) 249 that may be used for the Enumservice, and, when needed, other 250 information that will have to be transferred into the URI resolution 251 process itself. 253 3.2. Naming Requirements 255 The name of an Enumservice MUST be unique in order to be useful as a 256 selection criteria: 258 o The Type MUST be unique. 260 o The Subtype (being dependent on the Type) MUST be unique within a 261 given Type. 263 Types and Subtypes MUST conform to the ABNF specified in Section 264 3.4.3 of [I-D.ietf-enum-3761bis]. 266 The ABNF specified in Section 3.4.3 of [I-D.ietf-enum-3761bis] allows 267 the "-" (dash) character for Types and Subtypes . To avoid confusion 268 with possible future prefixes, a "-" MUST NOT be used as the first 269 nor as the second character of a Type nor a Subtype. Furthermore, a 270 "-" MUST NOT be used as the last character of a Type nor a Subtype. 271 In addition, Types and Subtypes are case insensitive and SHOULD be 272 specified in lowercase letters. 274 Note: The legacy IANA Registry of Enumservices contains Type and 275 Subtype strings with uppercase letters. Implementors could be 276 tempted to refuse handling uppercase Type or Subtype strings, which 277 could negatively affect interoperability. 279 To avoid confusion with Enumservice fields using a deprecated 280 (obsolete) syntax, Type and Subtype MUST NOT start with the string 281 "e2u". 283 The Subtype for one Type MAY have the same identifier as a Subtype 284 for another Type but it is not sufficient to simply reference another 285 Type's Subtype. The functionality of each Subtype MUST be fully 286 specified in the context of the Type being registered. 288 Section 4 contains further naming requirements. 290 3.3. Security Requirements 292 An analysis of security issues is REQUIRED for all registered 293 Enumservices. (This is in accordance with the basic requirements for 294 all IETF protocols.) 296 All descriptions of security issues MUST be as accurate and extensive 297 as feasible. In particular, a statement that there are "no security 298 issues associated with this Enumservice" must not be confused with 299 "the security issues associated with this Enumservice have not been 300 assessed". 302 There is no requirement that an Enumservice must be completely free 303 of security risks. Nevertheless, all known security risks MUST be 304 identified in an Enumservice Specification. 306 Some of the issues to be looked at in a security analysis of an 307 Enumservice are: 309 1. Complex Enumservices may include provisions for directives that 310 institute actions on a user's resources. In many cases provision 311 can be made to specify arbitrary actions in an unrestricted 312 fashion which may then have devastating results (especially if 313 there is a risk for a new ENUM look-up, and because of that an 314 infinite loop in the overall resolution process of the E.164 315 number). 317 2. Complex Enumservices may include provisions for directives that 318 institute actions which, while not directly harmful, may result 319 in disclosure of information that either facilitates a subsequent 320 attack or else violates the users' privacy in some way. 322 3. An Enumservice might be targeted for applications that require 323 some sort of security assurance but do not provide the necessary 324 security mechanisms themselves. For example, an Enumservice 325 could be defined for storage of confidential security services 326 information such as alarm systems or message service passcodes, 327 which in turn require an external confidentiality service. 329 3.4. Publication Requirements 331 Enumservices Specifications MUST be published according to the 332 requirements for "Specification Required" set out in "Guidelines for 333 Writing an IANA Considerations Section in RFCs" [RFC5226]. RFCs 334 fulfill these requirements. Therefore, it is strongly RECOMMENDED to 335 publish Enumservice Specifications as RFCs. 337 In case the Enumservice Specification is not published as an RFC, 338 sufficient information that allows to uniquely identify the 339 Enumservice Specification MUST be provided. 341 4. Enumservice Creation Cookbook 343 4.1. General Enumservice Considerations 345 ENUM is an extremely flexible identifier mapping mechanism, using 346 E.164 (phone) numbers as input identifiers, and returning URIs as 347 output identifiers. Because of this flexibility, almost every use 348 case for ENUM could be implemented in several ways. 350 Section 2 of "Guidelines for Writing an IANA Considerations Section 351 in RFCs" [RFC5226] provides motivation why management of a name space 352 might be necessary. Even though the namespace for Enumservices is 353 rather large (up to 32 alphanumeric characters), there are reasons to 354 manage this in accordance with Section 2 of [RFC5226]. The following 355 is a list of motivations applying to Enumservices: 357 o Prevent hoarding or wasting of values: Enumservice Types are not 358 an opaque identifier to prevent collisions in the namespace, but 359 rather identify the use of a certain technology in the context of 360 ENUM. Service Types might also be displayed to end users in 361 implementations, so meaningful Type strings having a clear 362 relation to the protocols and applications used are strongly 363 RECOMMENDED. Therefore, preventing hoarding, wasting, or 364 "hijacking" of Enumservice Type strings is important. 366 o Sanity check to ensure sensible or necessary requests: This 367 applies to Enumservices, since especially various Enumservices for 368 the same purpose would reduce the chance of successful 369 interoperability, and unnecessarily increase the confusion among 370 implementers. 372 o Delegation of namespace portions: Theoretically, the Type and/or 373 Subtype structure of Enumservices would allow for delegations of 374 Type values, and self-supporting management of Subtype values by a 375 delegate within the Type value. Such delegates could for example 376 be other standardization bodies. However, this would require 377 clear policies regarding publication and use of such Subtypes. 378 Delegation of Enumservice namespace portions is therefore 379 currently not supported. 381 o Interoperability: Since the benefit of an Enumservice rises with 382 the number of supporting clients, the registration and use of 383 several services for a similar or identical purpose clearly 384 reduces interoperability. Operational circumstances suggest to 385 keep the space occupied by all services published in the NAPTR 386 RRSet at any owner in the e164.arpa domain bounded. Registration 387 of nearly identical services and subsequent competing or parallel 388 use could easily increase the DNS operational complexity. 390 Generally, before commencing work on a new Enumservice registration, 391 the following should be considered: 393 o Is there an existing Enumservice that could fulfill the desired 394 functionality without overloading it? Check the IANA Enumservice 395 Registry at . 397 o Is there work in progress, or previous work, on a similar 398 Enumservice? Check the mailing list archives at 399 , and search 400 the Internet-Drafts Archive at . As some 401 Internet-Drafts may have expired and no longer be available in the 402 Internet-Drafts Archive, or some work on Enumservices may have 403 been considered outside the IETF, we recommend also a web search. 405 o Section 4.2 provides three general categories for Enumservice 406 classification. In some cases, there might be several options for 407 designing an Enumservice. For example, a mapping service using 408 HTTP could be considered a "protocol Type" Enumservice (using HTTP 409 as the protocol), while it could also be viewed as an "application 410 Type" Enumservice, with the application being access to mapping 411 services. In such a case where several options are available, 412 defining use cases before commencing work on the Enumservice 413 itself might be useful before making a decision on which aspect of 414 the Enumservice is more important. 416 4.2. Classification, Type and Subtype 418 Because of their flexibility, Enumservices can be and are used in a 419 lot of different ways. This section contains a classification of 420 Enumservices, and provides guidance for choosing suitable Type and 421 Subtype strings for each individual Enumservice Class. 423 The Classification of each Enumservice MUST be listed in the 424 Registration Document (see Section 5.2). If the Enumservice cannot 425 be assigned to one of the classes outlined below, the Registration 426 Document MUST contain a section on the difficulties encountered while 427 trying to classify the service to help the experts in their decision. 429 4.2.1. General Type / Subtype Considerations 431 To avoid confusion, the name of a URI Scheme MUST NOT be used as a 432 Type string for an Enumservice which is not specifically about the 433 respective protocol or URI Scheme. For example, the Type string 434 "imap" would be inadequate for use in an Enumservice about "Internet 435 mapping" services, because it corresponds to an existing URI Scheme / 436 protocol for something different. 438 If Subtypes are defined, the minimum number SHOULD be two (including 439 the empty Subtype, if defined). The choice of just one possible 440 Subtype for a given Type does not add any information when selecting 441 an ENUM record, and hence can be left out completely. However, 442 potential future expansion of a Type towards several Subtypes may 443 justify the use of Subtypes, even in the case just one is currently 444 defined, as noted in Section 9. 446 It is perfectly legal under a certain Type to mix the Enumservice 447 without a Subtype (empty Subtype) with Enumservices containing a 448 Subtype. In that case, however, the Enumservice with an empty 449 Subtype SHOULD be specified to reflect the base service, while the 450 other Enumservices SHOULD be specified to reflect variants. 452 4.2.2. Protocol-Based Enumservices Class 454 Such an Enumservice indicates that an interaction using the named 455 protocol will result for use of this NAPTR. The expected behavior of 456 a system using this Enumservice MUST be clear from the protocol. 458 A good indication that an Enumservice belongs to this Class is the 459 fact that a client does not need to understand the actual application 460 to make use of an instance of this Enumservice. 462 Examples of such Enumservices include "xmpp" [RFC4979] and "sip" 463 [RFC3764]. 465 4.2.2.1. Protocol-Based Enumservice "Type" Strings 467 A protocol-based Enumservice SHOULD use the lowercase name of the 468 protocol as its Type string. Names as registered in the IANA Port 469 Number Registry (, 470 defined in Section 8 and 9 of [RFC2780]) are preferred. 472 4.2.2.2. Protocol-Based Enumservice "Subtype" Strings 474 Where there is a single URI Scheme associated with this protocol, a 475 Subtype SHOULD NOT be specified for the Enumservice. 477 Where there are a number of different URI Schemes associated with 478 this protocol, the Enumservice Specification MAY use the empty 479 Subtype for all URI Schemes that it specifies as mandatory to 480 implement. For each URI Scheme that is not mandatory to implement a 481 distinct Subtype string MUST be used. 483 If Subtypes are defined, it is RECOMMENDED to use the URI Scheme name 484 as the Subtype string. 486 4.2.3. Application-Based Enumservice Classes 488 Application-based Enumservices are used when the kind of service 489 intended is not fully defined by a protocol specification. There are 490 three cases here: 492 o Common Application Enumservice: 494 The application reflects a kind of interaction that can be 495 realized by different protocols, but where the intent of the 496 publisher is the same. From a user's perspective, there is a 497 common kind of interaction - how that interaction is implemented 498 is not important. The Enumservice Specification MUST describe the 499 interaction and expected behavior in enough detail that an 500 implementation can decide if this activity is one in which it can 501 engage. However, it is RECOMMENDED that the Enumservice is 502 defined in a way that will allow others to use it at a later date. 503 An Enumservice that defines a generalized application is preferred 504 to one that has narrow use. 506 An example of this flavor of Enumservice is email. Whilst this 507 might appear to be a "pure" protocol scheme, it is not. The URI 508 Scheme is 'mailto', and does not identify the protocol used by the 509 sender or the recipient to offer or retrieve emails. 511 Another example is SMS, where the existence of such an Enumservice 512 indicates that the publishing entity is capable of engaging in 513 sending or receiving a message according to the Short Messaging 514 Service specifications. The underlying protocol used and the URI 515 Scheme for the addressable end point can differ, but the "user 516 visible" interaction of sending and receiving an SMS is similar. 518 o Subset Enumservice: 520 The application interaction reflects a subset of the interactions 521 possible by use of a protocol. Use of this Enumservice indicates 522 that some options available by use of the protocol will not be 523 accepted or are not possible in this case. Any such Enumservice 524 Specification MUST define the options available by use of this 525 NAPTR in enough detail that an implementation can decide whether 526 or not it can use this Enumservice. Examples of this kind of 527 Enumservice are "voice:tel" and "fax:tel". In both cases the URI 528 holds a telephone number. However, the essential feature of these 529 Enumservices is that the telephone number is capable of receiving 530 a voice call or of receiving a Facsimile transmission, 531 respectively. These form subsets of the interactions capable of 532 using the telephone number, and so have their own Enumservices. 533 These allow an end point to decide if it has the appropriate 534 capability of engaging in the advertised user service (a voice 535 call or sending a fax) rather than just being capable of making a 536 connection to such a destination address. This is especially 537 important where there is no underlying mechanism within the 538 protocol to negotiate a different kind of user interaction. 540 o Ancillary Application Enumservice 542 Another variant on this is the Ancillary Application. This is one 543 in which further processing (potentially using a number of 544 different protocols or methods) is the intended result of using 545 this Enumservice. An example of this kind of application is the 546 "pstn:tel" Enumservice. This indicates that the NAPTR holds 547 Number Portability data. It implies that the client should engage 548 in number portability processing using the associated URI. Note 549 that this Enumservice usually does not itself define the kind of 550 interaction available using the associated URI. That application 551 is negotiated with some other "out of band" means (either through 552 prior negotiation, or explicitly through the number portability 553 process, or through negotiation following the selection of the 554 final destination address). 556 4.2.3.1. Application-Based Enumservice "Type" Strings 558 It is recommended that Application-class Enumservices use the 559 lowercase well known name of the abstract application as Type string. 561 4.2.3.2. Application-Based Enumservice "Subtype" Strings 563 It is RECOMMENDED to use the URI Scheme(s) which the application 564 uses, as Subtype string(s). Subtype strings MAY be shared between 565 URI Schemes, if all the URI Schemes within the same Subtype are 566 mandatory to implement. 568 If it is foreseen that there is only one URI Scheme ever to be used 569 with the application, the empty Subtype string MAY be used. 571 4.2.4. Data Type-Based Enumservice Class 573 "Data Type" Enumservices typically refer to a specific data type or 574 format, which may be addressed using one or more URI Schemes and 575 protocols. Examples of such Enumservices include "vpim" [RFC4238] 576 and "vcard" [RFC4969]. 578 4.2.4.1. Data Type-Based Enumservice "Type" Strings 580 It is recommended to use the lowercase well known name of the data 581 type or format name as the Type string. 583 4.2.4.2. Data Type-Based Enumservice "Subtype" Strings 585 It is RECOMMENDED to use the URI Schemes used to access the service 586 as Subtype strings. Subtype strings MAY be shared between URI 587 Schemes, if all the URI Schemes within the same Subtype are mandatory 588 to implement. 590 If there is only one URI Scheme foreseen to access the data type or 591 format, the empty Subtype string MAY be used. 593 4.2.5. Other Enumservice 595 In case an Enumservice proposal cannot be assigned to any of the 596 classes mentioned above, the element (Enumservice Class) in 597 the IANA Registration Template (see Section 5.2) MUST be populated 598 with "Other". In that case, the Enumservice Specification MUST 599 contain a section elaborating on why the Enumservice does not fit 600 into the classification structure. 602 5. Required Sections and Information 604 There are several sections that MUST appear in an Enumservice 605 Specification. These sections are as follows, and SHOULD be in the 606 given order. 608 The following terms SHOULD begin with a capital letter, whenever they 609 refer to the IANA Registration: 610 o Class 611 o Type 612 o Subtype 613 o URI Scheme 615 5.1. Introduction (REQUIRED) 617 An introductory section MUST be included. This section will explain, 618 in plain English, the purpose and intended use of the proposed 619 Enumservice registration. 621 The Introduction SHOULD start with a short sentence about ENUM, 622 introduce the protocol used in the Enumservice, and discuss the 623 Enumservice as it refers from the E.164 number to the protocol or 624 service. 626 5.2. IANA Registration (REQUIRED) 628 This section MUST be included in an Enumservice Specification. Where 629 a given Enumservice Type has multiple Subtypes, there MUST be a 630 separate "IANA Registration" section for each Subtype. The following 631 lists the elements that are to be used in the XML chunk based 632 Registration Template of an "IANA Registration" section. 634 5.2.1. Enumservice Class () 636 This element contains the Class of the Enumservice as defined in 637 Section 4.2. Its value MUST be one of (without quotes): 639 o "Protocol-Based": The Enumservice belongs to the Protocol-based 640 class as described in Section 4.2.2. 642 o "Application-Based, Common": The Enumservice is a "common" case of 643 the Application-based class as described in Section 4.2.3. 645 o "Application-Based, Subset": The Enumservice belongs to the 646 "subset" case of the Application-based class as described in 647 Section 4.2.3. 649 o "Application-Based, Ancillary": The Enumservice is an "ancillary" 650 case of the Application-based class, as described in 651 Section 4.2.3. 653 o "Data Type-Based": The Enumservice belongs to the Data Type-Based 654 class as described in Section 4.2.4. 656 o "Other": The majority of the functionality of the Enumservice does 657 not fall into one of the classes defined. 659 e.g. Protocol-Based 661 5.2.2. Enumservice Type () 663 The Type of the Enumservice. All Types SHOULD be listed in lower- 664 case. The choice of Type depends on the Enumservice Class. Please 665 find further instructions in Section 4. 667 e.g. foo 669 5.2.3. Enumservice Subtype () 671 The Subtype of the Enumservice. All Subtypes SHOULD be listed in 672 lower-case. The choice of Subtype depends on the Enumservice Class. 673 Should the Enumservice not utilize a Subtype, then the 674 element MUST be omitted in the IANA Registration Template. If a 675 given Enumservice Type has multiple Subtypes, then there MUST be a 676 separate IANA Registration Template for each Subtype. Please find 677 further instructions in Section 4. 679 e.g. bar 681 5.2.4. URI Scheme(s) () 683 The URI Schemes [RFC3986] that are used with the Enumservice. The 684 selection of URI Schemes often depends on the Enumservice Class, 685 Type, and/or Subtype. A colon MUST NOT be placed after the URI 686 Scheme name. If there is more than one URI Scheme, then one 687 element per URI scheme MUST be used in the IANA 688 Registration Template. Please find further instructions in 689 Section 4. 691 e.g. bar 692 sbar 694 Note: A client cannot choose a specific ENUM record in a record set 695 based on the URI Scheme - the selection is only based on Type and 696 Subtype, in accordance with [RFC3402]. 698 5.2.5. Functional Specification () 700 The Functional Specification describes how the Enumservice is used in 701 connection with the URI to which it resolves. 703 e.g. 704 705 This Enumservice indicates that the resource 706 identified can be addressed by the associated 707 URI in order to foo the bar. 708 709 710 [...] 711 712 714 Where the terms used are non-obvious, they should be defined in the 715 Enumservice Specification, or a reference to an external document 716 containing their definition should be provided. 718 5.2.6. Security Considerations () 720 A reference to the "Security Considerations" section of a given 721 Enumservice Specification. 723 e.g. 724 See , Section 6. 725 727 5.2.7. Intended Usage () 729 One of the following values (without quotes): 731 o "COMMON": Indicates that the Enumservice is intended for 732 widespread use on the public Internet, and that its scope is not 733 limited to a certain environment. 735 o "LIMITED USE": Indicates that the Enumservice is intended for use 736 on a limited scope, for example in private ENUM-like application 737 scenarios. The use case provided in the Enumservice Specification 738 should describe such a scenario. 740 o "DEPRECATED": Indicates that the Enumservice has been declared 741 deprecated (Section 11.7) and is not to be used in new 742 deployments. Applications SHOULD however expect to encounter 743 legacy instances of this Enumservice. 745 e.g. COMMON 747 5.2.8. Enumservice Specification () 749 Reference(s) to the Document(s) containing the Enumservice 750 Specification. 752 e.g. 753 754 756 e.g. 757 (obsoleted by RFC 2551) 758 759 761 e.g. 762 [International Telecommunications Union, 763 "Enumservice Specification for Foobar", 764 ITU-F Recommendation B.193, Release 73, Mar 2009.] 766 768 5.2.9. Requesters () 770 The persons requesting the registration of the Enumservice. Usually 771 these are the authors of the Enumservice specification. 773 e.g. 774 775 777 [...] 779 780 781 John Doe 782 ACME Research and Development Inc. 783 mailto:jd@acme.example.com 784 2008-11-20 785 786 788 If there is more than one requester, there MUST be one element 789 per requester in the element, and one chunk per 790 requester in the element. 792 5.2.10. Further Information () 794 Any other information the authors deem interesting, including 795 artwork. 797 e.g. 798 more info goes here 799 801 Note: If there is no such additional information, then the 802 element is omitted. 804 5.3. Examples (REQUIRED) 806 This section MUST show at least one example of the Enumservice being 807 registered, for illustrative purposes. The example(s) shall in no 808 way limit the various forms that a given Enumservice may take, and 809 this should be noted at the beginning of this section of the 810 document. The example(s) MUST show the specific formatting of the 811 intended NAPTRs (according to [RFC3403] and [I-D.ietf-enum-3761bis]), 812 including one or more NAPTR example(s), AND a brief textual 813 description, consisting of one or more sentences written in plain 814 English, explaining the various parts or attributes of the record(s). 816 The example(s) SHOULD contain a brief description how a client 817 supporting this Enumservice could behave, if that description was not 818 already given in e.g. the Introduction or the Functional 819 Specification. 821 The example(s) SHOULD follow any relevant IETF guidelines on the use 822 of domain names, phone numbers, and other resource identifier 823 examples, such as [RFC2606]. 825 e.g. 826 $ORIGIN 9.7.8.0.6.9.2.3.6.1.4.4.e164.arpa. 827 @ IN NAPTR 100 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" . 829 5.4. Implementation Recommendations / Notes (OPTIONAL) 831 Recommendations that pertain to implementation and/or operations 832 SHOULD be included. Such a section is helpful to someone reading an 833 Enumservice Specification and trying to understand how best to use it 834 to support their network or service. 836 5.5. Security Considerations (REQUIRED) 838 A section explaining any potential security threats which are 839 especially applicable to the given registration MUST be included. 840 This MUST also include any information about access to Personally 841 Identifiable Information (PII). 843 An Enumservice Specification SHOULD NOT include general and obvious 844 security recommendations, such as securing servers with strong 845 password authentication. 847 For additional background, please note that [RFC3552] provides 848 guidance to write a good Security Considerations section. In 849 addition, [I-D.ietf-enum-3761bis] already outlines security 850 considerations affecting ENUM as a whole. Enumservice Specifications 851 do not need to and SHOULD NOT repeat considerations already listed in 852 that document. However, Enumservice Specifications SHOULD include a 853 reference to that section. 855 Also, ENUM refers to resources using existing URI Schemes and 856 protocols. Enumservice Specifications do not need to and SHOULD NOT 857 repeat security considerations affecting those protocols and URI 858 Schemes themselves. 860 However, in some cases, the inclusion of those protocols and URI 861 Schemes into ENUM specifically could introduce new security issues. 862 In these cases, those issues or risks MUST be covered in the 863 "Security Considerations" section of the Enumservice Specification. 864 Authors should pay particular attention to any indirect risks that 865 are associated with a proposed Enumservice, including cases where the 866 proposed Enumservice could lead to the discovery or disclosure of 867 Personally Identifiable Information (PII). 869 5.6. IANA Considerations (REQUIRED) 871 Describe the task IANA needs to fulfill processing the Enumservice 872 Registration Document. 874 e.g. 875 This document requests the IANA registration of the Enumservice with 876 Type "foo" and Subtype "bar" according to the definitions in this 877 document, RFC XXXX [Note for RFC Editor: Please replace XXXX with the 878 RFC number of this document before publication] and 879 [I-D.ietf-enum-3761bis]. 881 e.g. 882 This document requests an update of the IANA registration of the 883 Enumservice Type "foo" with Subtype "bar", according to the 884 definitions in this document, RFC XXXX [Note for RFC Editor: Please 885 replace XXXX with the RFC number of this document before publication] 886 and [I-D.ietf-enum-3761bis]. Therefore, in the existing IANA 887 registration for this Enumservice, the element 888 (Enumservice Specification) is enhanced by adding a supplementary 889 reference that points to this document. 891 e.g. 892 This document requests an update of the IANA registration of the 893 Enumservice Type "foo" with all its Subtypes, in order to declare it 894 deprecated. Therefore, in the existing IANA registration for this 895 Enumservice, the element (Intended Usage) is changed to 896 "DEPRECATED", and the element (Enumservice 897 Specification) is enhanced by adding a supplementary reference that 898 points to this document. 900 5.7. DNS Considerations (REQUIRED) 902 In case the inclusion of protocols and URI Schemes into ENUM 903 specifically introduces new DNS issues, those MUST be described 904 within this section. 906 Such DNS issues include, but are not limited to: 908 o Assumptions about ownership or administrative control of the 909 namespace. 911 o Requirement or need to use DNS wildcards. 913 o Incompatibility with DNS wildcards. 915 o Presence or absence of respective NAPTR Resource Records at 916 particular levels in the DNS hierarchy (e.g. only for "full" E.164 917 numbers, or wildcards only). 919 o Use of any Resource Records (especially non-NAPTR) within or 920 beyond the e164.arpa namespace other than those needed to resolve 921 the domain names that appear in the "replacement" URI. 923 o Potential for significant additional load on the nameserver chain 924 due to use of the service, and the mitigation of such additional 925 load. 927 o Mitigation of potential for DNS loops, specifically in cases where 928 the result URI of an Enumservice might be used to trigger 929 additional (subsequent) ENUM queries. This applies in particular 930 to Enumservices using the 'tel' URI scheme [RFC3966] or any other 931 (future) URI scheme using (E.164) numbers. The "ENUM Dip 932 Indicator Parameter for the 'tel' URI scheme" [RFC4759] provides 933 an example of a loop mitigation mechanism. 935 Rationale: some Enumservices try to exploit side effects of the DNS 936 that need to be explicitly discussed. 938 5.8. Other Sections (OPTIONAL) 940 Other sections beyond those required above MAY be included in an 941 Enumservice Specification. These sections may relate to the 942 specifics of the intended use of the Enumservice registration, as 943 well as to any associated technical, operational, administrative, or 944 other concerns. 946 A use case SHOULD be included by the authors of the proposal, so that 947 experts can better understand the problem the proposal seeks to solve 948 (intended use of the Enumservice). The inclusion of such a use case 949 will both accelerate the Expert Review process, as well as make any 950 eventual registration easier to understand and implement by other 951 parties. 953 6. The Process of Registering New Enumservices 955 This section is an illustration of the process by which a new 956 Enumservice Registration Document is submitted for review and 957 comment, how such proposed Enumservices are reviewed, and how they 958 are published. This section is a non-normative description of the 959 process. The normative process is described in [RFC5226]. 961 Figure 1 shows what authors of a Registration Document describing an 962 Enumservice must carry out before said Registration Document can be 963 formally submitted to IANA for Expert Review. Figure 2 shows the 964 process from Expert Review onwards. 966 +----------------------------+ 967 | Step 1: Read this document | 968 +----------------------------+ 969 | 970 V 971 +-------------------------------+ 972 | Step 2: Write R-D and submit | 973 +-------------------------------+ 974 | 975 V 976 +--------------------------------------------+ 977 | Step 3: Announce R-D and solicit feedback |<--+ 978 +--------------------------------------------+ | 979 | | 980 V | 981 .^. | 982 . . | 983 +------------+ . Feed- . +------------+ 984 | Update R-D |<---------< back >------------>| Update R-D | 985 | and submit | non-sub- . results . substantial | and submit | 986 +------------+ stantial . in: . changes +------------+ 987 | changes . . needed 988 | needed Y 989 | | no changes needed 990 | V 991 | +-----------------------------+ 992 +-------->| Step 4: Submit R-D to IANA | 993 +-----------------------------+ 994 : 995 : 996 V 998 R-D: Registration Document 1000 Figure 1 1002 6.1. Step 1: Read This Document in Detail 1004 This document, particularly in Sections 3, 4, and 5, describes all of 1005 the recommended and required sections, as well as requirements and 1006 suggestions for content of an Enumservice Specification. 1008 6.2. Step 2: Write and Submit Registration Document 1010 An Internet-Draft (or another specification as appropriate) must be 1011 written and made publicly available (submitted). The Registration 1012 Document shall follow the guidelines according to Sections 4 and 5 of 1013 this document. The Review Guidelines for experts are defined in 1014 Section 7.2. 1016 6.3. Step 3: Request Comments From the IETF Community 1018 The authors shall send an email to , in which comments 1019 on the Registration Document are requested. A proper public 1020 reference (a URL is recommended) to the Registration Document must be 1021 included in this email. 1023 Note: The ENUM WG mailing list will be kept open 1024 after conclusion of the ENUM WG. 1026 The authors should allow a reasonable period of time to elapse, such 1027 as two to four weeks, in order to collect any feedback. The authors 1028 then consider whether or not to take any of those comments into 1029 account, by making changes to the Registration Document and 1030 submitting a revision, or otherwise proceeding. The following 1031 outcomes are open to the authors. The choice of path is left to the 1032 authors' judgement. 1034 Note: Whatever the outcome is, the experts performing the Expert 1035 Review later in the processs are not bound to any decision during 1036 this phase. 1038 6.3.1. Outcome 1: No Changes Needed 1040 No changes to the Registration Document are made, and the authors 1041 proceed to Step 4 below. 1043 This outcome is recommended when the feedback received does not lead 1044 to a new revision of the Registration Document. 1046 6.3.2. Outcome 2: Changes, But No Further Comments Requested 1048 The authors update the Registration Document and is/are confident 1049 that all issues are resolved and do not require further discussion. 1051 The authors proceed to Step 4 below. 1053 This outcome is recommended when minor objections have been raised, 1054 or minor changes have been suggested. 1056 6.3.3. Outcome 3: Changes and Further Comments Requested 1058 The authors update and submit the Registration Document, and proceed 1059 to Step 3 above, which involves sending another email to 1060 to request additional comments for the updated 1061 version. 1063 This outcome is recommended when substantial objections have been 1064 raised, or substantial changes have been suggested. 1066 6.4. Step 4: Submit Registration Document to IANA 1068 The authors submit the Registration Document to IANA (using the 1069 website) for Expert Review. 1071 : 1072 : 1073 V 1074 +-----------------------+ 1075 | Step 5: Expert Review |<-------------+ 1076 +-----------------------+ | 1077 | | 1078 V | 1079 .^. | 1080 . . | 1081 .---------. . Expert . +------------+ 1082 ( Bad luck! )<-------- < Review >------------>| Update R-D | 1083 `---------' experts . results . changes | and submit | 1084 reject . in: . required +------------+ 1085 . . 1086 Y 1087 | experts approve 1088 V 1089 +-----------------------------------+ 1090 | Step 6: Publication of R-D | 1091 +-----------------------------------+ 1092 | 1093 V 1094 +---------------------------------------------+ 1095 | Step 7: Adding Enumservice to IANA Registry | 1096 +---------------------------------------------+ 1098 R-D: Registration Document 1100 Figure 2 1102 6.5. Step 5: Expert Review 1104 IANA will take care of the "Expert Review" according to [RFC5226]. 1105 The Expert Review guidelines are outlined in Section 7.2 of this 1106 document. The authors must be prepared for further interaction with 1107 IANA and the experts. 1109 6.5.1. Outcome 1: Experts Approve the Registration Document 1111 No (more) changes to the Registration Document are made. IANA will 1112 inform the authors, who then will proceed to Step 6 below. 1114 6.5.2. Outcome 2: Changes Required 1116 The experts might require changes before they can approve the 1117 Registration Document. The authors update and submit the 1118 Registration Document. The authors inform the experts about the 1119 available update, who then continue the Expert Review Process. 1121 6.5.3. Outcome 3: Experts Reject the Registration Document 1123 The expert might reject the Registration, which means the Expert 1124 Review process is discontinued. 1126 6.6. Step 6: Publication of the Registration Document 1128 The authors are responsible that the Registration Document is 1129 published according to "Specification Required" as defined in 1130 [RFC5226]. 1132 As set out in Section 3.4 it is strongly recommended to publish 1133 Enumservice Specifications as RFCs. As to every RFC the normal IETF 1134 publication process applies (see [Instructions2authors]); i.e. the 1135 Registration Document is submitted in the form of an Internet Draft 1136 (e.g. via an IETF Working Group or a sponsoring Area Director). 1137 [Instructions2authors] also contains an option to publish an RFC as 1138 'Independent Submission', which is further described in "Independent 1139 Submissions to the RFC Editor" [RFC4846]. 1141 6.7. Step 7: Adding Enumservice to IANA Registry 1143 In case the Registration Document is to be published as an RFC, the 1144 RFC publication process ensures that IANA will add the Enumservice to 1145 the Registry. 1147 In case the Registration Document is to be published in a 1148 specification other than RFC, the authors must inform IANA, as soon 1149 as the Enumservice Specification has been published according to 1150 "Specification Required" as defined in [RFC5226]. The 1151 element in the IANA Registration Template must 1152 contain an unambiguous reference to the Enumservice Specification 1153 (see also Section 5.2). In addition, the authors must provide IANA 1154 with a stable URL to the Enumservice Specification, in order that 1155 IANA may obtain the information included in the Enumservice 1156 Specification. IANA will then add the Enumservice to the Registry. 1158 7. Expert Review 1160 7.1. Expert Selection Process 1162 According to Section 3.2 of [RFC5226], experts are appointed by the 1163 IESG. The IESG is responsible for ensuring that there is always a 1164 sufficient pool of experts available. 1166 7.2. Review Guidelines 1168 Generally, the "Expert Review" process of an Enumservice follows the 1169 guidelines documented in Section 3.3 of "Guidelines for Writing an 1170 IANA Considerations Section in RFCs" [RFC5226]. Note that RFC 5226 1171 says 'The review may be wide or narrow, depending on the situation 1172 and the judgment of the designated expert'. Therefore, the following 1173 list should be considered a guideline, rather than a binding list. 1175 In case of conflicts between [RFC5226] and the guidelines in this 1176 section, [RFC5226] remains authoritative. 1178 The expert evaluates the criterion as set out in [RFC5226], and 1179 should additionally consider the following: 1181 o Verify conformance with the ENUM specification 1182 [I-D.ietf-enum-3761bis]. 1184 o Verify that the requirements set out in this document (Sections 3 1185 and 5) are met. This includes check for completeness and whether 1186 all the aspects described in Sections 3 and 5 are sufficiently 1187 addressed. 1189 o If a use case is provided, the experts should verify whether the 1190 proposed Enumservice does actually match the use case. The 1191 experts should also determine whether the use case could be 1192 covered by an existing Enumservice. 1194 o Verify that the Enumservice proposed cannot be confused with 1195 identical (or similar) other Enumservices already registered. 1197 o If the Enumservice is classified according to Section 4.2, the 1198 experts must verify that the principles of the Class in question 1199 are followed. 1201 o In case the Enumservice is not classified, the experts must verify 1202 whether a convincing reason for the deviation is provided in the 1203 Registration Document. 1205 o Investigate whether the proposed Enumservice has any negative side 1206 effects on existing clients and infrastructure, particularly the 1207 DNS. 1209 o If the output of processing an Enumservice might be used for input 1210 to more ENUM processing (especially services returning 'tel' 1211 URIs), the experts should verify that the authors have adequately 1212 addressed the issue of potential query loops. 1214 7.3. Appeals 1216 Appeals of Expert Review decisions follow the process described in 1217 section 7 of [RFC5226] and section 6.5 of [RFC2026]. 1219 8. Revision of Existing Enumservice Specifications 1221 Many Enumservice Registrations, published via IETF RFCs, already 1222 exist at the time of the development of this document. These 1223 existing Enumservice Specifications MAY be revised to comply with the 1224 specifications contained herein. All revisions of Enumservice 1225 Specifications MUST be compliant with the specifications contained 1226 herein. 1228 Note: Enumservice Specifications updated only by 1229 [I-D.ietf-enum-enumservices-transition] are not compliant with the 1230 specifications contained herein! 1232 9. Extension of Existing Enumservice Specifications 1234 There are cases where it is more sensible to extend an existing 1235 Enumservice registration rather than proposing a new one. Such cases 1236 include adding a new Subtype to an existing Type. Depending on the 1237 nature of the extension, the original Enumservice Specification needs 1238 to be extended (Updates) or replaced (Obsoletes) [RFC2223]. 1239 Specifically, an update is appropriate when a new Subtype is being 1240 added without changes to the existing repertoire. A replacement is 1241 needed if there is a change to the default, or changes to the 1242 assumptions of URI support in clients. 1244 Any Enumservice Specifications for existing Enumservices that are 1245 extended MUST comply with the specifications contained herein. As a 1246 consequence, revisions of existing Enumservice Specifications 1247 according to Section 8 may be required. 1249 10. Security Considerations 1251 10.1. Considerations Regarding This Document 1253 Since this document does not introduce any new technology, protocol, 1254 or Enumservice Specification, there are no specific security issues 1255 to be considered for this document. However, as this is a guide to 1256 authors of new Enumservice Specifications, the next section should be 1257 considered closely by authors and experts. 1259 10.2. Enumservice Security Considerations Guideline 1261 Guidelines concerning the Security Considerations section of an 1262 Enumservice Specification can be found in Section 5.5. 1264 11. IANA Considerations 1266 11.1. Registry Update 1268 IANA will update the Registry "Enumservice Registrations" as defined 1269 in (this) Section 11, which will replace the old mechanism as defined 1270 in RFC 3761 [RFC3761]. 1272 It is noted that the process described herein applies only to 1273 ordinary Enumservice registrations (i.e. the registration process of 1274 "X-" Enumservices is beyond the scope of this document, and as per 1275 [I-D.ietf-enum-3761bis] "P-" Enumservices will not be registered at 1276 all). 1278 11.2. Registration Template (XML chunk) 1279 1280 1281 1282 1283 1284 1285 1286 1287 1289 1290 1291 1292 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1309 1310 1311 1312 :-) 1313 1314 1315 1317 1318 1319 1320 1321 1322 1323 1324 1325 1327 Authors of Enumservice Specification are encouraged to use these XML 1328 chunks as a template to create the IANA Registration Template. 1329 Examples for the use of this template are contained in Appendix A. 1331 11.3. Location 1333 Approved Enumservice registrations are published in the IANA Registry 1334 named "Enumservice Registrations", which is available at the 1335 following URI: 1336 < http://www.iana.org/assignments/enum-services >. 1338 This Registry publishes representations derived from the IANA 1339 Registration Template as described in Section 11.2 and specified in 1340 Section 5.2. 1342 Where the Enumservice Specification is not an RFC, IANA must hold an 1343 escrow copy of that Enumservice Specification. Said escrow copy will 1344 act as the master reference for that Enumservice Registration. 1346 11.4. Structure 1348 IANA maintains the Enumservice Registry sorted in alphabetical order. 1349 The first sort field is Type, the second is Subtype. 1351 Each Enumservice starts with a caption, which is composed of Type and 1352 Subtype, separated by a colon; e.g. if the Type is "foo" and the 1353 Subtype "bar", the resulting caption is "foo:bar". 1355 [I-D.ietf-enum-enumservices-transition] updates the existing 1356 Enumservices by transforming them into the new XML chunk based IANA 1357 Registration Template (see also Section 8). 1359 11.5. Expert Review Procedure 1361 Whenever a Registration Document is submitted via the IANA website, 1362 IANA will take care of the "Expert Review" process according to 1363 "Guidelines for Writing an IANA Considerations Section in RFCs" 1364 [RFC5226]. 1366 To prevent clashes IANA will check whether a request with identical 1367 "type:subtype" (or "type" without Subtype) was submitted for Expert 1368 Review earlier and will inform the experts accordingly. The experts 1369 are authorized to resolve clashes as they see fit. The requesters 1370 may need to update their registration request before getting expert 1371 approval. 1373 Once the experts have conditionally approved the Enumservice, IANA 1374 will inform the authors. This information should also include a 1375 reminder that (i) the authors are now responsible for publication of 1376 the Registration Document (see also Section 6.6) and (ii) the 1377 Enumservice will be added to the IANA Registry only after its 1378 Enumservice Specification is published according to the 1379 "Specification Required" policy as defined in [RFC5226] (see also 1380 Section 6.7). 1382 Note: After sending the approval note to the authors, IANA has no 1383 further responsibilities besides keeping internal records of approved 1384 Registration Documents. IANA will be involved again at registration 1385 of the Enumservice (see Section 11.6). 1387 11.6. Registration Procedure 1389 There is a slight difference in process depending on whether or not 1390 the Enumservice Specification will be published as an RFC. The 1391 reason for this difference lies in the current RFC publication 1392 process that includes IANA interaction shortly before publication of 1393 an RFC. 1395 11.6.1. Published as RFC 1397 As per the RFC publication process IANA will receive the Enumservice 1398 Specification to carry out IANA actions shortly before publication of 1399 the RFC. The IANA action will be to register the Enumservice, i.e. 1400 add the Enumservice to the IANA "Enumservice Registrations" Registry 1401 (see also Section 11.3). 1403 IANA must only add Enumservices to the Registry, if the experts have 1404 approved the corresponding Enumservice Specification as to be 1405 published. IANA should attempt to resolve possible conflicts arising 1406 from this together with the experts. In case changes between the 1407 (conditionally) approved and the to be published version are 1408 substantial, IANA may reject the request after consulting the 1409 experts. 1411 IANA must ensure that any further substantial changes the Enumservice 1412 Specification might undergo before final RFC publication are approved 1413 by the experts. 1415 Note: Clearly editorial changes (such as typos) or minor changes in 1416 purely editorial sections (such as Authors' Addresses, 1417 Acknowledgments, References, and alike) are not considered 1418 substantial. 1420 11.6.2. Published as a Non-RFC 1422 Once the authors have informed IANA about the publication, IANA must 1423 ensure that the requirements to "Specification Required" as defined 1424 in [RFC5226] are met, the reference to the specification is 1425 unambiguous, and the content of the Enumservice Specification is 1426 identical to the Registration Document as approved by the experts. 1427 IANA will then register the Enumservice, i.e. add the Enumservice to 1428 the IANA "Enumservice Registrations" Registry, and make an escrow 1429 copy (see also Section 11.3). 1431 IANA must only add Enumservices to the Registry, if the experts have 1432 approved the corresponding Enumservice Specification as published. 1433 IANA should attempt to resolve possible conflicts arising from this 1434 together with the experts. In case changes between the approved and 1435 the published version are substantial, IANA may reject the request 1436 after consulting the experts. 1438 Note: Clearly editorial changes (such as typos) or minor changes in 1439 purely editorial sections (such as Authors' Addresses, 1440 Acknowledgments, References, and alike) are not considered 1441 substantial. 1443 11.7. Change Control 1445 Change control of any Enumservice Registrations is done by 1446 "Specification Required", which implies the use of a Designated 1447 Expert, according to [RFC5226]. Updates of Enumservice 1448 Specifications MUST comply with the requirements described in this 1449 document. Updates are handled the same way as initial Enumservice 1450 Registrations. 1452 Authorized Change Controllers are the experts and the IESG. 1454 Enumservice registrations must not be deleted. An Enumservice that 1455 is believed no longer appropriate for use can be declared deprecated 1456 by publication of a new Enumservice Specification changing its 1457 element (Intended Usage) to "DEPRECATED"; such Enumservices 1458 will be clearly marked in the lists published by IANA. As 1459 obsoletions are updates, they are also handled the same way as 1460 initial Enumservice Registrations. Alternatively, Enumservices may 1461 be declared deprecated by an IESG action. 1463 11.8. Restrictions 1465 As stated in Section 3.2, a "-" (dash) MUST NOT be used as the first 1466 nor as the second nor as the last character of a Type nor a Subtype. 1467 Furthermore, Type nor Subtype of any Enumservice MUST NOT be set to 1468 nor start with "E2U". Any Enumservice registration requests not 1469 following these restrictions must be rejected by IANA, and the Expert 1470 Review process should not be initiated. 1472 Section 5.2 contains examples for Enumservice registrations. 1473 Therefore, IANA must not register an Enumservice with Type or Subtype 1474 set to "foo", "bar", or "sbar", unless the experts explicitly confirm 1475 an exception. 1477 12. Acknowledgments 1479 The authors would like to thank the following people who have 1480 provided feedback or significant contributions to the development of 1481 this document: Jari Arkko, Stewart Bryant, Gonzalo Camarillo, 1482 Lawrence Conroy, Michelle Cotton, Miguel Garcia, David Harrington, 1483 Alfred Hoenes, Ari Keranen, Peter Koch, Edward Lewis, Alexey 1484 Melnikov, Jon Peterson, Pekka Savola, and Peter Saint-Andre 1486 Lawrence Conroy has provided extensive text for the Enumservice 1487 Classification section. 1489 Section 3 of RFC 3761 [RFC3761], which was edited by Patrik Faltstrom 1490 and Michael Mealling, has been incorporated into this document. 1491 Please see the Acknowledgments section in RFC 3761 for additional 1492 acknowledgments. 1494 13. References 1496 13.1. Normative References 1498 [I-D.ietf-enum-3761bis] 1499 Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1500 Uniform Resource Identifiers (URI) Dynamic Delegation 1501 Discovery System (DDDS) Application (ENUM)", 1502 draft-ietf-enum-3761bis-09 (work in progress), June 2010. 1504 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1505 Resource Identifiers (URI) Dynamic Delegation Discovery 1506 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1508 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1509 3", BCP 9, RFC 2026, October 1996. 1511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1512 Requirement Levels", BCP 14, RFC 2119, March 1997. 1514 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1515 Part Two: The Algorithm", RFC 3402, October 2002. 1517 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1518 Part Three: The Domain Name System (DNS) Database", 1519 RFC 3403, October 2002. 1521 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1522 Resource Identifier (URI): Generic Syntax", STD 66, 1523 RFC 3986, January 2005. 1525 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1526 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1527 May 2008. 1529 13.2. Informative References 1531 [I-D.ietf-enum-enumservices-transition] 1532 Hoeneisen, B. and A. Mayrhofer, "Update of legacy IANA 1533 Registrations of Enumservices", 1534 draft-ietf-enum-enumservices-transition-06 (work in 1535 progress), July 2010. 1537 [RFC1035] Mockapetris, P., "Domain names - implementation and 1538 specification", STD 13, RFC 1035, November 1987. 1540 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 1541 RFC 2223, October 1997. 1543 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1544 Values In the Internet Protocol and Related Headers", 1545 BCP 37, RFC 2780, March 2000. 1547 [Instructions2authors] 1548 Reynolds, J. and R. Braden, "Instructions to Request for 1549 Comments (RFC) Authors", RFC Editor http:// 1550 www.rfc-editor.org/rfc-editor/instructions2authors.txt, 1551 August 2004. 1553 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 1554 Names", BCP 32, RFC 2606, June 1999. 1556 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1557 Text on Security Considerations", BCP 72, RFC 3552, 1558 July 2003. 1560 [RFC3764] Peterson, J., "enumservice registration for Session 1561 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 1562 April 2004. 1564 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1565 RFC 3966, December 2004. 1567 [RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, 1568 October 2005. 1570 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1571 Indicator Parameter for the "tel" URI", RFC 4759, 1572 December 2006. 1574 [RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the 1575 RFC Editor", RFC 4846, July 2007. 1577 [RFC4969] Mayrhofer, A., "IANA Registration for vCard Enumservice", 1578 RFC 4969, August 2007. 1580 [RFC4979] Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'", 1581 RFC 4979, August 2007. 1583 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1584 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1586 [ITU.E164.2005] 1587 International Telecommunications Union, "The International 1588 Public Telecommunication Numbering Plan", ITU- 1589 T Recommendation E.164, Feb 2005. 1591 Appendix A. IANA Registration Template Examples 1593 This section contains non-normative examples of the XML chunk based 1594 IANA Registration Template: 1596 This is the first example: 1598 1599 Protocol-Based 1600 email 1601 mailto 1602 mailto 1603 1604 1605 This Enumservice indicates that the resource 1606 can be addressed by the associated URI in 1607 order to send an email. 1608 1609 1610 1611 See , Section 6. 1612 1613 COMMON 1614 1615 1616 1617 1618 1619 1620 1622 1623 1624 Lawrence Conroy 1625 Siemens Roke Manor Research 1626 mailto:lwc@roke.co.uk 1627 2008-11-20 1628 1629 1631 This is the second example. 1633 1634 Protocol-Based 1635 xmpp 1636 xmpp 1637 1638 1639 This Enumservice indicates that the 1640 resource identified is an XMPP entity. 1641 1642 1643 1644 See , Section 6. 1645 1646 COMMON 1647 1648 1649 1650 1651 1652 1653 1655 1656 1657 Alexander Mayrhofer 1658 enum.at GmbH 1659 mailto:alexander.mayrhofer@enum.at 1660 2008-10-10 1661 1662 1664 This is the third example: 1666 1667 Application-Based 1668 voicemsg 1669 sip 1670 sip 1671 1672 1673 This Enumservice indicates that the resource 1674 identified can be addressed by the associated 1675 URI scheme in order to initiate a voice 1676 communication session to a voice messaging system. 1677 1678 1679 1680 See , Section 3. 1681 1682 COMMON 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 Implementers should review a non-exclusive list of 1693 examples in , 1694 Section 7. 1695 1696 1697 1699 1700 1701 Jason Livingood 1702 Comcast Cable Communications 1703 mailto:jason_livingood@cable.comcast.com 1704 2008-11-20 1705 1706 1707 Donald Troshynski 1708 Acme Packet 1709 mailto:dtroshynski@acmepacket.com 1710 2008-11-20 1711 1712 1714 Note: The "voicemsg" Enumservice has several Subtypes. For each 1715 Subtype, an individual Registration Template must be submitted to 1716 IANA, with only the first one shown above. This is to avoid any 1717 ambiguity of the relation between and elements. 1719 Appendix B. Changes from RFC 3761 1721 This section lists the changes applied to the Enumservice 1722 registration process and the IANA Registry definition, compared to 1723 RFC 3761. 1725 o While RFC 3761 required "Standards track or Experimental" RFCs for 1726 an Enumservice to be registered, this document mandates 1727 "Specification Required", which implies the use of a Designated 1728 Expert. 1730 o This document defines the classification of Enumservices. The 1731 IANA Registration Template has been complemented to contain a 1732 element (Enumservice Class). 1734 o A new element (Enumservice Specification) has 1735 been added to the IANA Registration Template. 1737 o The former field "Any other information that the author deems 1738 interesting" of the IANA Registration Template turned into the 1739 element (Further Information). 1741 o The Enumservice "Name" field has been removed from the IANA 1742 Registration Template. 1744 o The Registration Template is now a chunk of XML data, reflecting 1745 IANA's recent work to convert registries to XML. 1747 Appendix C. Document Changelog 1749 [RFC Editor: This section is to be removed before publication] 1751 draft-ietf-enum-enumservices-guide-22: 1752 o jason: addressed numerous comments and discusses opened during 1753 IESG review from David Harrington 1754 o bernie/alex: addressed more IESG review feedback from David 1755 Harrington 1756 o bernie: removed obsolete text that was still in the XML version, 1757 but commented out 1759 o bernie: minor editorials 1761 draft-ietf-enum-enumservices-guide-21: 1763 Implemented IESG Feedback: 1764 o alex: added note about scope of expert review process ("wide or 1765 narrow") to section 7 1766 o alex: changed cross-reference to section 2.4.4 of 3761bis to 3.4.3 1767 o alex: Added "non-normative" text to section 6 and 7 (David) 1768 o alex: Changed all RFC2119 text in section 6 and 7 to non-RFC2119 1769 text (David) 1770 o bernie: Adjusted comment in the registration template 1771 o bernie: Intended Status to 'std' on IESG request 1772 o bernie: Clarified 'substantial changes' in IANA section (Peter) 1773 o alex: changed RFC 9999 to something more funny (Stewart) 1774 o bernie: corrected typos in Sections 3.2, 11.6, 5.2.4 1775 o bernie: sorted out XML chunk vs. IANA Registration Template 1776 o bernie: added option for obsoletion by IESG action (Alexey) 1777 o bernie: conduct an (Expert Review) -> take care of the (Alexey / 1778 Miguel) 1779 o bernie: added "P-" Enumservices will not be registered at all 1780 (Alexey) 1781 o bernie: changes to normative language in Section 5.2.4 and 5.2.9 1782 (Jari) 1783 o bernie: improvement of text in section 11.5 (Dave H. / Miguel) 1784 o bernie: updated Acknowledgments section 1785 o bernie: re-ordered references 1786 o bernie: moved reference to rfc3986 to normative and added a 1787 reference in Section 5.2.4 (Alexey) 1789 draft-ietf-enum-enumservices-guide-20: 1790 o bernie: minor editorial (Feedback Alfred Hoenes) 1791 o bernie: updated my author's address (swisscom -> ucom.ch) 1792 o bernie: clarified IANA registration policy: "Specification 1793 Required", which implies "Expert Review", i.e. point to a single 1794 policy (Feedback Gonzalo Camarillo) 1795 o bernie: Further clarifications concerning mailing list and experts 1796 (Feedback Gonzalo Camarillo) 1797 o bernie: Rewording of recommendations for search for existing work 1799 draft-ietf-enum-enumservices-guide-19: 1800 o bernie: updated reference to specific RFC3761bis section 1801 o bernie: corrected several typos / grammar / clarity issues 1802 reported by Alfred Hoenes 1803 o bernie: added long versions of DNS and NAPTR / added DNS (incl. 1804 reference) to introduction 1806 o bernie: cleared out NAPTR DNS RR in Functionality Requirements 1807 o bernie: rewrote 2nd paragraph in Step 6 1808 o bernie: cleared out 3rd paragraph of Section 11.5 1810 draft-ietf-enum-enumservices-guide-18: 1811 o bernie: corrected -> 1812 o bernie: changed "(sub)type name" -> "(sub)type string" to be 1813 consistent 1814 o bernie: changed "element" -> "field" when referring to the old 1815 IANA template 1816 o bernie: lots of small editorial/punctuation changes 1817 o bernie: changed my author's address 1819 draft-ietf-enum-enumservices-guide-17: 1820 o bernie: As per IANA feedback changed the process in a way, that 1821 Expert Review takes place before the publication process is 1822 started (even in RFC case) 1823 o bernie: Restructured IANA Considerations section 1824 o bernie: IANA to ensure only expert reviewed versions are published 1825 as RFC 1826 o bernie: Editorial changes to section 'IANA Registration 1827 (MANDATORY)' (made sub-sections) 1828 o bernie: Added a note that IANA is to check for clashes in type: 1829 subtype naming 1830 o bernie: redundant sentences about (not) skip Step 6 removed in 1831 Step 4 1832 o bernie: Added clarification that extended Enumservices not 1833 complying with the new rules need to be updated 1834 o bernie: Added explicit Section for ABNF in references to 3761bis 1835 o bernie: Removed explicit hint / internal reference to appeal in 1836 Outcome 3 of step 5 1837 o bernie: Reference from naming requirements to cookbook as 1838 requirement, not only recommendation. 1839 o bernie: Explicit instructions to IANA to make the escrow copy 1840 o bernie: Lowercased vCard example for Type 1841 o bernie: Not that enum-svc-trans does not update compliant with 1842 this spec 1843 o bernie: Added Pekka Savola and Michelle Cotton to Acknowledgments. 1844 The above changes are a result of Pekka's feedback. 1845 o bernie: Typo in Step 6 corrected (Step 5 -> step 6) 1846 o bernie: 'IANA Template' -> 'XML chunk based IANA template' (in 1847 Structure) 1848 o bernie: Removed reference to RFC4355 (not used) 1849 o bernie: Updated ipr attribute to 'pre5378Trust200902' according to 1850 http://www.ietf.org/mail-archive/web/syslog/current/msg02333.html 1852 draft-ietf-enum-enumservices-guide-16: 1854 o bernie: capitalize "-based" in 1855 o bernie: consistent usage of plural for 1856 o bernie: changed title/naming for element (not 1857 changing element name itself) 1858 o bernie: updated Changes Overview section 1859 o bernie: clarified Open Issues section to be removed before 1860 publication 1861 o bernie: whitespace changes (indentations, line-breaks) in XML 1862 chunks 1863 o bernie: changed drama number in the example to a non-premium rate 1864 one (feedback Lawrence Conroy) 1866 draft-ietf-enum-enumservices-guide-15: 1867 o bernie: cleared out authors/requesters 1868 o alex: added ABNF reference + acronym expansion 1869 o alex: changed order of paragraphs in introduction - registry 1870 update now in front of blah blah paragraph 1871 o alex: various editorial and formatting updates to the new XML 1872 template specs. 1873 o alex: moved XML template to IANA considerations 1874 o alex: removed "identifying tag" language 1875 o alex: clarified "element" vs. "field" usage - "element" now refers 1876 to XML chunk pieces of IANA registration, while "fields" refers to 1877 other things, like fields of a NAPTR record, etc. 1878 o alex: removed more subtypes from third example - one subtype per 1879 template ensures that there is no confusion between the URI 1880 schemes for various subtypes 1882 draft-ietf-enum-enumservices-guide-14: 1883 o alex: changed template information in description of fields to XML 1884 chunk information 1885 o alex: added references to person information in examples 1886 o alex: replaced "registrant" with "requester" 1887 o bernie: minor editorial corrections and nits 1888 o jason: added the IANA XML chunk, as well as some examples 1890 draft-ietf-enum-enumservices-guide-13: 1891 o alex: Some minor changes - the only real open issue is whether or 1892 not we should go to an XML template instead of the plain text one. 1893 IANA provided a "chunk", but gave no feedback about schema, 1894 namespace, etc. so it is deemed not "normative" enough yet. 1895 o bernie: Implemented IANA Feedback: made difference between RFC and 1896 no-RFC specs more clear; now the both variants slightly differ in 1897 process. 1898 o bernie: Implemented more feedback of Peter Koch: 1899 * Terminology updated throughout the document: Enumservice 1900 Specification / Registration Document 1902 * Changed IANA Template field 'Registration Document(s) to 1903 'Enumservice specification(s)' 1904 * Disallow dash '-' as last char of Type or Subtype 1905 * Removed XML2RFC template and referencing sections 1906 o bernie: changed "Subtype names MAY be shared between URI Schemes 1907 that the Registration specifies as mandatory to implement for a 1908 given Subtype." to "Subtype names MAY be shared between URI 1909 Schemes, if all the URI Schemes within the same Subtype are 1910 mandatory to implement." 1911 o bernie: Cleared out independent submission and added reference to 1912 RFC 4846 1913 o jason: Per the co-chair and Peter Koch, doc changed to BCP. Doc 1914 doesn't specify a protocol but a process. Both RFC 2026, section 1915 5, and section 4.3 of RFC 5226 suggest that process documents, and 1916 IANA Guidelines in particular, usually are published as BCP RFCs. 1917 Also, there's little to implement independently in this draft that 1918 could help advance it on the Standards Track. 1919 o jason: various nits clean-up suggested by Peter Koch. 1921 draft-ietf-enum-enumservices-guide-12: 1922 o bernie: Refined process, i.e. separation of Expert Review and 1923 addition to IANA Registry (only after publication of spec): 1924 * Split up "Further Steps" into three new sections 1925 * Extended ASCII Art 1926 * Adjusted IANA considerations 1927 o bernie: Updated Open Issues 1928 o alex: Added reference to RFC3552 (security considerations 1929 guidance) 1930 o alex: Added instructions2author as informative reference - i don't 1931 see another way (revision 439, closing ticket 25) 1932 o alex: Moved text about use cases from Review Guidelines up to 1933 "other sections", slightly reworded it (revision 438, closing 1934 ticket 66) 1935 o bernie: Updated own contact details 1936 o bernie: Implemented editorial feedback from Alfred Hoenes 1937 o bernie: Added some clarifications to IANA consideration as 1938 proposed by Michelle Cotton (IANA) 1939 o bernie: Edited appendix "Changes Overview", moved stuff from 1940 "Introduction" to "Changes Overview" 1941 o bernie: Updated IANA section "Change Control": 1942 * Authorized Change controllers are experts and IESG 1943 * Removed field "Authorized Change Controller" (was introduced in 1944 -11) 1945 o bernie: Replaced "number blocks" by "wildcards" (DNS 1946 Considerations) to avoid conflict with RFC3761 1947 o bernie: Extended recommendations about search for previous work 1948 o bernie: Adjusted sections "Revision of Pre-Existing Enumservice 1949 RFCs" and "Submit Registration Document to IANA" 1951 draft-ietf-enum-enumservices-guide-11: 1952 o bernie: Replaced reference rfc2434bis with rfc5226 1953 o bernie: Moved terminology related paragraph from Introduction to 1954 Terminology Section 1955 o bernie: Added reference to transition document 1956 o jason: Updated my author address 1957 o jason: Closed out active tickets at 1958 http://ietf.enum.at/cgi-bin/trac.cgi/report/1 1959 o jason: Section 8, review of pre-existing enumservices, updated 1960 with IETF 72 feedback that this must take place 1961 o jason: Ticket 39: Added text to section 4.1, general enumservice 1962 considerations, section 2, bullet 2 to address comment by Lawrence 1963 Conroy about expired I-Ds 1964 o jason: Ticket 45: Added text to section 7.1, expert review / 1965 review guidelines, bullet 3, to indicate that a use case SHOULD be 1966 included. Also added related text to section 5.8, other sections, 1967 to address this. This resolves comments by Lawrence Conroy 1968 o jason: Ticket 55: Replaced 'repository' with 'registry' throughout 1969 the document to normalize this text and make it uniform. 1970 o jason: Ticket 52: Checked references to ensure rfc5226 is cited 1971 instead of rfc2434bis, which Bernie seems to have mainly covered. 1972 I also added a reference in the header for rfc5226, since it is a 1973 normative reference. 1974 o jason: Ticket 25: Removed reference to rfc2223bis-08 as this I-D 1975 is now listed as dead. 1976 o jason: Ticket 49: Have updated section 5.2, IANA registration, 1977 bullet on authors addresses, to say that email addresses MUST NOT 1978 be included in the IANA Registry. I opened a related ticket. 1979 Seems there are some email addresses in the registry. Also 1980 simplified author(s) and expert(s) to authors and experts 1981 throughout. 1982 o jason: Ticket 28: Minor changes to Section 10.1 and 10.2, Security 1983 Considerations 1984 o jason: Ticket 30: Updated section 6.4, 6.5, on IANA registration 1985 to include that submission must be in XML format for IANA and that 1986 the Enumservice must have an RFC number, per discussion at IETF 72 1987 o jason: Ticket 42: Cleaned up section 5.7, DNS considerations, per 1988 comments from Lawrence. 1989 o jason: Updated definitions to reflect IANA Designated Experts per 1990 RFC 5226, and clean up of IANA-related terms (Registry, Template, 1991 etc.) 1992 o jason: Ticket 51: added section to describe the need to have a 1993 contact listed for updating a registration, per RFC 5226, section 1994 5.2. 1996 draft-ietf-enum-enumservices-guide-10: 1997 o bernie: No longer empty field for IANA Registration ('N/A' must be 1998 used in this case) 1999 o bernie: Adjusted IANA Registration Template: 2000 * Registration Document -> Registration Document(s) 2001 * Author -> Author(s) 2002 o bernie: IANA repository in alphabetical order by Type and Subtype 2003 o bernie: Class, Type, Subtype and URI Schema to begin with capital 2004 o bernie: Caption for each Enumservice 2005 o bernie: Consistent use of "field" for fields within IANA 2006 registration template (no longer used are "item" or "section") 2007 o bernie: URI Schemes without colons and between single quotes, no 2008 longer email address in author(s) field 2009 o bernie: Adjusted IANA Registration Section of XML2RFC template 2010 o alex: Added List of Classes to choose from 2012 draft-ietf-enum-enumservices-guide-09: 2013 o alex: Removed Enumservice "Name" as decided at IETF 71 2014 o alex: Reworded registration requirements 2015 o alex: Explained possible values for "Intended Usage" 2016 o bernie: Rewrite of section 'Change Control' 2017 o bernie: Cleared out scope of this document (only ordinary, but no 2018 'X-' registrations) 2019 o bernie: Cleared out naming restrictions in IANA section 2020 o bernie: Changed section name from 'ENUM Service Registration' to 2021 'IANA Registration' 2022 o bernie: Combined Expert Review related sections 2023 o bernie: Partly implemented feedback Alfred Hoenes and added him to 2024 Acknowledgments 2025 o bernie: Enhanced examples for "Registration Document" 2026 o bernie: Enhanced examples for "IANA Considerations" (feedback from 2027 Alfred Hoenes) 2028 o bernie: Removed Note about RFC3761bis obsoleting RFC3761 (does not 2029 belong to this doc) 2030 o bernie: Rewrote Naming Requirements section (impact to IANA 2031 Considerations - Restrictions) 2033 draft-ietf-enum-enumservices-guide-08: 2034 o alex: new text for Subtypes of protocol class enumservices 2035 ("mandatory to implement" stuff) 2036 o alex: added "to be foreseen" to the application Type Subtype 2037 recommendation 2038 o alex: added "lowercase" recommendation to the Type names 2039 o bernie: Corrected various typos, clarifications, and other 2040 editorial stuff (feedback from Lawrence Conroy) 2041 o bernie: IANA Registry ftp -> http (feedback from Lawrence Conroy) 2042 o bernie: Made steps prior to IANA submission mandatory (feedback 2043 from Lawrence Conroy) 2044 o bernie: Shortened abstract 2046 draft-ietf-enum-enumservices-guide-07: 2047 o bernie: Section DNS considerations made mandatory 2048 o bernie: Complete rewrite of IANA considerations 2049 o bernie: XML2RFC template will be downloadable at IANA 2050 o bernie: Complete re-write of process 2051 o alex: Adjusted Cook-book / classification 2052 o bernie: Take over chapter "Registration mechanism for 2053 Enumservices" from RFC 3761bis 2054 o bernie: Changed title to adjust to new purpose 2055 o bernie: Intended status changed to Standards Track (was bcp) 2056 o bernie: Obsoletes (partly) RFC 3761 2057 o bernie: Adjusted section "Registration mechanism for Enumservices" 2058 o bernie: Updated most RFC 3761 references to either RFC3761bis or 2059 new (internal) section 2060 o bernie: Acknowledgment for RFC3761 contributors 2061 o bernie: Shortened bullet point in IANA Registration Template: 2062 "Any other information that the author deems interesting" 2063 ==> "Further Information" 2064 o alex: Rewritten Abstract, Introduction to be consistent with with 2065 new goal (IANA Registry description) 2066 o alex: Add obsoletes section 3 of RFC 3761 to Introduction 2067 o alex: Changed section 3 to "registration requirements", Simplified 2068 structure 2069 o alex: Added examples for protocol Enumservice classification 2070 o alex: Added text about "other" classification 2072 draft-ietf-enum-enumservices-guide-06: 2073 o alex: updated Class Schemes. 2074 o alex: updated expert's tasks 2075 o alex: added experts review considerations 2076 o bernie: Moved Terminology section in XML2RFC template (now after 2077 Introduction) 2078 o bernie: Class is now part of the Enumservice registration in the 2079 IANA template 2080 o bernie: Individual Submission relaxed (comment Peter Koch) 2081 o bernie: updated vcard Ref (now RFC) 2083 draft-ietf-enum-enumservices-guide-05: 2084 o bernie/alex: added text for sections 'The Enumservice Expert 2085 Selection Process' and 'The Process for Appealing Expert Review 2086 Decisions' 2087 o bernie: added ASCII-art figure for registration process 2088 o bernie: adjusted registration process 2089 o jason: proposed registration process 2091 draft-ietf-enum-enumservices-guide-04: 2092 o bernie: added section about Extension of existing Enumservice RFCs 2093 o bernie: added open issue about future registration process 2094 o bernie: added category (bcp) 2095 o bernie: clean up in Security Considerations 2096 o bernie: editorial stuff (mainly XML issues) 2098 draft-ietf-enum-enumservices-guide-03: 2099 o alex: moved terminology section 2100 o alex: removed note asking for feedback 2101 o bernie: added DNS consideration section 2102 o bernie: added Acknowledgments section 2103 o bernie: editorial stuff (nicer formating, fixing too long lines) 2104 o alex: added security considerations from vcard draft. 2106 draft-ietf-enum-enumservices-guide-02: 2107 o bernie: replaced numbers in examples by "Drama Numbers" 2108 o bernie: moved Change and Open Issues to Appendix. 2109 o bernie: major rewrite of section "6. Required Sections and 2110 Information" incl. separating explanations and examples. 2111 o bernie: removed section 7 (was just a repetition of referencing to 2112 XML2RFC template) 2113 o bernie: extended Appendix with Open Issues. 2115 draft-ietf-enum-enumservices-guide-01: 2116 o alex: added Security Considerations section for the doc itself 2117 o alex: added IANA Considerations section for the doc itself 2118 o alex: added cookbook idea 2120 Appendix D. Open Issues 2122 [RFC Editor: This section should be removed before publication] 2123 o None 2125 Appendix E. Notes for the RFC Editor Concerning RFC 3761 2127 [RFC Editor: This section should be removed before publication] 2129 This document obsoletes Section 3 of RFC3761, while 2130 draft-enum-ietf-3761bis obsoletes all the rest of RFC3761. We are a 2131 bit unclear about the id-nits rules about partially obsoleting a 2132 prior RFC. Furthermore, we ask whether you wish us to add something 2133 to this effect also to the Abstract or not (in addition to the 2134 mention in the Introduction section). We look forward to your 2135 guidance on what to do in this regard. 2137 Authors' Addresses 2139 Bernie Hoeneisen 2140 Ucom Standards Track Solutions GmbH 2141 CH-8049 Zuerich 2142 Switzerland 2144 Phone: +41 44 500 52 44 2145 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 2146 URI: http://www.ucom.ch/ 2148 Alexander Mayrhofer 2149 enum.at GmbH 2150 Karlsplatz 1/9 2151 Wien A-1010 2152 Austria 2154 Phone: +43 1 5056416 34 2155 Email: alexander.mayrhofer@enum.at 2156 URI: http://www.enum.at/ 2158 Jason Livingood 2159 Comcast Cable Communications 2160 One Comcast Center 2161 1701 John F. Kennedy Boulevard 2162 Philadelphia, PA 19103 2163 USA 2165 Phone: +1-215-286-7813 2166 Email: jason_livingood@cable.comcast.com 2167 URI: http://www.comcast.com/