idnits 2.17.1 draft-brandner-enumservice-vovi-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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 387. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 393), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 422 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7197 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 section? '4' on line 305 looks like a reference -- Missing reference section? '3' on line 302 looks like a reference -- Missing reference section? '5' on line 308 looks like a reference -- Missing reference section? '6' on line 310 looks like a reference -- Missing reference section? '7' on line 312 looks like a reference -- Missing reference section? '8' on line 315 looks like a reference -- Missing reference section? '9' on line 318 looks like a reference -- Missing reference section? '11' on line 325 looks like a reference -- Missing reference section? '12' on line 328 looks like a reference -- Missing reference section? '13' on line 332 looks like a reference -- Missing reference section? '10' on line 321 looks like a reference -- Missing reference section? '1' on line 298 looks like a reference -- Missing reference section? '2' on line 300 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ENUM Working Group R. Brandner 2 Internet Draft Siemens 3 L. Conroy 4 Siemens Roke Manor Research 5 R. Stastny 6 OeFEG 7 Expires: January 2005 July 2004 9 IANA Registration for enumservices voice and video 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document registers the ENUMservices "voice" and "video" (each of 41 which has a defined sub-type "tel"), as per the IANA registration 42 process defined in the ENUM specification RFC3761[4]. These services 43 are be used to indicate that the contact held in the generated URI 44 can be used to initiate an interactive voice or video/audio call 45 respectively. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119 [3]. 53 1. Introduction 55 RFC3761 [4] (ENUM) describes a machanism to populate communication 56 contacts within DNS [5] associated with an E.164 [6] number, using 57 NAPTRs [7] that hold the DDDS [8][9] Application identifier "E2U". 58 It defines a framework whereby the person controlling its population 59 may indicate the kind of communication that can result from using 60 the contact. This indication is called an ENUMservice, and there may 61 be more than one ENUMservice associated with a single NAPTR, where 62 the contact may be used to initiate more than one kind of 63 communication. 65 ENUMservices have a type and subtype. This latter is optional, as it 66 may be implicit in the service type. The type defines the kind of 67 communication session that can be initiated using the contact 68 indicated by the URI generated by the enclosing NAPTR. The sub-type 69 defines the subsystem that is to be used to initiate the 70 communication session. Note that the sub-type definition includes 71 the URI style that is to be used. Both the type and subtype (where 72 present) must be supported for the NAPTR to be used by a potential 73 correspondent. 75 Whilst the protocol elements that make up ENUM are defined in the 76 above documents and in this one, further examples of the use to 77 which these may be put are given in other documents, for example in 78 ETSI TS 102 172 [11]. 80 There are a number of DDDS Applications in addition to ENUM (for 81 example, see [12] and [13]). However, an ENUMservice indication 82 operates only within the context of the "E2U" (ENUM) DDDS 83 Application. 85 That context is specified in RFC3761, and requires a a standards 86 track or experimental RFC to define the expectations for the 87 ENUMservice, to be referred to in the IANA registry of ENUMservices. 88 This document is the defining document for the ENUMservices "voice" 89 and "video". 91 2. ENUMservice for Interactive Voice 93 ENUMservice Type: 94 "Voice" 96 The kind of communication indicated by this ENUMservice is 97 "Interactive Voice". From a protocol perspective, this 98 communication is expected to involve bidirectional media streams 99 carrying audio data. 101 A client may imply that the person controlling population of a 102 NAPTR holding this ENUMservice indicates their capability to engage 103 in an interactive voice session when contacted using the URI 104 generated by this NAPTR. 106 2.1. Defined Sub-types for Interactive Voice 108 2.1.1 ENUMservice "Voice" Sub-type "Tel" 110 Sub-type: 111 "tel" 113 Generated URI scheme: 114 "tel:" (defined in RFC2806 [10]) 116 This sub-type indicates that the person responsible for the NAPTR 117 is accessible via the PSTN (Public Switched Telephone Network) or 118 PLMN (Public Land Mobile Network) using the value of the generated 119 URI. 121 The kind of subsystem required to initiate a Voice ENUMservice with 122 this sub-type is a "Dialler". This is a subsystem that either 123 provides a local connection to the PSTN or PLMN, or that provides 124 an indirect connection to those networks. The subsystem will use 125 the telephone number held in the generated URI to place a voice 126 call. The voice call is placed to a network that uses E.164 numbers 127 to route calls to an appropriate destination. 129 Note that the PLMN connection may be indirect. The end user 130 receiving this NAPTR may have a relationship with a Communications 131 Service Provider that accepts call initiation requests from that 132 subsystem using an IP-based protocol such as SIP or H.323, and 133 places the call to the PSTN using a remote gateway service. In this 134 case the Provider may either accept requests using "tel:" URIs or 135 has a defined mechanism to convert "tel:" URI values into a 136 "protocol-native" form. 138 The "tel:" URI value SHOULD be fully qualified (using the "global 139 phone number" form of RFC2806 [10]). A "local phone number" [10] 140 SHOULD NOT be used unless the controller of the zone in which the 141 NAPTR appears is sure that it can be distinguished unambiguously by 142 all clients that can access the resouce record and that a call from 143 their network access points can be routed to that destination. 145 2.1.1.2 Security Considerations 146 See main security considerations section of this document. 148 2.1.1.3. Intended Usage of ENUMservice Voice 149 COMMON 151 2.1.1.4. Authors 152 Rudolf Brandner, Lawrence Conroy, Richard Stastny 153 (for author contact detail see section 9) 155 2.1.1.5. Other Information Author Deems Interesting 156 NONE 158 3. ENUMservice for Interactive Video 160 ENUMservice Type: 161 "video" 163 The kind of communication indicated by this ENUMservice is 164 "Interactive Video and Voice". From a protocol perspective, this 165 communication is expected to involve bidirectional media streams 166 carrying video and audio data. 168 A client may imply that the person controlling population of a 169 NAPTR holding this ENUMservice indicates their capability to engage 170 in an interactive video and voice session when contacted using the 171 URI generated by this NAPTR. 173 3.1. Defined Sub-types for Interactive Video 175 3.1.1. ENUMservice "Video" sub-type "Tel" 177 Sub-type: 178 "tel" 180 Generated URI scheme: 181 "tel:" (defined in RFC2806 [10]) 183 There are existing Video/Voice services provided over the telephone 184 network, and this ENUMservice indicates that the destination has 185 such a service. Specifically, this sub-type indicates that the 186 person responsible for the NAPTR is accessible via the PSTN (Public 187 Switched Telephone Network) or PLMN (Public Land Mobile Network) 188 using the value of the generated URI. 190 The kind of subsystem required to initiate a Voice ENUMservice with 191 this sub-type is a "Dialler". This is a subsystem that either 192 provides a local connection to the PSTN or PLMN, or that provides 193 an indirect connection to those networks. The subsystem will use 194 the telephone number held in the generated URI to place a call via 195 the PSTN/PLMN network connection. See also section 2.1.1 above. 197 3.1.1.2 Security Considerations 198 See main security considerations section of this document. 200 3.1.1.3. Intended Usage of ENUMservice Voice 201 COMMON 203 3.1.1.4. Authors 204 Rudolf Brandner, Lawrence Conroy, Richard Stastny 205 (for author contact detail see section 9) 207 3.1.1.5. Other Information Author Deems Interesting 208 NONE 210 4. Additional Information 212 NONE 214 5. Security Considerations 216 DNS, as used by ENUM, is a global, distributed database. Thus any 217 information stored there is visible to anyone anonymously. Whilst 218 this is not qualitatively different from publication in a Telephone 219 Directory, it does open the data subject to having "their" 220 information collected automatically without any indication that this 221 has been done or by whom. 223 Such data harvesting by third parties is often used to generate 224 lists of targets for unrequested information; in short, they are 225 used to address "spam". Anyone who uses a Web-archived mailing list 226 is aware that the volume of "spam" email they are sent increases 227 when they post to the mailing list; publication of a telephone 228 number in ENUM is no different, and may be used to send "junk faxes" 229 or "junk SMS" for example. 231 Many mailing list users have more than one email address and use 232 "sacrificial" email accounts when posting to such lists to help 233 filter out unrequested emails sent to them. This is not so easy with 234 published telephone numbers; the PSTN E.164 number assignment 235 process is much more involved and usually a single E.164 number (or 236 a fixed range of numbers) is associated with each PSTN access. Thus 237 providing a "sacrificial" phone number in any publication is not 238 possible. 240 Due to the implications of publishing data on a globally accessible 241 database, as a principle the data subject MUST give their explicit 242 informed consent to data being published in ENUM. 244 In addition, they should be made aware that, due to storage of such 245 data during harvesting by third parties, removal of the data from 246 publication will not remove any copies that have been taken; in 247 effect, any publication may be permanent. 249 However, regulations in many regions will require that the data 250 subject can at any time request that the data is removed from 251 publication, and that their consent for its publication is 252 explicitly confirmed at regular intervals. 254 When placing a voice or video call via the PSTN or sending a message 255 via the Public Land Mobile Network, the sender may be charged for 256 this action. In both kinds of network, calling or messaging to some 257 numbers is more expensive than sending to others; both networks have 258 "premium rate" services that can charge considerably more than a 259 "normal" call or message destination. As such, it is important that 260 the end user be asked to confirm sending the message, and that the 261 destination number be presented to them. It is the originating 262 user's choice on whether or not to place a call to this destination 263 number, but they SHOULD be shown the destination number so that they 264 can make this decision 266 Where voice or video terminals are configured to accept incoming 267 calls, there SHOULD be an indication presented to the user that an 268 incoming call is being offered. Particularly with some video 269 systems, the terminal may be configured to "auto-accept" the call. 270 In this case there MUST be an obvious indication presented to the 271 called user that this has been done. 273 Systems configured to auto-accept audio/video calls that are sent to 274 a number published in a global public directory may be used by 275 unexpected individuals to check for the presence or otherwise of 276 people with a view to stealing property or other unwelcome acts. 277 Whilst "security through obscurity" may have seemed acceptable when 278 the access address was known to only a few, publication within ENUM 279 removes the obscurity, so leaving (for example) a "WebCam" switched 280 on after such publication is even less wise than in other 281 situations. 283 In addition to the specific security considerations given above, all 284 security considerations given in RFC3761 apply. 286 6. IANA Considerations 288 This document requests that IANA adds entries to the Registry of 289 ENUMservices set up as defined in the framework of RFC3761 for: 290 - ENUMservice type "voice" with sub-type "tel", and for 291 - ENUMservice type "video" with sub-type "tel". 293 This document defines these ENUMservices and should be referred to 294 in the Registry entries as their specification. 296 7. Normative References: 298 [1] Bradner, S., "Intellectual Property Rights in IETF Technology", 299 BCP 78, RFC3667, February 2004 300 [2] Bradner, S., "IETF Rights in Contributions", BCP 79, RFC3668, 301 February 2004 302 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 303 Levels", BCP 14, RFC 2119, March 1997 305 [4] Faltstrom, P. and Mealling M., "The E.164 to Uniform Resource 306 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 307 Application (ENUM)", RFC 3761, April 2004. 308 [5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 309 13, RFC 1034, November 1987 310 [6] ITU-T, "The International Public Telecommunication Number Plan", 311 Recommendation E.164, May 1997 312 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 313 Three: The Domain Name System (DNS) Database", RFC 3403, October 314 2002. 315 [8] M. Mealling, RFC 3401, 316 "Dynamic Delegation Discovery System (DDDS) Part One: 317 The Comprehensive DDDS", October 2002 318 [9] M. Mealling, RFC 3402, 319 "Dynamic Delegation Discovery System (DDDS) Part Two: 320 The Algorithm", October 2002 321 [10] A. Vaha-Sipila, RFC 2806, "URLs for Telephone Calls", April 2000 323 8. Informative References: 325 [11] ETSI TS 102 172, 326 "Minimum Requirements for Interoperability of European ENUM 327 Trials", July 2004 328 [12] M. Mealling, RFC 3404, 329 "Dynamic Delegation Discovery System (DDDS) Part Four: 330 The Uniform Resource Identifiers (URI) Resolution 331 Application", October 2002 332 [13] M. Mealling, RFC 3405, 333 "Dynamic Delegation Discovery System (DDDS) Part Five: 334 URI.ARPA Assignment Procedures", October 2002 336 9. Authors' Addresses 338 Rudolf Brandner 339 Siemens ICN 340 Hofmannstrasse 51 341 Munich 342 Germany 343 email: 344 voice: 345 web: 347 Lawrence Conroy 348 Siemens Roke Manor Research 349 Roke Manor 350 Romsey 351 U.K. 352 email: 353 voice: 355 Richard Stastny 356 OeFEG 357 Postbox 147 358 1103 Vienna 359 Austria 360 email: 361 voice: 363 10. IPR and Full Copyright Statement 365 Disclaimer of validity: 367 The IETF takes no position regarding the validity or scope of any 368 Intellectual Property Rights or other rights that might be claimed 369 to pertain to the implementation or use of the technology 370 described in this document or the extent to which any license 371 under such rights might or might not be available; nor does it 372 represent that it has made any independent effort to identify any 373 such rights. Information on the procedures with respect to rights 374 in RFC documents can be found in BCP 78 and BCP 79. 376 Copies of IPR disclosures made to the IETF Secretariat and any 377 assurances of licenses to be made available, or the result of an 378 attempt made to obtain a general license or permission for the use 379 of such proprietary rights by implementers or users of this 380 specification can be obtained from the IETF on-line IPR repository 381 at http://www.ietf.org/ipr. 383 The IETF invites any interested party to bring to its attention 384 any copyrights, patents or patent applications, or other 385 proprietary rights that may cover technology that may be required 386 to implement this standard. Please address the information to the 387 IETF at ietf-ipr@ietf.org. 389 Full Copyright Statement 391 Copyright (C) The Internet Society (2004). This document is subject 392 to the rights, licenses and restrictions contained in BCP 78, and 393 except as set forth therein, the authors retain all their rights. 395 Disclaimer of Warranty 397 This document and the information contained herein are provided on an 398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 400 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 401 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 402 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Acknowledgement 407 Funding for the RFC Editor function is currently provided by the 408 Internet Society.