idnits 2.17.1 draft-ietf-enum-vmsg-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 967. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (April 16, 2008) is 5847 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) == Unused Reference: '9' is defined on line 875, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 878, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 889, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 895, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 904, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 910, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '5') ** Obsolete normative reference: RFC 2616 (ref. '11') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. '12') (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM Working Group J. Livingood 3 Internet-Draft Comcast Cable Communications 4 Expires: October 2008 D. Troshynski 5 Intended Status: Proposed Standard Acme Packet 6 April 16, 2008 8 IANA Registration of Enumservices 9 for Voice and Video Messaging 10 draft-ietf-enum-vmsg-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 18, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document registers the Enumservice named "vmsg", which is used 43 to facilitate the real-time routing of voice, video, and unified 44 communications to a messaging system. This vmsg Enumservice 45 registers three Enumservice types; "voicemsg", "videomsg", and 46 "unifmsg". Each type also registers the subtypes "sip", "sips", 47 "http", and "https", as well as the subtype "tel" for the "voicemsg" 48 type. 50 Table of Contents 52 1. Terminology....................................................2 53 2. Introduction...................................................3 54 2.1 Selected Use Cases for Illustrative Purposes...............4 55 2.2 Consideration of Other Existing Enumservices...............4 56 3. Distribution of Data...........................................5 57 4. Security Considerations........................................5 58 5. ENUM Service Registration for voicemsg.........................6 59 5.1 Registration for "voicemsg" with Subtype "sip".............6 60 5.2 Registration for "voicemsg" with Subtype "sips"............6 61 5.3 Registration for "voicemsg" with Subtype "tel".............7 62 5.4 Registration for "voicemsg" with Subtype "http"............8 63 5.5 Registration for "voicemsg" with Subtype "https"...........8 64 6. ENUM Service Registration for videomsg.........................9 65 6.1 Registration for "videomsg" with Subtype "sip".............9 66 6.2 Registration for "videomsg" with Subtype "sips"...........10 67 6.3 Registration for "videomsg" with Subtype "http"...........10 68 6.4 Registration for "videomsg" with Subtype "https"..........11 69 7. ENUM Service Registration for unifmsg.........................12 70 7.1 Registration for "unifmsg" with Subtype "sip".............12 71 7.2 Registration for "unifmsg" with Subtype "sips"............13 72 7.3 Registration for "unifmsg" with Subtype "http"............13 73 7.4 Registration for "unifmsg" with Subtype "https"...........14 74 8. Selected Examples for Illustrative Purposes...................15 75 8.1 Example Using a 'sip' URI.................................15 76 8.2 Example Using a 'tel' URI.................................15 77 8.3 Example Using a Backreference.............................15 78 8.4 Example Using a 'sip' URI Without a Telephone Number......16 79 8.5 Example of Failover Using E2U+videomsg:sip................16 80 9. Implementation Recommendations................................16 81 9.1 Call Processing When Multiple Records Are Returned........16 82 9.2 NAPTR Configuration issues................................17 83 10. IANA Considerations..........................................17 84 11. Acknowledgements.............................................17 85 12. Contributors.................................................18 86 13. References...................................................18 87 13.1 Normative References.....................................18 88 13.2 Informative References...................................19 89 Authors' Addresses...............................................19 90 Intellectual Property and Copyright Statements...................20 92 1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in BCP 14, RFC-2119 [1]. 98 2. Introduction 100 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that 101 transforms E.164 numbers (The International Public Telecommunication 102 Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and 103 then uses DNS (Domain Name System, RFC 1034 [3]) delegation through 104 NS records and NAPTR records (Dynamic Delegation Discovery System 105 (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403 106 [4]) to look up what services are available for a specific domain 107 name. 109 This document registers Enumservices according to the guidelines 110 given in RFC 3761 [1] to be used for provisioning in the services 111 field of a NAPTR [4] resource record to indicate the types of 112 functionality associated with an end point and/or telephone number. 113 The registration is defined within the DDDS (Dynamic Delegation 114 Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" 115 DDDS Application defined in RFC 3761. 117 Voice messaging systems are used widely with telephony and voice 118 communication services. The need for a voice messaging service type 119 has become clear in order to provide certain applications with direct 120 access to various voice messaging services, for example voicemail, 121 most typically via the use of SIP. 123 The authors considered the use of VPIM [14] but found that VPIM was 124 best suited to the non-real-time and non-session-based routing of a 125 voice message once it had been deposited into a voice messaging 126 system. Thus, VPIM was a good solution for the non-real-time and 127 non-session-based routing of voice messages between and within 128 domains, but it did not enable real-time interaction with a voice 129 messaging system. 131 Thus, a need has been identified for this voice messaging service 132 type that would enable, for example some of the use cases listed in 133 this section. 135 Video messaging systems, sometimes called visual voice messaging 136 systems, are beginning to be used with real-time communication 137 services. The need for a video messaging service type has become 138 clear in order to provide certain applications with direct access to 139 various video messaging services, most typically via the use of SIP. 140 Thus, a need has been identified for this video messaging service 141 type that would enable, for example some of the use cases listed in 142 this section. 144 Finally, several service providers and software developers have 145 indicated that their system for voice messaging and video messaging 146 either have been or soon will be unified into a single system. As 147 such, they desired to have the option of using an Enumservice type 148 that represents a subscriber's mailbox as being a so-called "unified 149 messaging" repository. Thus, a need has been identified for this 150 unified voice and video messaging service type that would enable, for 151 example some of the use cases listed in this section. 153 2.1 Selected Use Cases for Illustrative Purposes 155 The following is a partial, non-exclusive list of use cases that the 156 vmsg Enumservice could address: 158 * A called party is busy or does not answer a call. A client or 159 server then determines that a messaging service should be used and 160 sends the calling party's session to such a service. The client or 161 server needs to be able to determine which server to direct this 162 real-time session to, whether that is within or outside of the called 163 party's domain. 165 * Similar to the above use case, a real-time session is attempted to 166 a messaging system, but that system is currently unavailable. Since 167 multiple service type records may be returned by the original ENUM 168 query, the client or server could then attempt to initiate a session 169 with one or more backup messaging servers in a manner which is 170 transparent to the calling party, and which supports better overall 171 availability of a messaging service. 173 * Similar to the above use case, this service type could be used to 174 balance load across multiple messaging servers, whether those are in 175 the same or in different physical locations. 177 * A user with an account on a messaging service needs to connect to 178 the messaging service in order to retrieve messages. They initiate a 179 real-time session and an ENUM query is performed to discover the 180 messaging server that holds their mailbox. 182 * In the process of invoking and supporting a real-time, automated 183 and interactive session with a user, whether for message deposit or 184 retrieval, VoiceXML files are referenced and utilized, via either 185 HTTP or HTTPS. Multiple VoiceXML servers could be associated with a 186 user and returned via ENUM query, for the purposes of load balancing, 187 for example. 189 2.2 Consideration of Other Existing Enumservices 191 The authors considered whether this service type could simply use the 192 SIP Enumservice type [19], but found that it does not satisfy their 193 voice messaging requirements, particularly given the non-SIP URI sub- 194 types specified herein. Even with sub-types for SIP URIs, however, 195 there are challenges to using the SIP Enumservice type. For example, 196 a request for access to such a service could be extended to the 197 requesting SIP client, or User Agent Client (UAC), rather than 198 relying upon the local policy of a SIP server, or User Agent Server 199 (UAS), which means that special routing logic within a UAS cannot be 200 relied upon to solve this problem. More importantly, however, the 201 authors have found that without this service type, a UAC or UAS will 202 be presented with multiple SIP URIs, with no ability other than in 203 non-standards-based routing rules or application logic to recognize 204 which one is related to a voice messaging, video messaging, or 205 unified voice and video messaging service. 207 3. Distribution of Data 209 The authors believe that it is more likely that these records will be 210 distributed on a purely private basis, but they may also be 211 distributed in public ENUM trees. Distribution of this NAPTR data 212 could be either (a) on a private basis within a service provider's 213 internal network, (b) on a private basis between one or more parties 214 using a variety of security mechanisms to prohibit general public 215 access, or (c) openly available. 217 4. Security Considerations 219 DNS, as used by ENUM, is a global, distributed database. Should 220 implementers of this specification use e164.arpa or any other 221 publicly available domain as the tree for maintaining voicemsg 222 Enumservice data, this information would be visible to anyone 223 anonymously. While this is not qualitatively different from 224 publication in a Telephone Directory, it does open or ease access to 225 such data without any indication that such data has been accessed or 226 by whom it has been accessed. 228 Such data harvesting by third parties is often used to generate lists 229 of targets for unsolicited information. Thus, a third party could use 230 this to generate a list that they can use to make unsolicited 231 "telemarketing" phone calls, or so-called SPAM over Internet 232 Telephony (SPIT). Many countries have do-not-call registries or other 233 legal or regulatory mechanisms in place to deal with such abuses. 235 As noted earlier carriers, service providers, and other users may 236 simply choose not to publish such information in the public e164.arpa 237 tree, but may instead simply publish this in their internal ENUM 238 routing database that is only able to be queried by trusted elements 239 of their network and/or partner networks, such as softswitches and 240 SIP proxy servers. They may also choose to publish such information 241 in a carrier-only branch of the e164.arpa tree, should one be 242 created. 244 Although an E.164 telephone number does not appear to reveal as much 245 identity information about a user as a name in the format 246 sip:username@hostname or email:username@hostname, the information is 247 still publicly available, thus there is still the risk of unwanted 248 communication. 250 An analysis of threats specific to the dependence of ENUM on the DNS 251 and the applicability of DNSSEC [16] to this is provided in RFC 3761 252 [1]. A thorough analysis of threats to the DNS itself is covered in 253 RFC 3833 [17]. 255 5. ENUM Service Registration for voicemsg 257 5.1 Registration for "voicemsg" with Subtype "sip" 259 Enumservice Name: "voicemsg" 261 Enumservice Type: "voicemsg" 263 Enumservice Subtypes: "sip" 265 URI Schemes: 'sip:' 267 Functional Specification: 269 This Enumservice indicates that the remote resource identified can be 270 addressed by the associated URI scheme in order to initiate a voice 271 communication session to a voice messaging system. 273 Security Considerations: See Section 4. 275 Intended Usage: COMMON 277 Authors: 279 Jason Livingood (jason_livingood@cable.comcast.com) 280 Don Troshynski (dtroshynski@acmepacket.com) 282 Any other information the author deems interesting: 284 Implementers should review a non-exclusive list of examples below in 285 Section 8. 287 5.2 Registration for "voicemsg" with Subtype "sips" 289 Enumservice Name: "voicemsg" 291 Enumservice Type: "voicemsg" 292 Enumservice Subtypes: "sips" 294 URI Schemes: 'sips:' 296 Functional Specification: 298 This Enumservice indicates that the remote resource identified can be 299 addressed by the associated URI scheme in order to initiate a voice 300 communication session to a voice messaging system. 302 Security Considerations: See Section 4. 304 Intended Usage: COMMON 306 Authors: 308 Jason Livingood (jason_livingood@cable.comcast.com) 309 Don Troshynski (dtroshynski@acmepacket.com) 311 Any other information the author deems interesting: 313 Implementers should review a non-exclusive list of examples below in 314 Section 8. 316 5.3 Registration for "voicemsg" with Subtype "tel" 318 Enumservice Name: "voicemsg" 320 Enumservice Type: "voicemsg" 322 Enumservice Subtype: "tel" 324 URI Schemes: 'tel:' 326 Functional Specification: 328 This Enumservice indicates that the remote resource identified can be 329 addressed by the associated URI scheme in order to initiate a voice 330 communication session to a voice messaging system. 332 Security Considerations: See Section 4. 334 Intended Usage: COMMON 336 Authors: 338 Jason Livingood (jason_livingood@cable.comcast.com) 339 Don Troshynski (dtroshynski@acmepacket.com) 340 Any other information the author deems interesting: 342 Implementers should review a non-exclusive list of examples below in 343 Section 8. 345 5.4 Registration for "voicemsg" with Subtype "http" 347 Enumservice Name: "voicemsg" 349 Enumservice Type: "voicemsg" 351 Enumservice Subtype: "http" 353 URI Schemes: 'http:' 355 Functional Specification: 357 This Enumservice indicates that the remote resource identified by the 358 associated URI scheme is capable of being a source of information. 360 Note that the kind of information retrieved can be manifold. 361 Usually, contacting a resource by an 'http:' [11] URI provides a 362 document. This document can contain references that will trigger the 363 download of many different kinds of information, such as text, audio, 364 video, executable code, or even voice message files. Thus, one 365 cannot be more specific about the kind of information expected when 366 contacting the resource. 368 Security Considerations: See Section 4. 370 Intended Usage: COMMON 372 Authors: 374 Jason Livingood (jason_livingood@cable.comcast.com) 375 Don Troshynski (dtroshynski@acmepacket.com) 377 Any other information the author deems interesting: 379 Implementers should review a non-exclusive list of examples below in 380 Section 8. 382 5.5 Registration for "voicemsg" with Subtype "https" 384 Enumservice Name: "voicemsg" 386 Enumservice Type: "voicemsg" 388 Enumservice Subtype: "https" 389 URI Schemes: 'https:' 391 Functional Specification: 393 This Enumservice indicates that the remote resource identified by the 394 associated URI scheme is capable of being a source of information, 395 which can be contacted using TLS or the Secure Socket Layer protocol. 397 Note that the kind of information retrieved can be manifold. 398 Usually, contacting a resource by an 'https:' [12] URI provides a 399 document. This document can contain references that will trigger the 400 download of many different kinds of information, such as text, audio, 401 video, executable code, or even voice message files. Thus, one 402 cannot be more specific about the kind of information expected when 403 contacting the resource. 405 Security Considerations: See Section 4. 407 Intended Usage: COMMON 409 Authors: 411 Jason Livingood (jason_livingood@cable.comcast.com) 412 Don Troshynski (dtroshynski@acmepacket.com) 414 Any other information the author deems interesting: 416 Implementers should review a non-exclusive list of examples below in 417 Section 8. 419 6. ENUM Service Registration for videomsg 421 6.1 Registration for "videomsg" with Subtype "sip" 423 Enumservice Name: "videomsg" 425 Enumservice Type: "videomsg" 427 Enumservice Subtypes: "sip" 429 URI Schemes: 'sip:' 431 Functional Specification: 433 This Enumservice indicates that the remote resource identified can be 434 addressed by the associated URI scheme in order to initiate a video 435 communication session to a video messaging system. 437 Security Considerations: See Section 4. 439 Intended Usage: COMMON 441 Authors: 443 Jason Livingood (jason_livingood@cable.comcast.com) 444 Don Troshynski (dtroshynski@acmepacket.com) 446 Any other information the author deems interesting: 448 Implementers should review a non-exclusive list of examples below in 449 Section 8. 451 6.2 Registration for "videomsg" with Subtype "sips" 453 Enumservice Name: "videomsg" 455 Enumservice Type: "videomsg" 457 Enumservice Subtypes: "sips" 459 URI Schemes: 'sips:' 461 Functional Specification: 463 This Enumservice indicates that the remote resource identified can be 464 addressed by the associated URI scheme in order to initiate a video 465 communication session to a video messaging system. 467 Security Considerations: See Section 4. 469 Intended Usage: COMMON 471 Authors: 473 Jason Livingood (jason_livingood@cable.comcast.com) 474 Don Troshynski (dtroshynski@acmepacket.com) 476 Any other information the author deems interesting: 478 Implementers should review a non-exclusive list of examples below in 479 Section 8. 481 6.3 Registration for "videomsg" with Subtype "http" 483 Enumservice Name: "videomsg" 484 Enumservice Type: "videomsg" 486 Enumservice Subtype: "http" 488 URI Schemes: 'http:' 490 Functional Specification: 492 This Enumservice indicates that the remote resource identified by the 493 associated URI scheme is capable of being a source of information. 495 Note that the kind of information retrieved can be manifold. 496 Usually, contacting a resource by an 'http:' [11] URI provides a 497 document. This document can contain references that will trigger the 498 download of many different kinds of information, such as text, audio, 499 video, executable code, or even video message files. Thus, one 500 cannot be more specific about the kind of information expected when 501 contacting the resource. 503 Security Considerations: See Section 4. 505 Intended Usage: COMMON 507 Authors: 509 Jason Livingood (jason_livingood@cable.comcast.com) 510 Don Troshynski (dtroshynski@acmepacket.com) 512 Any other information the author deems interesting: 514 Implementers should review a non-exclusive list of examples below in 515 Section 8. 517 6.4 Registration for "videomsg" with Subtype "https" 519 Enumservice Name: "videomsg" 521 Enumservice Type: "videomsg" 523 Enumservice Subtype: "https" 525 URI Schemes: 'https:' 527 Functional Specification: 529 This Enumservice indicates that the remote resource identified by the 530 associated URI scheme is capable of being a source of information, 531 which can be contacted using TLS or the Secure Socket Layer protocol. 533 Note that the kind of information retrieved can be manifold. 534 Usually, contacting a resource by an 'https:' [12] URI provides a 535 document. This document can contain references that will trigger the 536 download of many different kinds of information, such as text, audio, 537 video, executable code, or even video message files. Thus, one 538 cannot be more specific about the kind of information expected when 539 contacting the resource. 541 Security Considerations: See Section 4. 543 Intended Usage: COMMON 545 Authors: 547 Jason Livingood (jason_livingood@cable.comcast.com) 548 Don Troshynski (dtroshynski@acmepacket.com) 550 Any other information the author deems interesting: 552 Implementers should review a non-exclusive list of examples below in 553 Section 8. 555 7. ENUM Service Registration for unifmsg 557 7.1 Registration for "unifmsg" with Subtype "sip" 559 Enumservice Name: "unifmsg" 561 Enumservice Type: "unifmsg" 563 Enumservice Subtypes: "sip" 565 URI Schemes: 'sip:' 567 Functional Specification: 569 This Enumservice indicates that the remote resource identified can be 570 addressed by the associated URI scheme in order to initiate a unified 571 communication session to a unified messaging system. 573 Security Considerations: See Section 4. 575 Intended Usage: COMMON 577 Authors: 579 Jason Livingood (jason_livingood@cable.comcast.com) 580 Don Troshynski (dtroshynski@acmepacket.com) 581 Any other information the author deems interesting: 583 Implementers should review a non-exclusive list of examples below in 584 Section 8. 586 7.2 Registration for "unifmsg" with Subtype "sips" 588 Enumservice Name: "unifmsg" 590 Enumservice Type: "unifmsg" 592 Enumservice Subtypes: "sips" 594 URI Schemes: 'sips:' 596 Functional Specification: 598 This Enumservice indicates that the remote resource identified can be 599 addressed by the associated URI scheme in order to initiate a unified 600 communication session to a unified messaging system. 602 Security Considerations: See Section 4. 604 Intended Usage: COMMON 606 Authors: 608 Jason Livingood (jason_livingood@cable.comcast.com) 610 Any other information the author deems interesting: 612 Implementers should review a non-exclusive list of examples below in 613 Section 8. 615 7.3 Registration for "unifmsg" with Subtype "http" 617 Enumservice Name: "unifmsg" 619 Enumservice Type: "unifmsg" 621 Enumservice Subtype: "http" 623 URI Schemes: 'http:' 625 Functional Specification: 627 This Enumservice indicates that the remote resource identified by the 628 associated URI scheme is capable of being a source of information. 630 Note that the kind of information retrieved can be manifold. 631 Usually, contacting a resource by an 'http:' [11] URI provides a 632 document. This document can contain references that will trigger the 633 download of many different kinds of information, such as text, audio, 634 video, executable code, or even video message files. Thus, one 635 cannot be more specific about the kind of information expected when 636 contacting the resource. 638 Security Considerations: See Section 4. 640 Intended Usage: COMMON 642 Authors: 644 Jason Livingood (jason_livingood@cable.comcast.com) 645 Don Troshynski (dtroshynski@acmepacket.com) 647 Any other information the author deems interesting: 649 Implementers should review a non-exclusive list of examples below in 650 Section 8. 652 7.4 Registration for "unifmsg" with Subtype "https" 654 Enumservice Name: "unifmsg" 656 Enumservice Type: "unifmsg" 658 Enumservice Subtype: "https" 660 URI Schemes: 'https:' 662 Functional Specification: 664 This Enumservice indicates that the remote resource identified by the 665 associated URI scheme is capable of being a source of information, 666 which can be contacted using TLS or the Secure Socket Layer protocol. 668 Note that the kind of information retrieved can be manifold. 669 Usually, contacting a resource by an 'https:' [12] URI provides a 670 document. This document can contain references that will trigger the 671 download of many different kinds of information, such as text, audio, 672 video, executable code, or even video message files. Thus, one 673 cannot be more specific about the kind of information expected when 674 contacting the resource. 676 Security Considerations: See Section 4. 678 Intended Usage: COMMON 679 Authors: 681 Jason Livingood (jason_livingood@cable.comcast.com) 682 Don Troshynski (dtroshynski@acmepacket.com) 684 Any other information the author deems interesting: 686 Implementers should review a non-exclusive list of examples below in 687 Section 8. 689 8. Selected Examples for Illustrative Purposes 691 The following sub-sections document several examples that 692 implementers may find informative. These examples shall in no way 693 limit the various forms that this Enumservice may take. 695 8.1 Example Using a 'sip' URI 697 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 698 NAPTR 10 100 "u" "E2U+voicemsg:sip" 699 "!^.*$!sip:12155550123@gw.example.com!". 701 In this example, a calling party has attempted a session which has 702 gone unanswered after a certain period of time. The calling party's 703 session is sent to the appropriate voice messaging server, a 704 personalized greeting is played to the calling party, after which 705 they record a voice message to the called party. 707 8.2 Example Using a 'tel' URI 709 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 710 NAPTR 10 100 "u" "E2U+voicemsg:tel" 711 "!^.*$!tel:1-215-555-0123!". 713 In this example, a calling party has attempted a session which has 714 gone unanswered after a certain period of time. The calling party's 715 session is sent to the appropriate voice messaging server, a 716 personalized greeting is played to the calling party, after which 717 they record a voice message to the called party. 719 8.3 Example Using a Backreference 721 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 722 NAPTR 10 100 "u" "E2U+voicemsg:sip" 723 "!(^.*)$!sip:\1@example.net!". 725 In this example, a backreference is used to reduce the size of the 726 NAPTR record. The sip URI uses "\1" which would dynamically replace 727 the expression with the TN, in this case +12155550123. 729 8.4 Example Using a 'sip' URI Without a Telephone Number 731 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 732 NAPTR 10 100 "u" "E2U+voicemsg:sip" 733 "!^.*$!sip:johndoe@gw.example.com!". 735 In this example, a calling party has attempted a session which has 736 gone unanswered after a certain period of time. The calling party's 737 session is sent to the appropriate voice messaging server, a 738 personalized greeting is played to the calling party, after which 739 they record a voice message to the called party. The URI that this 740 session is directed to does not include a telephone number, as this 741 user has multiple service that are not particularly tied to telephone 742 numbers whereby text, audio, video and other multimedia messages can 743 be received and accessed. 745 8.5 Example of Failover Using E2U+videomsg:sip 747 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 748 NAPTR 10 100 "u" "E2U+videomsg:sip" 749 "!^.*$!sip:12155550123@gw1.example.com!". 751 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 752 NAPTR 10 200 "u" "E2U+videomsg:sip" 753 "!^.*$!sip:12155550123@gw2.example.com!". 755 In this example, the preference indicates that gw1.example.com is 756 used first (100), and if this is unreachable, then the next higher 757 preference (200) is used and gw2.example.com is contacted. While out 758 of scope for this document, a service provider could thus mirror or 759 cluster a message store and fail from the primary to secondary using 760 the DNS in an active-standby mode. 762 9. Implementation Recommendations 764 9.1 Call Processing When Multiple Records Are Returned 766 It is likely that that both E2U+sip and E2U+voicemsg, E2U+videomsg, 767 and/or E2U+unifmsg Enumservice type records will be returned for a 768 given query. In this case, this could result in what is essentially 769 E2U+sip records for real-time communications with an end user, while, 770 for example, the E2U+voicemsg records will be used for real-time 771 communications with a voice messaging service, when the called party 772 is not available or does not wish to be disturbed. Therefore, the 773 network element that receives the results of this ENUM query will 774 need to know enough information in order to select the voicemsg 775 service type, rather than the sip service type. 777 In addition, it is likely that multiple E2U+voicemsg, E2U+videomsg, 778 and/or E2U+unifmsg Enumservice type records will be returned for a 779 given query. In this case, multiple records may include order and 780 preference to allow recursion or load balancing. Order could be used 781 to designate a primary and a backup voice, video, or unified voice 782 and video messaging service. Preference could be used to load 783 balance across multiple voice, video, and/or unified voice and video 784 messaging servers by weight, for example. 786 Finally, as with multiple records resulting from a typical ENUM query 787 of the e164.arpa tree, it is up to the application using an ENUM 788 resolver to determine which record(s) to use and which record(s) to 789 ignore. Implementers should take this into consideration and build 790 logic into their applications that can select appropriately from 791 multiple records based on business, network, or other rules. 793 9.2 NAPTR Configuration issues 795 Implementers may wish to consider using regular expressions in order 796 to reduce the size of individual NAPTRs. This will have a 797 significant effect on the overall size of the database involved. 799 10. IANA Considerations 801 This document registers the 'voicemsg' Enumservice type and the 802 subtype "tel", "sip", "sips", "http", and "https" under the 803 Enumservice registry described in the IANA considerations in RFC 804 3761. Details of this registration are provided in Section 5 of this 805 document. 807 This document registers the 'videomsg' Enumservice type and the 808 subtype "sip", "sips", "http", and "https" under the Enumservice 809 registry described in the IANA considerations in RFC 3761. Details 810 of this registration are provided in Section 6 of this document. 812 This document registers the 'unifmsg' Enumservice type and the 813 subtype "sip", "sips", "http", and "https" under the Enumservice 814 registry described in the IANA considerations in RFC 3761. Details 815 of this registration are provided in Section 7 of this document. 817 11. Acknowledgements 819 The authors thank Rich Ferrise, Chris Harvey, Tong Zhou, and Hadriel 820 Kaplan for their detailed assistance in developing the ideas behind 821 this document in numerous brainstorming sessions, with information 822 gleaned from their work to solve real application architecture 823 issues. The authors also thank Lawrence Conroy and Jean-Francois Mule 824 for their feedback in developing this document. 826 12. Contributors 828 Tong Zhou 829 Comcast Cable Communications 830 Email: tong_zhou@cable.comcast.com 832 Richard Ferrise 833 Comcast Cable Communications 834 Email: rich_ferrise@cable.comcast.com 836 Chris Harvey 837 Comcast Cable Communications 838 Email: chris_harvey@cable.comcast.com 840 Hadriel Kaplan 841 Acme Packet 842 Email: hkaplan@acmepacket.com 844 13. References 846 13.1 Normative References 848 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 849 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 850 Application (ENUM)", RFC 3761, April 2004. 852 [2] ITU-T, "The International Public Telecommunication Number Plan", 853 Recommendation E.164, May 1997. 855 [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 856 1034, November 1987. 858 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 859 Three: The Domain Name System (DNS) Database", RFC 3403, October 860 2002. 862 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 863 One: The Comprehensive DDDS", RFC 3401, October 2002. 865 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 866 Two: The Algorithm", RFC 3402, October 2002. 868 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 869 Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 870 2002. 872 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 873 Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. 875 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 876 December 2004. 878 [10] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 879 3261, June 2002. 881 [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 882 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 883 HTTP/1.1", RFC 2616, June 1999. 885 [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 887 13.2 Informative References 889 [13] Peterson, J., et al., "Using E.164 Numbers with the Session 890 Initiation Protocol (SIP)", RFC 3824, June 2004. 892 [14] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, 893 October 2005. 895 [15] Bradner, et al., "IANA Registration for Enumservices email, fax, 896 mms, ems and sms", RFC 4355, January 2006. 898 [16] Arends, R. and et al., "Protocol Modifications for the DNS 899 Security Extensions", RFC 4035, March 2005. 901 [17] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name 902 System (DNS)", RFC 3833, August 2004. 904 [18] Foster, M., McGarry, T., and Yu, J., "Number Portability in the 905 GSTN: An Overview", RFC 3482, February 2003. 907 [19] Peterson, J., "enumservice Registration for Session Initiation 908 Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. 910 [20] Bradner, et al., "IANA Registration for Enumservice 'web' and 911 'ft', RFC 4022, February 2005. 913 Authors' Addresses 915 Jason Livingood 916 Comcast Cable Communications 917 One Comcast Center 918 1701 John F. Kennedy Boulevard 919 Philadelphia, PA 19103 920 USA 921 Email: jason_livingood@cable.comcast.com 923 Donald Troshynski 924 Acme Packet 925 Email: dtroshynski@acmepacket.com 927 Intellectual Property and Copyright Statements 929 Full Copyright Statement 931 Copyright (C) The IETF Trust (2008). 933 This document is subject to the rights, licenses and restrictions 934 contained in BCP 78, and except as set forth therein, the authors 935 retain all their rights. 937 This document and the information contained herein are provided on an 938 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 939 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 940 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 941 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 942 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 943 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 945 Intellectual Property 947 The IETF takes no position regarding the validity or scope of any 948 Intellectual Property Rights or other rights that might be claimed to 949 pertain to the implementation or use of the technology described in 950 this document or the extent to which any license under such rights 951 might or might not be available; nor does it represent that it has 952 made any independent effort to identify any such rights. Information 953 on the procedures with respect to rights in RFC documents can be 954 found in BCP 78 and BCP 79. 956 Copies of IPR disclosures made to the IETF Secretariat and any 957 assurances of licenses to be made available, or the result of an 958 attempt made to obtain a general license or permission for the use of 959 such proprietary rights by implementers or users of this 960 specification can be obtained from the IETF on-line IPR repository at 961 http://www.ietf.org/ipr. 963 The IETF invites any interested party to bring to its attention any 964 copyrights, patents or patent applications, or other proprietary 965 rights that may cover technology that may be required to implement 966 this standard. Please address the information to the IETF at ietf- 967 ipr@ietf.org. 969 Acknowledgment 971 Funding for the RFC Editor function is currently provided by the IETF 972 Administrative Support Activity (IASA).