Internet Draft R. Stastny Document: draft-stastny-enum-services-analysis-00.txt OeFEG Category: Informational R. Brandner Siemens L. Conroy Siemens Expires: December 2002 June 2002 Analysis of the Usage of ENUM and ENUM Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document analyzes the usage of the URI-schemes, services and "enumservices" under discussion for the ENUM System. It tries to combine the existing proposals for "enumservices" and proposes examples of a compatible approach as a way forward for the definition of the "enumservices" to be used in the ENUM trials planned. Stastny Expires - December 2002 [Page 1] Analysis of the Usage of ENUM and ENUM Services June 2002 Table of Contents 1. The Usage of ENUM..............................................2 2. Usage of the URI schemes only to identify services.............3 3. The Usage of "enumservices"....................................3 3.1 Simple URI Schemes............................................3 3.2 Combined URI Schemes and Services.............................4 3.3 Functional grouping of "enumservices".........................4 4. Examples of "enumservices".....................................5 4.1 The URI-schemes to be used in ENUM............................5 4.2 The Services to be used in ENUM...............................5 4.3 Simple and combined "enumservices"............................6 4.4 Functional groups of "enumservices"...........................7 4.5 Informational enumservices....................................8 5. Maximum Packet Size Considerations.............................8 6. Conclusion.....................................................9 7. Security Considerations........................................9 8. Acknowlegdements...............................................9 9. References....................................................10 10. Author's Addresses...........................................10 1. The Usage of ENUM The ENUM System as defined in Draft RFC2916bis [2] allows an ENUM End User to use the DNS to connect services on the Internet to an E.164 number. Each service is identified with an URI contained in a NAPTR record, as described in the DDDS/URI Application in [3]. Any user on the Internet may contact the ENUM End User by retrieving this information via a DNS query. The ENUM End User may indicate his preferred services to be contacted by using the preference field in the NAPTR record. This may either be the primarily preferred service to be contacted in general, or the preferred service of similar or equivalent services listed. Note: The order field in the NAPTR record is used if more than one NAPTR record is necessary to evaluate the entries in the DNS. Currently no example of the usage of such a construct has been given. To indicate that a NAPTR record belongs to the ENUM System, the non- optional parameter "E2U" in the service field is used. The "U" flag in the flag field indicates, that this NAPTR record (rule) is the last one and the final outcome of the evaluated regexp field will be an URI. A user on the Internet may now query the domain related to the E.164 number and retrieve the information contained within. In principle, the querying user or the application used by the user needs to match Stastny Expires - December 2002 [Page 2] Analysis of the Usage of ENUM and ENUM Services June 2002 the services offered by the ENUM End User and eventually the given preferences with the services he has available, is able to use and/or intends to use. 2. Usage of the URI schemes only to identify services As already mentioned, the NAPTR records are used to indicate services and these services are identified with an URI in the regexp field. Since an end-point indicated by a given URI may provide multiple services, or the same URI scheme used in different NAPTR records may provide different services, it is necessary to provide the querying user with additional information. This information may be given by additional parameters provided with the URI, e.g. the svc parameter. To select the proper service to be used, the user may retrieve the NAPTR records by querying the DNS for the given E.164 related domain, evaluate all retrieved NAPTR records to get the URIs and eventually the services (svc) and other parameters provided with a given URI. Some services may even require (or allow) to contact the end-point given with the URI to negotiate the services required and/or available. The advantage of this "peek-ahead" approach is, that no additional information is required in the NAPTR records, which reduces the size of the NAPTR records and therefore the size of the information to be transmitted or cached. Regarding the maximum UDP packet size limitation see also section 6. The disadvantage of this approach may be the additional processing power and time needed to evaluate the URI fitting to the service required and offered. It is therefore proposed in RFC2916bis to indicate the service(s) offered with a given NAPTR record in the service field of the NAPTR record in addition to the mandatory "E2U". 3. The Usage of "enumservices" 3.1 Simple URI Schemes The simplest proposal is, as hinted in the examples of RFC2916bis, to indicate the scheme of the resulting URI of the regexp, by using the same name for the enumservice as for the URI-scheme: +mailto, +sip, +h323, +tel, etc. Stastny Expires - December 2002 [Page 3] Analysis of the Usage of ENUM and ENUM Services June 2002 Since some URI schemes may point to different services or one URI may provide more then one service, additional information may be required to select the proper NAPTR record and to eliminate false positives. 3.2 Combined URI Schemes and Services It was therefore proposed to define a combination of the URI-scheme and the service provided by this URI-scheme as enumservice, e.g.: +telvoice, +telfax, +telsms, +sipvoice, +sipvideo, etc. The names for these enumservices may be defined easily by using on one side the names of the URI-schemes and on the other side the names of the services, provided that the names used for the services are different from the URI-schemes. Also the same service names shall be used for the equivalent services with different URI-schemes. This implies, that the names of this enumservices should be self- explaining, even if the exact functions still have to be described in in the URI-schemes and in the ENUM registration template. All enumservices related to one URI may be defined in one template (as defined in RFC2816bis) and preferably by the specialists and/or workgroup dealing with this URI-scheme. These two approaches of enumservice definitions could be used together, since different names are used. So the enumservices +sip, +tel, +mailto, +h323, etc. may be used in addition to the enumservices +telfax, +telvoice, etc. 3.3 Functional grouping of "enumservices" It was pointed out during the discussions, that some functional grouping of the enumservices may be helpful for evaluating, especially from the user point of view. If this is not considered as an alternative, but as additional information to the selection process, all three approaches to the definitions of enumservices may exist and may be used in parallel. So the definitions of the functional groups of services may be added to the above mentioned simple and combined enumservices, provided that different names are used e.g.: +talk, +message, +info, +chat, +srs, +certificate, etc.,. The functional groups of enumservices may be defined based on already defined enumservices, re-using their definitions, so it may be not necessary to define them based on the URI-schemes themselves, e.g.: Stastny Expires - December 2002 [Page 4] Analysis of the Usage of ENUM and ENUM Services June 2002 talk may be defined using the enumservice definitions +tel, +sip, +telvoice, +sipvoice, +h323voice, etc. 4. Examples of "enumservices" 4.1 The URI-schemes to be used in ENUM In principle any URI-Scheme may potentially be used in ENUM. Nevertheless, at least for the ENUM trials and also for compatibility of the ENUM client-SW, it does make sense to define the URI-schemes valid for ENUM, e.g.: mailto: ldap: smtp: sip: h323: tel: http: https: ftp: sftp: enum: etc. Of course, the list may be expanded at any time. Note: For the use and purpose of the URI Scheme enum, see , section 7.2 [4]. 4.2 The Services to be used in ENUM If an URI-Scheme may provide different services, either separate or in parallel, the services and how they are indicated need to be defined. This shall be done in the definition of the URI-scheme. In addition, there need to be defined, which of these services may be used with ENUM. The URI tel: may e.g. point to a voice-only phone number, to a fax- only phone number, to a sms-only phone number, or to a phone number providing all three services (see also [5]). The definitions of the services are URI specific, so only examples are given here: Stastny Expires - December 2002 [Page 5] Analysis of the Usage of ENUM and ENUM Services June 2002 voice, fax, sms, ems, mms, tdd, ivoice, etc. for tel: mail, key, etc. for ldap: voice, video, etc. for sip: and h323: etc. Remark: it should be noted, that e.g a sip- or h323-client may use tel, sip and h323 URIs, if the application service provider allows it. This may also be valid for other URI-schemes. 4.3 Simple and combined "enumservices" Now for each URI-scheme the simple and/or combined enumservices are defined. For all URI-schemes providing (currently) only one service within ENUM, the same name for the enumservice as for the URI-scheme may be sufficient, e.g. "mailto". For all URI-schemes allowing potentially more than one service to be used, combined enumservices are defined e.g.: telvoice, telfax, telsms, telems, telmms, telivoice, etc. telrn, telcic, teldn, etc. sipvoice, sipvideo, etc. h323voice, h323video, etc. ldapmail, ldapkey, etc. etc. Each block of enumservices related to one URI-scheme could be defined in one template. Note: the enumservices telrn, telcic and teldn are primarily required for infrastructure ENUM-like Systems and may be defined separately (see also [4]). An open question is whether the definition of a simple enumservice is required in addition, if combined enumservices are defined for an URI-scheme and what the functional specification of such an simple enumservice should be. There are some choices of definitions possible: a. All possible services of the URI-scheme are implemented with this enumservice. Stastny Expires - December 2002 [Page 6] Analysis of the Usage of ENUM and ENUM Services June 2002 b. All possible services of the URI-scheme that are not implemented with another enumservice explicitely are implemented with this enumservice. c. The services related to this URI-scheme may be negotiated. d. A default service is defined in the functional specification of the related enumservice. e. The service is obvious together with the functional group used in conjunction with this simple enumservice(see below) There may even exist different approaches for different simple enumservices, described in the functional description. 4.4 Functional groups of "enumservices" The functional groups proposed so far are: "talk" (or "phone" or "rtc") used with: tel, telvoice, sipvoice, sipvideo, h323voice, h323video, etc., for any kind of two-way realtime mediastream communication. "msg" (or "message") used with: mailto, smtp, ldap, ldapmail, telsms, telems, telmms, etc., for any kind of store-and-forward or instant messaging application. "info" (or "file") used with: http, https, ftp, sftp, etc., to point to any kind of information, either on a web-page or at document. "cert" (or "certificate") used with "ldap, ldapkey, etc., to point to any kind of certificate, eg. a public key. Note: Is there a possibility to store a public key directly in DNS? "srs" (or "enquire/inquire") used with: sip, h323, etc., if the services are not defined explicitly, but need to be negotiated. "pres" (or "presence") used with: sip, etc., for any kind of presence or location information. "chat" (or "textchat") used with: sip, etc., Stastny Expires - December 2002 [Page 7] Analysis of the Usage of ENUM and ENUM Services June 2002 to be used for real-time text communication. "streaming" (or "broadcast") used with: rtsp, etc., for any kind of one-way streaming broadcast, e.g audio or video broadcast. This may also be used for announcements. "any" used with: enum, or any other functional group, if a user wants to redirect all or parts or the services to another number. For each functional group a template needs to be defined, but since these templates may refer to the already defined templates of the simple and/or combined enumservices, the creation of these templates may be simple. This may also solve some of the above mentioned problems of the definition of single-URI enumservices, e.g.: a. a functional group enumservice may only be defined if a related simple or combined enumservice exists. b. a simple enumservice may be used, if it is selfexplaining together with a functional group enumservice, e.g.: "E2U+talk+tel". c. if the services are to be negotiated, the functional group enumservice "srs" has to be used, e.g. "E2U+srs+sip" 4.5 Informational enumservices Customers may require additional optional enumservices to tag certain NAPTR records for specific use. One example may be derived from the convention how to put different phone numbers on a business card, e.g. "Home", "Office", "Mobile", etc. Therefore an enumservice field may look like "E2U+talk+sip+home" or "E2U+msg+mailto+office" 5. Maximum Packet Size Considerations DNS uses primarily UDP to transmit requests and responses. As per RFC1035 [6] the maximum UDP packet size for DNS is 512 Octets. Stastny Expires - December 2002 [Page 8] Analysis of the Usage of ENUM and ENUM Services June 2002 The UDP max packet size limit for UDP has implications on two parameters, which are not independent. Up to some 7 NAPTRs can be transmitted in a single DNS response, dependent on how long the RR is. The longer the NAPTR is the fewer NAPTRs RR can be put into a domain, if UDP has be used. Thus, long enumservice fields like "E2U+tel+telvoice+telvideo+telfax+telsms+telems+telmms" are highly discouraged. In defining the enumservices for ENUM this has to be taken into account. The DNS UDP maximum packet size limit can be overcome by using TCP. However using TCP additional latency is introduced due to establishing a TCP connection prior to the data transfer. 6. Conclusion This draft may show a way forward in the definition of enumservices, at least for the planned ENUM trial period. The examples of the enumservices given are compatible and usable in the ENUM trials either independently or combined, even if finally the experience of the ENUM trials may show, that not all of the enumservices described here may be required or some combinations of enumservices may be redundant. The ENUM trials will also provide information on the number of NAPTR RR and "enumservices" used by the typical ENUM End Users and if there are any problems with the above mentioned packet size limitations. 7. Security Considerations This document does not introduce new security implications other than those associated with the ENUM Service as defined in Draft RFC2916bis. If there are specific security considerations related to an URI- scheme, service or an "enumservice", this should be covered with the definition of the URI-scheme or the "enumservice". 8. Acknowlegdements The author would like to thank Rich Shockey, Patrik Faltstrom, Michael Mealling, Andrew Zmolek and Clive Feather for their comments and invaluable help. Stastny Expires - December 2002 [Page 9] Analysis of the Usage of ENUM and ENUM Services June 2002 9. References 1 Scott Bradner, RFC2026, "The Internet Standards Process û Revision 3," October 1996. 2 P. Faltstrom, "The E.164 to URI DDDS Application", draft-ietf-enum-rfc2916bis-01.txt, Work in Progress, March 2002. 3 M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" draft-ietf-urn-dns-ddds-database-08.txt, Work in Progress, February 2002. 4 R. Stastny, "Scenarios for ENUM and ENUM-like Systems", draft-stastny-enum-scenarios-00.txt, Work in Progress, June 2002. 5 R. Brandner, "The 'tel:' URI 'svc' parameter", draft-brandner-tel-svc-00.txt, Work in Progress, June 2002. 6 P. Mockapetris, RFC1035, "Domain Names - Implementation and Specification", November 1987. 10. Author's Addresses Rudolf Brandner Siemens ICN Hofmannstrasse 51 Munich Germany Msg: Talk: Info: Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey U.K. Msg: Talk: Stastny Expires - December 2002 [Page 10] Analysis of the Usage of ENUM and ENUM Services June 2002 Richard Stastny OeFEG Postbox 147 1103 Vienna Austria Msg: Talk: Stastny Expires - December 2002 [Page 11]