idnits 2.17.1 draft-ietf-enum-webft-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.5 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 421. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 389), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([3]), 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 (May 24, 2004) is 7249 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: '1' is defined on line 307, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 340, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 343, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 347, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 349, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3761 (ref. '3') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '6') ** Obsolete normative reference: RFC 1738 (ref. '11') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2616 (ref. '12') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. '13') (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM R. Brandner 3 Internet-Draft Siemens AG 4 Expires: November 22, 2004 L. Conroy 5 Siemens Roke Manor Research 6 R. Stastny 7 Oefeg 8 May 24, 2004 10 IANA Registration for ENUMservices web and ft 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 22, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document registers the 'ENUMservices' [3] 'web' and 'ft' using 42 the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA 43 registration process defined in the ENUM specification RFC3761 [3]. 45 Table of Contents 47 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Web Service . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 51 3.2 Web Service Registration with 'http:' . . . . . . . . . . 6 52 3.3 Web Service Registration with 'https:' . . . . . . . . . . 7 53 4. FT Service Registration . . . . . . . . . . . . . . . . . . . 8 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 57 6.2 Informative References . . . . . . . . . . . . . . . . . . 11 58 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 59 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 61 1. Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in BCP 14, RFC2119 [2]. 67 2. Introduction 69 ENUM (E.164 Number Mapping, RFC3761 [3]) is a system that transforms 70 E.164 numbers [4] into domain names and then uses DNS (Domain Name 71 Service, RFC1034 [5]) services like delegation through NS records and 72 NAPTR records to look up what services are available for a specific 73 domain name. 75 This document registers 'ENUMservices' according to the guidelines 76 given in RFC3761 to be used for provisioning in the services field of 77 a NAPTR [8] resource record to indicate what class of functionality a 78 given end point offers. The registration is defined within the DDDS 79 (Dynamic Delegation Discovery System [6][7][8][9][10]) hierarchy, for 80 use with the "E2U" DDDS Application defined in RFC3761. 82 The following 'ENUMservices' are registered with this document: 'web' 83 and 'ft'. These share a common feature in that they each indicate 84 that the functionality of the given end points and the associated 85 resources are primarily sources of information. 87 According to RFC2619bis, the 'ENUMservice' registered must be able to 88 function as a selection mechanism when choosing one NAPTR resource 89 record from another. That means that the registration MUST specify 90 what is expected when using that very NAPTR record, and the URI 91 scheme which is the outcome of the use of it. 93 Therefore an 'ENUMservice' acts as a hint, indicating the kind of 94 service with which the URI constructed using the regexp field is 95 associated. There can be more than one 'ENUMservice' included within 96 a single NAPTR; this indicates that there is more than one service 97 that can be achieved using the associated URI scheme. 99 The common thread with this set of definitions is that they reflect 100 the kind of service that the end user will hope to achieve with the 101 communication using the associated URI. 103 The services specified here are intended NOT to specify the protocol 104 or even method of connection that MUST be used to achieve each 105 service. Instead they define the kind of interactive behavior that an 106 end user will expect, leaving the end system to decide (based on 107 policies outside the remit of this specification) how to execute the 108 service. 110 Since the same URI scheme may be used for different services (e.g. 111 'tel:'), and the same kind of service may use different URI schemes 112 (e.g. for VoIP 'sip:', 'h323:' and 'tel:' may be used), it is 113 necessary in some cases to specify the service and the URI scheme 114 used. 116 The service parameters defined in RFC3761 allow therefore a 'type' 117 and a 'subtype' to be specified. Within this set of specifications 118 the convention is assumed that the 'type' (being the more generic 119 term) is defining the service and the 'subtype' is defining the URI 120 scheme. 122 3. Web Service 124 3.1 Introduction 126 The ENUMservices registered in this section indicate that the 127 resource identified by the associated URI is capable of being a 128 source of information. 130 3.2 Web Service Registration with 'http:' 132 Enumservice Name: "web" 134 Enumservice Type: "web" 136 Enumservice Subtype: "http" 138 URI Scheme: 'http:' 140 Functional Specification: 142 This ENUMservice indicates that the resource identified by the 143 associated URI scheme is capable of being a source of information. 145 It has to be noted that the kind of information retrieved can be 146 manifold. Usually, contacting a resource by an 'http:' URI provides a 147 document. This document can contain references that will trigger 148 download of many different kinds of information, like audio or video or 149 executable code. Thus, one can not be more specific about the kind of 150 information that can be expected when contacting the resource. 152 Security Considerations: 154 There are no specific security issues with this 'ENUMservice'. 155 However, the general considerations of Section 5 apply. 157 Intended Usage: COMMON 159 Author: 161 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact 162 detail see Authors' Addresses section) 164 Any other information the author deems interesting: 166 None 168 3.3 Web Service Registration with 'https:' 170 Enumservice Name: "web" 172 Enumservice Type: "web" 174 Enumservice Subtype: "https" 176 URI Scheme: 'https:' 178 Functional Specification: 180 This ENUMservice indicates that the resource identified by the 181 associated URI scheme is capable of being a source of information, 182 which can be contacted by using TLS or Secure Socket Layer protocol. 184 It has to be noted that the kind of information retrieved can be 185 manifold. Usually, contacting a resource by an 'https:' URI provides 186 a document. This document can contain all different kind of 187 information, like audio or video or executable code. Thus, one can 188 not be more specific what information to expect when contacting the 189 resource. 191 Security Considerations: 193 There are no specific security issues with this 'ENUMservice'. 194 However, the general considerations of Section 5 apply. 196 Intended Usage: COMMON 198 Author: 200 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact 201 detail see Authors' Addresses section) 203 Any other information the author deems interesting: 205 None 207 4. FT Service Registration 209 Enumservice Name: "ft" 211 Enumservice Type: "ft" 213 Enumservice Subtype: "ftp" 215 URI Scheme: 'ftp:' 217 Functional Specification: 219 This ENUMservice indicates that the resource identified by the 220 associated URI scheme is a file service from which a file or file 221 listing can be retrieved. 223 Security Considerations: 225 There are no specific security issues with this 'ENUMservice'. 226 However, the general considerations of Section 5 apply. 228 Intended Usage: COMMON 230 Author: 232 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact 233 detail see Authors' Addresses section) 235 Any other information the author deems interesting: 237 None 239 5. Security Considerations 241 DNS, as used by ENUM, is a global, distributed database. Thus any 242 information stored there is visible to anyone anonymously. Whilst 243 this is not qualitatively different from publication in a Telephone 244 Directory, it does open the data subject to having "their" 245 information collected automatically without any indication that this 246 has been done or by whom. 248 Such data harvesting by third parties is often used to generate lists 249 of targets for unrequested information; in short, they are used to 250 address "spam". Anyone who uses a Web-archived mailing list is aware 251 that the volume of "spam" email they are sent increases when they 252 post to the mailing list; publication of a telephone number in ENUM 253 is no different, and may be used to send "junk faxes" or "junk SMS" 254 for example. 256 Many mailing list users have more than one email address and use 257 "sacrificial" email accounts when posting to such lists to help 258 filter out unrequested emails sent to them. This is not so easy with 259 published telephone numbers; the PSTN E.164 number assignment process 260 is much more involved and usually a single E.164 number (or a fixed 261 range of numbers) is associated with each PSTN access. Thus providing 262 a "sacrificial" phone number in any publication is not possible. 264 Due to the implications of publishing data on a globally accessible 265 database, as a principle the data subject MUST give their explicit 266 informed consent to data being published in ENUM. 268 In addition, they should be made aware that, due to storage of such 269 data during harvesting by third parties, removal of the data from 270 publication will not remove any copies that have been taken; in 271 effect, any publication may be permanent. 273 However, regulations in many regions will require that the data 274 subject can at any time request that the data is removed from 275 publication, and that their consent for its publication is explicitly 276 confirmed at regular intervals. 278 The user SHOULD be asked to confirm opening a web page or starting an 279 ftp session (particularly if the ftp client is configured to send the 280 user's email address as an "anonymous" user password). 282 Using a web:http or ft:ftp service is not secure, and so the user 283 should apply the same caution when entering personal data as they 284 would do if using a client application started with any other method. 285 Whilst this is not a feature of ENUM or these ENUMservices, the 286 ENUM-using application on the end system may appear different from 287 the user's "normal" browser, and so the user SHOULD receive an 288 indication on whether or not their communication is secured. 290 As evaluating a web page can involve execution of embedded (or 291 linked) content that may include executable code, there are risks 292 involved in evaluating a web URL. If automatic evaluation of a web 293 link were to be used, the querying user would be exposed to risks 294 associated with that automatic download and execution of content. 295 Thus the client MUST ask the querying user for confirmation before 296 evaluating the web URL; the client MUST NOT download and evaluate the 297 web content automatically. 299 An analysis of threats specific to the dependence of ENUM on the DNS, 300 and the applicability of DNSSEC [15] to these, is provided in RFC3761 301 [3]. 303 6. References 305 6.1 Normative References 307 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 308 RFC 2026, BCP 9, October 1996. 310 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 311 Levels", RFC 2119, BCP 14, March 1997. 313 [3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 314 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 315 Application (ENUM)", RFC 3761, April 2004. 317 [4] ITU-T, "The International Public Telecommunication Number 318 Plan", Recommendation E.164 , May 1997. 320 [5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 321 1034, November 1987. 323 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 324 One: The Comprehensive DDDS", RFC 3401, October 2002. 326 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 327 Two: The Algorithm", RFC 3402, October 2002. 329 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 330 Three: The Domain Name System (DNS) Database", RFC 3403, 331 October 2002. 333 [9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 334 Four: The Uniform Resource Identifiers (URI)", RFC 3404, 335 October 2002. 337 [10] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 338 Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. 340 [11] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform 341 Resource Locators (URL)", RFC 1738, December 1994. 343 [12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 344 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - 345 HTTP/1.1", RFC 2616, June 1999. 347 [13] Rescola, E., "HTTP Over TLS", RFC 2818, May 2000. 349 [14] ETSI, "Minimum Requirements for Interoperability of European 350 ENUM Trials", ETSI TS 102 172, February 2003. 352 6.2 Informative References 354 [15] Arends, R. and et al. , "Protocol Modifications for the DNS 355 Security Extensions", Work in Progress . 357 7. Authors' Addresses 359 Rudolf Brandner 360 Siemens AG 361 Hofmannstr. 51 362 81359 Munich 363 Germany 365 Phone: +49-89-722-51003 366 EMail: rudolf.brandner@siemens.com 368 Lawrence Conroy 369 Siemens Roke Manor Research 370 Roke Manor 371 Romsey 372 United Kingdom 374 Phone: +44-1794-833666 375 EMail: lwc@roke.co.uk 376 Richard Stastny 377 Oefeg 378 Postbox 147 379 1103 Vienna 380 Austria 382 Phone: +43-664-420-4100 383 EMail: richard.stastny@oefeg.at 385 8. Full Copyright Statement 387 Copyright (C) The Internet Society (2004). This document is subject 388 to the rights, licenses and restrictions contained in BCP 78, and 389 except as set forth therein, the authors retain all their rights. 391 This document and the information contained herein are provided on an 392 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 393 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 394 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 395 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 396 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 Intellectual Property 401 The IETF takes no position regarding the validity or scope of any 402 Intellectual Property Rights or other rights that might be claimed to 403 pertain to the implementation or use of the technology described in 404 this document or the extent to which any license under such rights 405 might or might not be available; nor does it represent that it has 406 made any independent effort to identify any such rights. Information 407 on the procedures with respect to rights in RFC documents can be 408 found in BCP 78 and BCP 79. 410 Copies of IPR disclosures made to the IETF Secretariat and any 411 assurances of licenses to be made available, or the result of an 412 attempt made to obtain a general license or permission for the use of 413 such proprietary rights by implementers or users of this 414 specification can be obtained from the IETF on-line IPR repository at 415 http://www.ietf.org/ipr. 417 The IETF invites any interested party to bring to its attention any 418 copyrights, patents or patent applications, or other proprietary 419 rights that may cover technology that may be required to implement 420 this standard. Please address the information to the IETF at ietf- 421 ipr@ietf.org. 423 Acknowledgement 425 Funding for the RFC Editor function is currently provided by the 426 Internet Society.