idnits 2.17.1 draft-stastny-enum-services-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 1 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2002) is 7958 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 17 looks like a reference -- Missing reference section? '2' on line 65 looks like a reference -- Missing reference section? '3' on line 68 looks like a reference -- Missing reference section? '4' on line 266 looks like a reference -- Missing reference section? '5' on line 228 looks like a reference -- Missing reference section? '6' on line 369 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Stastny 3 Document: draft-stastny-enum-services-analysis-00.txt OeFEG 4 Category: Informational R. Brandner 5 Siemens 6 L. Conroy 7 Siemens 8 Expires: December 2002 June 2002 10 Analysis of the Usage of ENUM and ENUM Services 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 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 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 Abstract 36 This document analyzes the usage of the URI-schemes, services and 37 "enumservices" under discussion for the ENUM System. It tries to 38 combine the existing proposals for "enumservices" and proposes 39 examples of a compatible approach as a way forward for the definition 40 of the "enumservices" to be used in the ENUM trials planned. 42 Table of Contents 44 1. The Usage of ENUM..............................................2 45 2. Usage of the URI schemes only to identify services.............3 46 3. The Usage of "enumservices"....................................3 47 3.1 Simple URI Schemes............................................3 48 3.2 Combined URI Schemes and Services.............................4 49 3.3 Functional grouping of "enumservices".........................4 50 4. Examples of "enumservices".....................................5 51 4.1 The URI-schemes to be used in ENUM............................5 52 4.2 The Services to be used in ENUM...............................5 53 4.3 Simple and combined "enumservices"............................6 54 4.4 Functional groups of "enumservices"...........................7 55 4.5 Informational enumservices....................................8 56 5. Maximum Packet Size Considerations.............................8 57 6. Conclusion.....................................................9 58 7. Security Considerations........................................9 59 8. Acknowlegdements...............................................9 60 9. References....................................................10 61 10. Author's Addresses...........................................10 63 1. The Usage of ENUM 65 The ENUM System as defined in Draft RFC2916bis [2] allows an ENUM End 66 User to use the DNS to connect services on the Internet to an E.164 67 number. Each service is identified with an URI contained in a NAPTR 68 record, as described in the DDDS/URI Application in [3]. Any user on 69 the Internet may contact the ENUM End User by retrieving this 70 information via a DNS query. 72 The ENUM End User may indicate his preferred services to be contacted 73 by using the preference field in the NAPTR record. This may either be 74 the primarily preferred service to be contacted in general, or the 75 preferred service of similar or equivalent services listed. 77 Note: The order field in the NAPTR record is used if more than one 78 NAPTR record is necessary to evaluate the entries in the DNS. 79 Currently no example of the usage of such a construct has been given. 81 To indicate that a NAPTR record belongs to the ENUM System, the non- 82 optional parameter "E2U" in the service field is used. The "U" flag 83 in the flag field indicates, that this NAPTR record (rule) is the 84 last one and the final outcome of the evaluated regexp field will be 85 an URI. 87 A user on the Internet may now query the domain related to the E.164 88 number and retrieve the information contained within. In principle, 89 the querying user or the application used by the user needs to match 90 the services offered by the ENUM End User and eventually the given 91 preferences with the services he has available, is able to use and/or 92 intends to use. 94 2. Usage of the URI schemes only to identify services 96 As already mentioned, the NAPTR records are used to indicate services 97 and these services are identified with an URI in the regexp field. 98 Since an end-point indicated by a given URI may provide multiple 99 services, or the same URI scheme used in different NAPTR records may 100 provide different services, it is necessary to provide the querying 101 user with additional information. 103 This information may be given by additional parameters provided with 104 the URI, e.g. the svc parameter. To select the proper service to be 105 used, the user may retrieve the NAPTR records by querying the DNS for 106 the given E.164 related domain, evaluate all retrieved NAPTR records 107 to get the URIs and eventually the services (svc) and other 108 parameters provided with a given URI. 110 Some services may even require (or allow) to contact the end-point 111 given with the URI to negotiate the services required and/or 112 available. 114 The advantage of this "peek-ahead" approach is, that no additional 115 information is required in the NAPTR records, which reduces the size 116 of the NAPTR records and therefore the size of the information to be 117 transmitted or cached. Regarding the maximum UDP packet size 118 limitation see also section 6. 120 The disadvantage of this approach may be the additional processing 121 power and time needed to evaluate the URI fitting to the service 122 required and offered. 124 It is therefore proposed in RFC2916bis to indicate the service(s) 125 offered with a given NAPTR record in the service field of the NAPTR 126 record in addition to the mandatory "E2U". 128 3. The Usage of "enumservices" 130 3.1 Simple URI Schemes 132 The simplest proposal is, as hinted in the examples of RFC2916bis, to 133 indicate the scheme of the resulting URI of the regexp, by using the 134 same name for the enumservice as for the URI-scheme: +mailto, +sip, 135 +h323, +tel, etc. 137 Since some URI schemes may point to different services or one URI may 138 provide more then one service, additional information may be required 139 to select the proper NAPTR record and to eliminate false positives. 141 3.2 Combined URI Schemes and Services 143 It was therefore proposed to define a combination of the URI-scheme 144 and the service provided by this URI-scheme as enumservice, e.g.: 146 +telvoice, +telfax, +telsms, +sipvoice, +sipvideo, etc. 148 The names for these enumservices may be defined easily by using on 149 one side the names of the URI-schemes and on the other side the names 150 of the services, provided that the names used for the services are 151 different from the URI-schemes. Also the same service names shall be 152 used for the equivalent services with different URI-schemes. This 153 implies, that the names of this enumservices should be self- 154 explaining, even if the exact functions still have to be described in 155 in the URI-schemes and in the ENUM registration template. 157 All enumservices related to one URI may be defined in one template 158 (as defined in RFC2816bis) and preferably by the specialists and/or 159 workgroup dealing with this URI-scheme. 161 These two approaches of enumservice definitions could be used 162 together, since different names are used. So the enumservices +sip, 163 +tel, +mailto, +h323, etc. may be used in addition to the 164 enumservices +telfax, +telvoice, etc. 166 3.3 Functional grouping of "enumservices" 168 It was pointed out during the discussions, that some functional 169 grouping of the enumservices may be helpful for evaluating, 170 especially from the user point of view. 172 If this is not considered as an alternative, but as additional 173 information to the selection process, all three approaches to the 174 definitions of enumservices may exist and may be used in parallel. 176 So the definitions of the functional groups of services may be added 177 to the above mentioned simple and combined enumservices, provided 178 that different names are used e.g.: 180 +talk, +message, +info, +chat, +srs, +certificate, etc.,. 182 The functional groups of enumservices may be defined based on already 183 defined enumservices, re-using their definitions, so it may be not 184 necessary to define them based on the URI-schemes themselves, e.g.: 186 talk may be defined using the enumservice definitions +tel, +sip, 187 +telvoice, +sipvoice, +h323voice, etc. 189 4. Examples of "enumservices" 191 4.1 The URI-schemes to be used in ENUM 193 In principle any URI-Scheme may potentially be used in ENUM. 195 Nevertheless, at least for the ENUM trials and also for compatibility 196 of the ENUM client-SW, it does make sense to define the URI-schemes 197 valid for ENUM, e.g.: 199 mailto: 200 ldap: 201 smtp: 202 sip: 203 h323: 204 tel: 205 http: 206 https: 207 ftp: 208 sftp: 209 enum: 210 etc. 212 Of course, the list may be expanded at any time. 214 Note: For the use and purpose of the URI Scheme enum, see , section 7.2 [4]. 217 4.2 The Services to be used in ENUM 219 If an URI-Scheme may provide different services, either separate or 220 in parallel, the services and how they are indicated need to be 221 defined. This shall be done in the definition of the URI-scheme. 223 In addition, there need to be defined, which of these services may be 224 used with ENUM. 226 The URI tel: may e.g. point to a voice-only phone number, to a fax- 227 only phone number, to a sms-only phone number, or to a phone number 228 providing all three services (see also [5]). 230 The definitions of the services are URI specific, so only examples 231 are given here: 233 voice, fax, sms, ems, mms, tdd, ivoice, etc. for tel: 234 mail, key, etc. for ldap: 235 voice, video, etc. for sip: and h323: 236 etc. 238 Remark: it should be noted, that e.g a sip- or h323-client may use 239 tel, sip and h323 URIs, if the application service provider allows 240 it. This may also be valid for other URI-schemes. 242 4.3 Simple and combined "enumservices" 244 Now for each URI-scheme the simple and/or combined enumservices are 245 defined. 247 For all URI-schemes providing (currently) only one service within 248 ENUM, the same name for the enumservice as for the URI-scheme may be 249 sufficient, e.g. "mailto". 251 For all URI-schemes allowing potentially more than one service to be 252 used, combined enumservices are defined e.g.: 254 telvoice, telfax, telsms, telems, telmms, telivoice, etc. 255 telrn, telcic, teldn, etc. 256 sipvoice, sipvideo, etc. 257 h323voice, h323video, etc. 258 ldapmail, ldapkey, etc. 259 etc. 261 Each block of enumservices related to one URI-scheme could be defined 262 in one template. 264 Note: the enumservices telrn, telcic and teldn are primarily required 265 for infrastructure ENUM-like Systems and may be defined separately 266 (see also [4]). 268 An open question is whether the definition of a simple enumservice is 269 required in addition, if combined enumservices are defined for an 270 URI-scheme and what the functional specification of such an simple 271 enumservice should be. 273 There are some choices of definitions possible: 275 a. All possible services of the URI-scheme are implemented with this 276 enumservice. 278 b. All possible services of the URI-scheme that are not implemented 279 with another enumservice explicitely are implemented with this 280 enumservice. 282 c. The services related to this URI-scheme may be negotiated. 284 d. A default service is defined in the functional specification of 285 the related enumservice. 287 e. The service is obvious together with the functional group used in 288 conjunction with this simple enumservice(see below) 290 There may even exist different approaches for different simple 291 enumservices, described in the functional description. 293 4.4 Functional groups of "enumservices" 295 The functional groups proposed so far are: 297 "talk" (or "phone" or "rtc") used with: 298 tel, telvoice, sipvoice, sipvideo, h323voice, h323video, etc., 299 for any kind of two-way realtime mediastream communication. 301 "msg" (or "message") used with: 302 mailto, smtp, ldap, ldapmail, telsms, telems, telmms, etc., 303 for any kind of store-and-forward or instant messaging application. 305 "info" (or "file") used with: 306 http, https, ftp, sftp, etc., 307 to point to any kind of information, either on a web-page or at 308 document. 310 "cert" (or "certificate") used with 311 "ldap, ldapkey, etc., 312 to point to any kind of certificate, eg. a public key. 313 Note: Is there a possibility to store a public key directly in DNS? 315 "srs" (or "enquire/inquire") used with: 316 sip, h323, etc., 317 if the services are not defined explicitly, but need to be 318 negotiated. 320 "pres" (or "presence") used with: 321 sip, etc., 322 for any kind of presence or location information. 324 "chat" (or "textchat") used with: 325 sip, etc., 326 to be used for real-time text communication. 328 "streaming" (or "broadcast") used with: 329 rtsp, etc., 330 for any kind of one-way streaming broadcast, e.g audio or video 331 broadcast. This may also be used for announcements. 333 "any" used with: 334 enum, or any other functional group, if a user wants to redirect all 335 or parts or the services to another number. 337 For each functional group a template needs to be defined, but since 338 these templates may refer to the already defined templates of the 339 simple and/or combined enumservices, the creation of these templates 340 may be simple. 342 This may also solve some of the above mentioned problems of the 343 definition of single-URI enumservices, e.g.: 345 a. a functional group enumservice may only be defined if a related 346 simple or combined enumservice exists. 348 b. a simple enumservice may be used, if it is selfexplaining together 349 with a functional group enumservice, e.g.: "E2U+talk+tel". 351 c. if the services are to be negotiated, the functional group 352 enumservice "srs" has to be used, e.g. "E2U+srs+sip" 354 4.5 Informational enumservices 356 Customers may require additional optional enumservices to tag certain 357 NAPTR records for specific use. 359 One example may be derived from the convention how to put different 360 phone numbers on a business card, e.g. "Home", "Office", "Mobile", 361 etc. 363 Therefore an enumservice field may look like "E2U+talk+sip+home" or 364 "E2U+msg+mailto+office" 366 5. Maximum Packet Size Considerations 368 DNS uses primarily UDP to transmit requests and responses. As per 369 RFC1035 [6] the maximum UDP packet size for DNS is 512 Octets. 371 The UDP max packet size limit for UDP has implications on two 372 parameters, which are not independent. Up to some 7 NAPTRs can be 373 transmitted in a single DNS response, dependent on how long the RR 374 is. The longer the NAPTR is the fewer NAPTRs RR can be put into a 375 domain, if UDP has be used. Thus, long enumservice fields like 377 "E2U+tel+telvoice+telvideo+telfax+telsms+telems+telmms" 379 are highly discouraged. In defining the enumservices for ENUM this 380 has to be taken into account. 382 The DNS UDP maximum packet size limit can be overcome by using TCP. 383 However using TCP additional latency is introduced due to 384 establishing a TCP connection prior to the data transfer. 386 6. Conclusion 388 This draft may show a way forward in the definition of enumservices, 389 at least for the planned ENUM trial period. 391 The examples of the enumservices given are compatible and usable in 392 the ENUM trials either independently or combined, even if finally the 393 experience of the ENUM trials may show, that not all of the 394 enumservices described here may be required or some combinations of 395 enumservices may be redundant. 397 The ENUM trials will also provide information on the number of NAPTR 398 RR and "enumservices" used by the typical ENUM End Users and if there 399 are any problems with the above mentioned packet size limitations. 401 7. Security Considerations 403 This document does not introduce new security implications other than 404 those associated with the ENUM Service as defined in Draft 405 RFC2916bis. 407 If there are specific security considerations related to an URI- 408 scheme, service or an "enumservice", this should be covered with the 409 definition of the URI-scheme or the "enumservice". 411 8. Acknowlegdements 413 The author would like to thank Rich Shockey, Patrik Faltstrom, 414 Michael Mealling, Andrew Zmolek and Clive Feather for their comments 415 and invaluable help. 417 9. References 419 1 Scott Bradner, RFC2026, "The Internet Standards Process � 420 Revision 3," October 1996. 422 2 P. Faltstrom, "The E.164 to URI DDDS Application", 423 draft-ietf-enum-rfc2916bis-01.txt, 424 Work in Progress, March 2002. 426 3 M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part 427 Three: The DNS Database" 428 draft-ietf-urn-dns-ddds-database-08.txt, 429 Work in Progress, February 2002. 431 4 R. Stastny, "Scenarios for ENUM and ENUM-like Systems", 432 draft-stastny-enum-scenarios-00.txt, 433 Work in Progress, June 2002. 435 5 R. Brandner, "The 'tel:' URI 'svc' parameter", 436 draft-brandner-tel-svc-00.txt, 437 Work in Progress, June 2002. 439 6 P. Mockapetris, RFC1035, "Domain Names - Implementation and 440 Specification", November 1987. 442 10. Author's Addresses 444 Rudolf Brandner 445 Siemens ICN 446 Hofmannstrasse 51 447 Munich 448 Germany 450 Msg: 451 Talk: 452 Info: 454 Lawrence Conroy 455 Siemens Roke Manor Research 456 Roke Manor 457 Romsey 458 U.K. 460 Msg: 461 Talk: 463 Richard Stastny 464 OeFEG 465 Postbox 147 466 1103 Vienna 467 Austria 469 Msg: 470 Talk: