idnits 2.17.1 draft-hoeneisen-enum-enumservices-transition-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 902. 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 abstract seems to contain references ([I-D.ietf-enum-enumservices-guide], [RFC3761]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4143, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3953, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3762, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3764, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3762, updated by this document, for RFC5378 checks: 2003-02-19) -- 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 (May 20, 2008) is 5819 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) == Missing Reference: 'RFCTHIS' is mentioned on line 727, but not defined -- Looks like a reference, but probably isn't: '15' on line 494 -- Looks like a reference, but probably isn't: '16' on line 497 -- Looks like a reference, but probably isn't: '14' on line 519 -- Looks like a reference, but probably isn't: '12' on line 208 -- Looks like a reference, but probably isn't: '13' on line 208 -- Looks like a reference, but probably isn't: '7' on line 540 -- Looks like a reference, but probably isn't: '6' on line 283 == Missing Reference: 'RFC3413' is mentioned on line 304, but not defined -- Looks like a reference, but probably isn't: '4' on line 323 -- Looks like a reference, but probably isn't: '17' on line 372 -- Looks like a reference, but probably isn't: '10' on line 597 ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-22) exists of draft-ietf-enum-enumservices-guide-10 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 21 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 SWITCH 4 Internet-Draft A. Mayrhofer 5 Updates: 3762, 3764, 3953, 4143, enum.at 6 4002, 4238, 4355, 4415, 4769, May 20, 2008 7 4969, 4979, 5028 8 (if approved) 9 Intended status: Standards Track 10 Expires: November 21, 2008 12 Update of legacy IANA Registrations of Enumservices 13 draft-hoeneisen-enum-enumservices-transition-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 21, 2008. 40 Abstract 42 This document specifies a revision of all Enumservices that have been 43 registered at IANA under the nowadays obsolete regime of [RFC3761]. 44 It mainly adds the new fields to the IANA Registration Template as 45 specified in [I-D.ietf-enum-enumservices-guide], and makes at the 46 same time some corrections of editorial nature. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Enumservice Registrations . . . . . . . . . . . . . . . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 61 6. Normative References . . . . . . . . . . . . . . . . . . . . . 18 63 Appendix A. Former Content of the IANA Repository . . . . . . . . 19 65 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 19 67 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 70 Intellectual Property and Copyright Statements . . . . . . . . . . 21 72 1. Introduction 74 [I-D.ietf-enum-enumservices-guide] has obsoleted the IANA 75 registration section of [RFC3761]. In the IANA registry for 76 Enumservices, there are several entries that had been made under RFC 77 3761 regime. Those do not conform to the new guidelines as specified 78 in [I-D.ietf-enum-enumservices-guide]. To ensure consistency among 79 the Enumservice registrations, the document adds the new fields to 80 the existing IANA registrations and makes some editorial corrections 81 at the same time. 83 However, this document does only add the missing fields from the IANA 84 Registration Template as specified in the IANA Considerations of 85 [I-D.ietf-enum-enumservices-guide], but does not complete the 86 (nowadays) missing sections of the corresponding Registration 87 Documents. These documents have to be revised in order to conform 88 with the new regime for Enumservice registrations as specified in 89 [I-D.ietf-enum-enumservices-guide]. 91 This document updates the following RFCs: 93 o [RFC3762] 94 o [RFC3764] 95 o [RFC3953] 96 o [RFC4143] 97 o [RFC4002] 98 o [RFC4238] 99 o [RFC4355] 100 o [RFC4415] 101 o [RFC4769] 102 o [RFC4969] 103 o [RFC4979] 104 o [RFC5028] 105 o [I-D.ietf-enum-calendar-service] 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 3. IANA Considerations 114 3.1. Enumservice Registrations 116 IANA replaces the existing Enumservice Registrations by the 117 following: 119 [Note for RFC Editor: Please replace any instance of RFCTHIS with the 120 RFC number of this document before publication] 122 Assigned Enumservice Values 123 --------------------------- 125 email:mailto 127 o Enumservice Class: Application-based, Common 128 o Enumservice Type: "email" 129 o Enumservice Subtype: "mailto" 130 o URI Scheme(s): 'mailto' 131 o Functional Specification: 132 * This Enumservice indicates that the resource can be addressed 133 by the associated URI in order to send an email. 134 o Security Considerations: See Section 6 of [RFC4355] 135 o Intended Usage: COMMON 136 o Registration Document(s): 137 * [RFC4355] (Updated by RFCTHIS) 138 * [RFCTHIS] 139 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 140 o Further Information: N/A 142 ems:mailto 144 o Enumservice Class: Application-based, Common 145 o Enumservice Type: "ems" 146 o Enumservice Subtype: "mailto" 147 o URI Scheme(s): 'mailto' 148 o Functional Specification: 149 * This Enumservice indicates that the resource identified by the 150 associated URI is capable of receiving a message using an email 151 protocol. 152 * EMS content is sent over SMTP using the format specified by TS 153 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an 154 MMS message. Within such a message, EMS content is carried as 155 either a text or application/octet-stream MIME sub-part (see TS 156 26.140 [16], Section 4.1). 157 * For references see [RFC4355]. 159 o Security Considerations: 160 * There are no specific security issues with this Enumservice. 161 However, the general considerations of Section 6 of [RFC4355] 162 apply. 163 o Intended Usage: COMMON 164 o Registration Document(s): 165 * [RFC4355] (Updated by RFCTHIS) 166 * [RFCTHIS] 167 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 168 o Further Information: N/A 170 ems:tel 172 o Enumservice Class: Application-based, Common 173 o Enumservice Type: "ems" 174 o Enumservice Subtype: "tel" 175 o URI Scheme(s): 'tel' 176 o Functional Specification: 177 * This Enumservice indicates that the resource identified by the 178 associated URI is capable of receiving a message using the 179 Enhanced Message Service (EMS) [14] (For reference see 180 [RFC4355]). 181 o Security Considerations: 182 * There are no specific security issues with this Enumservice. 183 However, the general considerations of Section 6 of [RFC4355] 184 apply. 185 o Intended Usage: COMMON 186 o Registration Document(s): 187 * [RFC4355] (Updated by RFCTHIS) 188 * [RFCTHIS] 189 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 190 o Further Information: 191 * Note that an indication of EMS can be taken as implying that 192 the recipient is capable of receiving SMS messages at this 193 address as well. 195 fax:tel 197 o Enumservice Class: Application-based, Subset 198 o Enumservice Type: "fax" 199 o Enumservice Subtype: "tel" 200 o URI Scheme(s): 'tel' 201 o Functional Specification: 202 * This Enumservice indicates that the resource identified by the 203 associated URI is capable of being contacted to provide a 204 communication session during which facsimile documents can be 205 sent. 206 * A client selecting this NAPTR will have support for generating 207 and sending facsimile documents to the recipient using the PSTN 208 session and transfer protocols specified in [12] and [13] in 209 [RFC4355] - in short, they will have a fax program with a local 210 or shared PSTN access over which they can send faxes. 211 o Security Considerations: See Section 6 of [RFC4355] 212 o Intended Usage: COMMON 213 o Registration Document(s): 214 * [RFC4355] (Updated by RFCTHIS) 215 * [RFCTHIS] 216 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 217 o Further Information: N/A 219 ft:ftp 221 o Enumservice Class: Application-based, Subset 222 o Enumservice Type: "ft" 223 o Enumservice Subtype: "ftp" 224 o URI Scheme(s): 'ftp' 225 o Functional Specification: 226 * This Enumservice indicates that the resource identified by the 227 associated URI is a file service from which a file or file 228 listing can be retrieved. 229 o Security Considerations: See Section 5 of [RFC4002] 230 o Intended Usage: COMMON 231 o Registration Document(s): 232 * [RFC4002] (Updated by RFCTHIS) 233 * [RFCTHIS] 234 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 235 o Further Information: N/A 237 h323 239 o Enumservice Class: Protocol-based 240 o Enumservice Type: "h323" 241 o Enumservice Subtype: N/A 242 o URI Scheme(s): 'h323' 243 o Functional Specification: See Section 3 of [RFC3762] 244 o Security Considerations: See section 5 of [RFC3762] 245 o Intended Usage: COMMON 246 o Registration Document(s): 247 * [RFC3762] (Updated by RFCTHIS) 248 * [RFCTHIS] 250 o Author(s): Orit Levin 251 o Further Information: N/A 253 ical:access 255 o Enumservice Class: Data- / Format-based 256 o Enumservice Type: "ical" 257 o Enumservice Subtype: "access" 258 o URI Scheme(s): 'http', 'https' 259 o Functional Specification: 260 * This Enumservice indicates that the resource identified is a 261 URI used for Internet Calendaring which is available to access 262 a user's calendar (for example free/busy status). Supported 263 URI Schemes are 'http:' or 'https:' URIs for the CalDAV [7] 264 protocol. 265 o Security Considerations: See Section 3 of [RFC-ietf-enum-calendar- 266 service-04.txt] 267 o Intended Usage: COMMON 268 o Registration Document(s): 269 * [RFC-ietf-enum-calendar-service-04.txt] (Updated by RFCTHIS) 270 * [RFCTHIS] 271 o Author(s): Author: Rohan Mahy 272 o Further Information: N/A 274 ical:sched 276 o Enumservice Class: Data- / Format-based 277 o Enumservice Type: "ical" 278 o Enumservice Subtype: "sched" 279 o URI Scheme(s): 'mailto', 'http', 'https' 280 o Functional Specification: 281 * This Enumservice indicates that the resource identified is a 282 URI used for scheduling using Internet Calendaring. Supported 283 URI Schemes are the 'mailto:' URI for the iMIP [6] protocol, 284 and 'http:' or 'https:' URIs for a planned scheduling extension 285 [15] to the CalDAV [7] protocol. 286 o Security Considerations: See Section 3 of [RFC-ietf-enum-calendar- 287 service-04.txt] 288 o Intended Usage: COMMON 289 o Registration Document(s): 290 * [RFC-ietf-enum-calendar-service-04.txt] (Updated by RFCTHIS) 291 * [RFCTHIS] 292 o Author(s): Rohan Mahy 293 o Further Information: N/A 294 ifax:mailto 296 o Enumservice Class: Application-based, Subset 297 o Enumservice Type: "ifax" 298 o Enumservice Subtype: "mailto" 299 o URI Scheme(s): 'mailto' 300 o Functional Specification: See Section 1 of [RFC4143] 301 o Security Considerations: See Section 3 of [RFC4143] 302 o Intended Usage: COMMON 303 o Registration Document(s): 304 * [RFC3413] (Updated by RFCTHIS) 305 * [RFCTHIS] 306 o Author(s): Kiyoshi Toyoda, Dave Crocker 307 o Further Information: 308 * The URI Scheme is "mailto" because facsimile is a profile of 309 standard Internet mail and uses standard Internet mail 310 addressing. 312 im 314 o Enumservice Class: Application-based, Common 315 o Enumservice Type: "im" 316 o Enumservice Subtype: N/A 317 o URI Scheme(s): 'im' 318 o Functional Specification: 319 * This Enumservice indicates that the resource identified is an 320 'im:' URI. The 'im:' URI scheme does not identify any 321 particular protocol that will be used to handle instant 322 messaging receipt or delivery, rather the mechanism in RFC3861 323 [4] is used to discover whether an IM protocol supported by the 324 party querying ENUM is also supported by the target resource. 325 o Security Considerations: See Section 3 of [RFC5028] 326 o Intended Usage: COMMON 327 o Registration Document(s): 328 * [RFC5028] (Updated by RFCTHIS) 329 * [RFCTHIS] 330 o Author(s): Rohan Mahy 331 o Further Information: N/A 333 mms:mailto 335 o Enumservice Class: Application-based, Common 336 o Enumservice Type: "mms" 337 o Enumservice Subtype: "mailto" 338 o URI Scheme(s): 'mailto' 339 o Functional Specification: 340 * This Enumservice indicates that the resource identified by the 341 associated URI is capable of receiving a message using an email 342 protocol. 343 * MMS messages are sent over SMTP using the format specified by 344 TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4. 345 * Within and between MMS Environments (MMSE, network 346 infrastructures that support the MultiMedia Service), other 347 pieces of state data (for example, charging-significant 348 information) are exchanged between MMS Relay Servers. Thus, 349 although these servers use SMTP as the "bearer" for their 350 application exchanges, they map their internal state to 351 specialized header fields carried in the SMTP message 352 exchanges. The header fields used in such MMSE are described 353 in detail in [17]. 354 * For references see [RFC4355] 355 o Security Considerations: 356 * There are no specific security issues with this Enumservice. 357 However, the general considerations of Section 6 of [RFC4355] 358 apply. 359 o Intended Usage: COMMON 360 o Registration Document(s): 361 * [RFC4355] (Updated by RFCTHIS) 362 * [RFCTHIS] 363 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 364 o Further Information: 365 * The MMS Architecture describes an interface between the MMSE 366 and "legacy messaging systems" (labelled as MM3) which accepts 367 "standard" SMTP messages. Thus although the MMS Relay Server 368 that supports this interface appears as a standard SMTP server 369 from the perspective of an Internet-based mail server, it acts 370 as a gateway and translator, adding the internal state data 371 that is used within and between the MMS Environments. This 372 mechanism is described in [17], which also includes references 373 to the specifications agreed by those bodies responsible for 374 the design of the MMS. 376 mms:tel 378 o Enumservice Class: Application-based, Common 379 o Enumservice Type: "mms" 380 o Enumservice Subtype: "tel" 381 o URI Scheme(s): 'tel' 382 o Functional Specification: 384 * This Enumservice indicates that the resource identified by the 385 associated URI is capable of receiving a message using the 386 Multimedia Messaging Service (MMS) [15]. 387 * For references see [RFC4355]. 388 o Security Considerations: 389 * There are no specific security issues with this Enumservice. 390 However, the general considerations of Section 6 of [RFC4355] 391 apply. 392 * For references see [RFC4355]. 393 o Intended Usage: COMMON 394 o Registration Document(s): 395 * [RFC4355] (Updated by RFCTHIS) 396 * [RFCTHIS] 397 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 398 o Further Information: 399 * Note that MMS can be used as an alternative to deliver an SMS 400 RP- DATA RPDU if, for example, the SMS bearer is not supported. 401 If an entry includes this Enumservice, then in effect this can 402 be taken as implying that the recipient is capable of receiving 403 EMS or SMS messages at this address. Such choices on the end 404 system de do have two small caveats; whilst in practice all 405 terminals supporting MMS today support SMS as well, it might 406 not necessarily be the case in the future, and there may be 407 tariff differences in using the MMS rather than using the SMS 408 or EMS. 410 pres 412 o Enumservice Class: Application-based, Common 413 o Enumservice Type: "pres" 414 o Enumservice Subtype: N/A 415 o URI Scheme(s): 'pres' 416 o Functional Specification: See Section 4 of [RFC3953] 417 o Security Considerations: See Section 6 of [RFC3953] 418 o Intended Usage: COMMON 419 o Registration Document(s): 420 * [RFC3953] (Updated by RFCTHIS) 421 * [RFCTHIS] 422 o Author(s): Jon Peterson 423 o Further Information: See Section 3 of [RFC3953] 425 pstn:sip 427 o Enumservice Class: Application-based, Subset (??) 428 o Enumservice Type: "pstn" 429 o Enumservice Subtype: "sip" 430 o URI Scheme(s): 'sip' 431 o Functional Specification: 432 * These Enumservices indicate that the resource identified can be 433 addressed by the associated URI in order to initiate a 434 telecommunication session, which may include two-way voice or 435 other communications, to the PSTN. 436 o Security Considerations: See Section 7 of [RFC4769] 437 o Intended Usage: COMMON 438 o Registration Document(s): 439 * [RFC4769] (Updated by RFCTHIS) 440 * [RFCTHIS] 441 o Author(s): Jason Livingood, Richard Shockey 442 o Further Information: 443 * A Number Portability Dip Indicator (npdi) should be used in 444 practice (see examples below in Section 4 of [RFC4769]). 446 pstn:tel 448 o Enumservice Class: Application-based, Ancillary 449 o Enumservice Type: "pstn" 450 o Enumservice Subtype: "tel" 451 o URI Scheme(s): 'tel' 452 o Functional Specification: 453 * These Enumservices indicate that the resource identified can be 454 addressed by the associated URI in order to initiate a 455 telecommunication session, which may include two-way voice or 456 other communications, to the PSTN. These URIs may contain 457 number portability data as specified in RFC4694 [10]. 458 o Security Considerations: See Section 7 of [RFC4769] 459 o Intended Usage: COMMON 460 o Registration Document(s): 461 * [RFC4769] (Updated by RFCTHIS) 462 * [RFCTHIS] 463 o Author(s): Jason Livingood, Richard Shockey 464 o Further Information: 465 * A Number Portability Dip Indicator (npdi) should be used in 466 practice (see examples below in Section 4 of [RFC4769]). 468 sip 470 o Enumservice Class: Protocol-based 471 o Enumservice Type: "sip" 472 o Enumservice Subtype: N/A 473 o URI Scheme(s): 'sip', 'sips' 474 o Functional Specification: See Section 4 of [RFC3764] 475 o Security Considerations: See Section 6 of [RFC3764] 476 o Intended Usage: COMMON 477 o Registration Document(s): 478 * [RFC3764] (Updated by RFCTHIS) 479 * [RFCTHIS] 480 o Author(s): Jon Peterson 481 o Further Information: See Section 3 of [RFC3764] 483 sms:mailto 485 o Enumservice Class: Application-based, Common 486 o Enumservice Type: "sms" 487 o Enumservice Subtype: "mailto" 488 o URI Scheme(s): 'mailto' 489 o Functional Specification: 490 * This Enumservice indicates that the resource identified by the 491 associated URI is capable of receiving a message using an email 492 protocol. 493 * SMS content is sent over SMTP using the format specified by TS 494 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an 495 MMS message. Within such a message, SMS content is carried as 496 either a text or application/octet-stream MIME sub-part (see TS 497 26.140 [16], Section 4.1) 498 * For references see [RFC4355]. 499 o Security Considerations: 500 * There are no specific security issues with this Enumservice. 501 However, the general considerations of Section 6 of [RFC4355] 502 apply. 503 o Intended Usage: COMMON 504 o Registration Document(s): 505 * [RFC4355] (Updated by RFCTHIS) 506 * [RFCTHIS] 507 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 508 o Further Information: N/A 510 sms:tel 512 o Enumservice Class: Application-based, Common 513 o Enumservice Type: "sms" 514 o Enumservice Subtype: "tel" 515 o URI Scheme(s): 'tel' 516 o Functional Specification: 517 * This Enumservice indicates that the resource identified by the 518 associated URI is capable of receiving a message using the 519 Short Message Service (SMS) [14] in [RFC4355]. 520 o Security Considerations: 521 * There are no specific security issues with this Enumservice. 522 However, the general considerations of Section 6 of [RFC4355] 523 apply. 524 o Intended Usage: COMMON 525 o Registration Document(s): 526 * [RFC4355] (Updated by RFCTHIS) 527 * [RFCTHIS] 528 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 529 o Further Information: N/A 531 vcard 533 o Enumservice Class: Data- / Format-based 534 o Enumservice Type: "vcard" 535 o Enumservice Subtype: N/A 536 o URI Scheme(s): 'http', 'https' 537 o Functional Specification: 538 * This Enumservice indicates that the resource identified is a 539 plain vCard, according to RFC2426, which may be accessed using 540 HTTP / HTTPS [7]. 541 * Clients fetching the vCard from the resource indicated should 542 expect access to be restricted. Additionally, the 543 comprehension of the data provided may vary depending on the 544 client's identity. 545 o Security Considerations: See Section 5 [RFC4969] 546 o Intended Usage: COMMON 547 o Registration Document(s): 548 * [RFC4969] (Updated by RFCTHIS) 549 * [RFCTHIS] 550 o Author(s): Alexander Mayrhofer 551 o Further Information: 553 voice:tel 555 o Enumservice Class: Application-based, Common 556 o Enumservice Type: "voice" 557 o Enumservice Subtype: "tel" 558 o URI Scheme(s): 'tel' 559 o Functional Specification: 561 * The kind of communication indicated by this Enumservice is 562 "Interactive Voice". From a protocol perspective, this 563 communication is expected to involve bidirectional media 564 streams carrying audio data. 565 * A client may imply that the person controlling population of a 566 NAPTR holding this Enumservice indicates their capability to 567 engage in an interactive voice session when contacted using the 568 URI generated by this NAPTR. 569 o Security Considerations: See Section 5 of [RFC4415] 570 o Intended Usage: COMMON 571 o Registration Document(s): 572 * [RFC4415] (Updated by RFCTHIS) 573 * [RFCTHIS] 574 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 575 o Further Information: 576 * This Enumservice indicates that the person responsible for the 577 NAPTR is accessible via the PSTN (Public Switched Telephone 578 Network) or PLMN (Public Land Mobile Network) using the value 579 of the generated URI. 580 * The kind of subsystem required to initiate a Voice Enumservice 581 with this Subtype is a "Dialler". This is a subsystem that 582 either provides a local connection to the PSTN or PLMN, or that 583 provides an indirect connection to those networks. The 584 subsystem will use the telephone number held in the generated 585 URI to place a voice call. The voice call is placed to a 586 network that uses E.164 numbers to route calls to an 587 appropriate destination. 588 * Note that the PSTN/PLMN connection may be indirect. The end 589 user receiving this NAPTR may have a relationship with a 590 Communications Service Provider that accepts call initiation 591 requests from that subsystem using an IP-based protocol such as 592 SIP or H.323, and places the call to the PSTN using a remote 593 gateway service. In this case the Provider may either accept 594 requests using "tel:" URIs or has a defined mechanism to 595 convert "tel:" URI values into a "protocol-native" form. 596 * The "tel:" URI value SHOULD be fully qualified (using the 597 "global phone number" form of RFC3966 [10]). A "local phone 598 number" as defined in that document SHOULD NOT be used unless 599 the controller of the zone in which the NAPTR appears is sure 600 that it can be distinguished unambiguously by all clients that 601 can access the resource record and that a call from their 602 network access points can be routed to that destination. 604 vpim:ldap 605 o Enumservice Class: Application-based, Common (??) 606 o Enumservice Type: "vpim" 607 o Enumservice Subtype: "ldap" 608 o URI Scheme(s): 'ldap' 609 o Functional Specification: See Sections 3.2 - 3.3 of [RFC4238] 610 o Security Considerations: 611 * Malicious Redirection: 612 One of the fundamental dangers related to any service such as 613 this is that a malicious entry in a resolver's database will 614 cause clients to resolve the E.164 into the wrong LDAP URI. 615 The possible intent may be to cause the client to connect to a 616 rogue LDAP server and retrieve (or fail to retrieve) a resource 617 containing fraudulent or damaging information. 618 * Denial of Service: 619 By removing the URI to which the E.164 maps, a malicious 620 intruder may remove the client's ability to access the LDAP 621 directory server. 622 o Intended Usage: COMMON 623 o Registration Document(s): 624 * [RFC4238] (Updated by RFCTHIS) 625 * [RFCTHIS] 626 o Author(s): Greg Vaudreuil 627 o Further Information: N/A 629 vpim:mailto 631 o Enumservice Class: Application-based, Common 632 o Enumservice Type: "vpim" 633 o Enumservice Subtype: "mailto" 634 o URI Scheme(s): 'mailto' 635 o Functional Specification: See Sections 4.2 - 4.4 of [RFC4238] 636 o Security Considerations: 637 * Malicious Redirection: 638 One of the fundamental dangers related to any service such as 639 this is that a malicious entry in a resolver's database will 640 cause clients to resolve the E.164 into the wrong email URI. 641 The possible intent may be to cause the client to send the 642 information to an incorrect destination. 643 * Denial of Service: 644 By removing the URI to which the E.164 maps, a malicious 645 intruder may remove the client's ability to access the 646 resource. 647 * Unsolicited Bulk Email: 648 The exposure of email addresses through the ENUM service 649 provides a bulk mailer access to large numbers of email 650 addresses where only the telephone number was previously known. 652 o Intended Usage: COMMON 653 o Registration Document(s): 654 * [RFC4238] (Updated by RFCTHIS) 655 * [RFCTHIS] 656 o Author(s): Greg Vaudreuil 657 o Further Information: 658 * Error Conditions: 659 + E.164 number not in the numbering plan 660 + E.164 number in the numbering plan, but no URIs exist for 661 that number 662 + E2U+vpim:mailto Service unavailable of email addresses where 663 only the telephone number was previously known. 665 web:http 667 o Enumservice Class: Application-based, Common 668 o Enumservice Type: "web" 669 o Enumservice Subtype: "http" 670 o URI Scheme(s): 'http' 671 o Functional Specification: 672 * This Enumservice indicates that the resource identified by the 673 associated URI is capable of being a source of information. It 674 has to be noted that the kind of information retrieved can be 675 manifold. Usually, contacting a resource by an "http:" URI 676 provides a document. This document can contain references that 677 will trigger download of many different kinds of information, 678 like audio or video or executable code. Thus, one can not be 679 more specific about the kind of information that can be 680 expected when contacting the resource. 681 o Security Considerations: See Section 5 of [RFC4002] 682 o Intended Usage: COMMON 683 o Registration Document(s): 684 * [RFC4002] (Updated by RFCTHIS) 685 * [RFCTHIS] 686 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 687 o Further Information: N/A 689 web:https 691 o Enumservice Class: Application-based, Common 692 o Enumservice Type: "web" 693 o Enumservice Subtype: "https" 694 o URI Scheme(s): 'https' 695 o Functional Specification: 697 * This Enumservice indicates that the resource identified by the 698 associated URI is capable of being a source of information, 699 which can be contacted by using TLS or Secure Socket Layer 700 protocol. It has to be noted that the kind of information 701 retrieved can be manifold. Usually, contacting a resource by 702 an "https:" URI provides a document. This document can contain 703 all different kind of information, like audio or video or 704 executable code. Thus, one can not be more specific what 705 information to expect when contacting the resource. 706 o Security Considerations: See Section 5 of [RFC4002] 707 o Intended Usage: COMMON 708 o Registration Document(s): 709 * [RFC4002] (Updated by RFCTHIS) 710 * [RFCTHIS] 711 o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny 712 o Further Information: N/A 714 xmpp 716 o Enumservice Class: Protocol-based 717 o Enumservice Type: "xmpp" 718 o Enumservice Subtype: N/A 719 o URI Scheme(s): 'xmpp' 720 o Functional Specification: 721 * This Enumservice indicates that the resource identified is an 722 XMPP entity. 723 o Security Considerations: See Section 6 of [RFC4979] 724 o Intended Usage: COMMON 725 o Registration Document(s): 726 * [RFC4979] (Updated by RFCTHIS) 727 * [RFCTHIS] 728 o Author(s): Alexander Mayrhofer 729 o Further Information: N/A 731 4. Security Considerations 733 Since this document does not introduce any technology or protocol, 734 there are no security issues to be considered for this document 735 itself. 737 5. Acknowledgements 739 The authors would like to thank Alfred Hoenes for his prompt feedback 740 to this document. 742 6. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, March 1997. 747 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 748 Resource Identifiers (URI) Dynamic Delegation Discovery 749 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 751 [I-D.ietf-enum-enumservices-guide] 752 Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 753 Registration of Enumservices: Guide, Template and IANA 754 Considerations", draft-ietf-enum-enumservices-guide-10 755 (work in progress), May 2008. 757 [RFC3762] Levin, O., "Telephone Number Mapping (ENUM) Service 758 Registration for H.323", RFC 3762, April 2004. 760 [RFC3764] Peterson, J., "enumservice registration for Session 761 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 762 April 2004. 764 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 765 Registration for Presence Services", RFC 3953, 766 January 2005. 768 [RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail 769 (IFAX) Service of ENUM", RFC 4143, November 2005. 771 [RFC4002] Brandner, R., Conroy, L., and R. Stastny, "IANA 772 Registration for Enumservice 'web' and 'ft'", RFC 4002, 773 February 2005. 775 [RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, 776 October 2005. 778 [RFC4355] Brandner, R., Conroy, L., and R. Stastny, "IANA 779 Registration for Enumservices email, fax, mms, ems, and 780 sms", RFC 4355, January 2006. 782 [RFC4415] Brandner, R., Conroy, L., and R. Stastny, "IANA 783 Registration for Enumservice Voice", RFC 4415, 784 February 2006. 786 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 787 Enumservice Containing Public Switched Telephone Network 788 (PSTN) Signaling Information", RFC 4769, November 2006. 790 [RFC4969] Mayrhofer, A., "IANA Registration for vCard Enumservice", 791 RFC 4969, August 2007. 793 [RFC4979] Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'", 794 RFC 4979, August 2007. 796 [RFC5028] Mahy, R., "A Telephone Number Mapping (ENUM) Service 797 Registration for Instant Messaging (IM) Services", 798 RFC 5028, October 2007. 800 [I-D.ietf-enum-calendar-service] 801 Mahy, R., "A Telephone Number Mapping (ENUM) Service 802 Registration for Internet Calendaring Services", 803 draft-ietf-enum-calendar-service-04 (work in progress), 804 March 2008. 806 Appendix A. Former Content of the IANA Repository 808 Todo: Copy-Paste from existing IANA Repository 810 Appendix B. Document Changelog 812 [RFC Editor: This section is to be removed before publication] 814 draft-hoeneisen-enum-enumservices-transition-00: 815 o bernie: integrated feedback from Alfred Hoenes 816 * Typos / corrections 817 * Removed the words "remote" and "scheme" in existing 818 registrations 819 * changed "URL" to "URI" in existing registrations 820 * changed "headers" to "header fields" in existing "mms:mailto" 821 registration 822 o bernie: Added Acknowledgements section 824 draft-hoeneisen-enum-enumservices-transition-00: 825 o bernie: Initial version 826 o bernie: Imported and adjusted existing IANA Enumservice 827 registrations 828 o bernie: Removed Name and added Class fields 829 o bernie: Put caption to each Enumservice 830 o bernie: Sorted alphabetically 831 o bernie: All URI Schemes without colon 832 o alex: Added classification 834 Appendix C. Open Issues 836 [RFC Editor: This section should be empty before publication] 837 o How can these Enumservices be changed in future? 838 o Authors of Enumservices to review the changes 839 o Maybe get rid of quotes in Type, Subtype and URI Scheme 840 o Maybe change presentation of prose parts (quotes, colons) 842 Authors' Addresses 844 Bernie Hoeneisen 845 SWITCH 846 Werdstrasse 2 847 CH-8004 Zuerich 848 Switzerland 850 Phone: +41 44 268 1515 851 Email: bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch 852 URI: http://www.switch.ch/ 854 Alexander Mayrhofer 855 enum.at GmbH 856 Karlsplatz 1/9 857 Wien A-1010 858 Austria 860 Phone: +43 1 5056416 34 861 Email: alexander.mayrhofer@enum.at 862 URI: http://www.enum.at/ 864 Full Copyright Statement 866 Copyright (C) The IETF Trust (2008). 868 This document is subject to the rights, licenses and restrictions 869 contained in BCP 78, and except as set forth therein, the authors 870 retain all their rights. 872 This document and the information contained herein are provided on an 873 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 874 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 875 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 876 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 877 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 878 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 880 Intellectual Property 882 The IETF takes no position regarding the validity or scope of any 883 Intellectual Property Rights or other rights that might be claimed to 884 pertain to the implementation or use of the technology described in 885 this document or the extent to which any license under such rights 886 might or might not be available; nor does it represent that it has 887 made any independent effort to identify any such rights. Information 888 on the procedures with respect to rights in RFC documents can be 889 found in BCP 78 and BCP 79. 891 Copies of IPR disclosures made to the IETF Secretariat and any 892 assurances of licenses to be made available, or the result of an 893 attempt made to obtain a general license or permission for the use of 894 such proprietary rights by implementers or users of this 895 specification can be obtained from the IETF on-line IPR repository at 896 http://www.ietf.org/ipr. 898 The IETF invites any interested party to bring to its attention any 899 copyrights, patents or patent applications, or other proprietary 900 rights that may cover technology that may be required to implement 901 this standard. Please address the information to the IETF at 902 ietf-ipr@ietf.org.