ENUM Working Group R.Brandner Internet-Draft Siemens L. Conroy Siemens R. Stastny OeFEG Expires: December, 2002 June 21st, 2002 "Categorical enumservices" Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines the set of enumservices describing "high level" communications categories. These are used as elements within the services field of NAPTR resource records within ENUM domain space. Each category identifies a kind of communications service in which an end user might want to engage using the associated resource. It includes the expected "low level" service that comes under each category, together with a list of the URI schemes that are appropriate for use with each categorical enumservice. Brandner, Conroy, Stastny Expires December, 2002 [Page 1] Internet-Draft Categorical enumservices June 2002 1. Introduction Enumservices can be classified in a number of different ways. For a summary of the discussion on options available, see [2]. In addition to the scheme of the URI associated with a NAPTR and the DDDS application identifier ("E2U", in the case of ENUM [1]), there are two main ways of indicating the services supported by the identified resource. These are "low level" or specific services, of which there could be a large number, or higher level categories. This document focusses on the latter, and shows how the existing low level services may be mapped to the higher level categorical enumservices. Low level enumservices define the specific service offered via the associated resource. These are much "closer" to the URI scheme, and indicate the way in which a communication is to be carried out. High level (or categorical) enumservices are intended to reflect the kind of communication in which an end user wants to engage. The goal is to provide a small list of the kinds of communication appropriate rather than the protocol (or implementation) used to execute that communication; they are intended to reflect the "end user's view" of what they want to do, rather than the protocol used to effect that service. 1.1. About this document The following sections each describes a category of communication in which an end user may want to engage, and might be passed from the end user interface to the DDDS Application, where it could be used to sieve a NAPTR resource set returned for a particular zone within the ENUM domain space. The goal here is to use this passed list as a filter, rejecting NAPTRs that do not have matching indications in their service field. In each of the sections, the categorical service is described, along with any expected client behaviour, the "low level" services that fall into this category (and so should be matched against the "interesting categorical enumservices"), the URI-schemes that can be associated with the category and any features that they have when used in this way. 2. 'talk' categorical enumservice This enumservice indicates that the associated resource can be used for interactive (media stream exchange) calls; it can be used to "talk" to the owner. 2.1. 'talk' Expected client behaviour The end user, having selected the talk category as being of interest, will expect their client agent to filter the NAPTRs to those that include either this categorical service or the specific services that it implies. Given that this category is concerned with interactive calls, the querying clients agent should present the options available and supported locally to the end user. This is particularly important for calls that are delivered via a local PSTN connection, as there may well be a cost involved. Brandner, Conroy, Stastny Expires December, 2002 [Page 2] Internet-Draft Categorical enumservices June 2002 2.2. 'talk' Implied "low level" services This sub-section describes the low level services that can be classified under this category. Proposals so far have been similar to those included in the 'tel-svc' draft [4], and, for the 'talk' related services, include: - voice - video 2.3. 'talk' Associated URI schemes This sub-section describes the URI-schemes for which this category would be appropriate, together with a description of any special issues with each URI scheme used with this category. Note that, although it is possible that VPIM voice messages or video clips could be sent, this is NOT the meaning of the 'talk' category. Thus the URI schemes appropriate for this enumservice category include only those usable to exchange interactive media. 2.3.1. talk with "sip:" URI This combination implies that the associated URI may be used to initiate interactive telephony calls to the destination using SIP [6]. Note that SIP has its own negotiation method within the protocol, so that the client MAY be offered another kind of communication session after negotiation. However, this combination gives more information to the querying user than would be the case for the 'srs' enumservice (see section 6.3.1). The implication of the NAPTR with the 'talk' and 'sip' combination is that, if selected, the querying user can engage in an interactive call; thus the registrant SHOULD include such an entry only for those cases where this is possible. 2.3.2. talk with "tel:" URI The talk category is one of the two main uses for the "tel:" URI [3]. In this case, the querying client might use this to trigger a voice call via local "dialer" software that controls a PSTN interface (such as a software controlled telephone). If the client has no support for local PSTN connection, then it may submit the "tel:" URI to a local SIP user agent, if the user has a relationship with an external gateway provider that can support "tel:" URIs as destination end points. However, a "tel:" URI is intended for use where the destination party is connected via the PSTN or a network that uses E.164 numbers natively, and by preference the client should attempt to make a PSTN connection if possible. Note that the "tel:" URI may include a svc parameter, specifying the low level services this resource supports. This category implies voice or video services may be used; if one is specified then this may define which service can be used. If there is no such parameter or it includes both video and voice as supported, then the client is able to choose. However, it is recommended that voice be considered the default service and the one to be attempted first, in lack of further information Brandner, Conroy, Stastny Expires December, 2002 [Page 3] Internet-Draft Categorical enumservices June 2002 2.3.3. talk with "h323:" URI In principle, interactive calls could be made using the H.323 set of protocols. Within the ENUM system, this requires a URI-scheme to be defined for this protocol set, but once this is done, the talk category may be used with such an "h323:" URI. 2.3.4. talk with "enum:" URI The "enum:" URI scheme [7] is intended to indicate the E.164 number that should be used in a re-submission to the ENUM system. In this combination, the interpretation should be that this URI may be used to find further information from the ENUM system by re-submission for clients that are interested in the 'talk' enumservice category only. 3. 'msg' categorical enumservice The msg enumservice is intended to indicate that the associated resource is capable of receiving a discrete (non-session related) message or document. This category may be selected by a querying client if they want to deliver a message (such as a Fax) to a correspondent. 3.1. 'msg' Expected Client Behaviour Where a querying end user is interested in the 'msg' communication category, it is expected that they will select a NAPTR that is so identified and will generate the URI from this. Once this URI is available, the client would be expected to send a message using the protocol indicated by the URI-scheme. 3.2. 'msg' Implied "low level" services The msg category includes a number of specific services. These are: - Fax The Fax service will be associated with a "tel:" URI. As negotiation of particular fax classes (G2, G3, G4) is done within the Fax protocol itself, there is no specification for this needed within the ENUM system. This is considered the default service within this category when used with a "tel:" URI, so if the URI does not include a 'svc' parameter then this may be assumed from the category and URI scheme. - SMS or MMS These services will be associated with a "tel:" URI, and the particular service may be identified within the URI using a 'svc' parameter. If there is no such indication, then an attempt should not be made to use these services (i.e. an SMS or MMS message should not be sent). - email This category, when used with a "mailto:" URI, indicates the email service is supported at this resource. An email may be sent using the associated "mailto:" URI. See [5] for more details on this scheme. - IM Where this is used to send a message rather than initiate a session during which Instant Messages can be exchanged (for that, see section 5 of this document). Brandner, Conroy, Stastny Expires December, 2002 [Page 4] Internet-Draft Categorical enumservices June 2002 3.3. 'msg' Associated URI schemes 3.3.1. msg with "sip:" URI Whilst in the general case one would expect a "sip:" URI to be associated with the 'srs' category (see section 6 for details), it is possible for a registrant to decide to have a separate "sip:" URI specifically as a destination for Instant Messages (or for email). Thus, this categorical enumservice may be associated with a "sip:" URI - if so, then this "sip:" URI should not be used for categories not listed within the services field. For example, if a NAPTR includes the 'msg' category and no others, then this NAPTR should be used only for communications that involve sending a message to that resource; not for other sessions such as those associated with 'chat' or 'talk' categories. Although Instant Messages or emails might be sent without using a "sip:" URI, there is a benefit to doing this; the sender may be authenticated using the standard SIP techniques prior to returning the actual destination contact address, so "hiding" that contact address to non-authenticated would-be correspondents. This should be considered, as the ENUM domain space may be a good source of "junk mail" targets. 3.3.2. msg with "tel:" URI There are two main ways in which a telephone number can be used to send a message to a destination. These are to send a telefax to a device contactable via this telephone number, and to send a short message to an appropriate device. Although Short Message Service was designed for use with mobile telephones, there is a move to provide SMS service to landline telephones as well, either via a dial-out service node (for generating an SMS message from a landline telephone), or via a Universal Message service (for reception and storage of SMS messages, and transcoding to voice on demand). For this reason, it may be possible for two end users, both of whom have landline telephones, to send and receive SMS messages; it should NOT be assumed that this is only possible from mobile telephones. Note that the "tel:" URI may contain a 'svc' parameter. This is used to indicate the specific services supported via this resource. If there is no such parameter, but this NAPTR indicates the 'msg' category, then the "tel:" URI may be assumed to support Fax service. Only if the SMS or MMS service is indicated explicitly within the "tel:" URI should such a message be sent to that destination. 3.3.3. msg with "mailto:" URI This category is appropriate to indicate that email messages may be sent to the resource identified in the associated URI. In this case the "mailto:" URI is likely to be used (but a "sip:" URI may be chosen instead, particularly if the registrant wants to authenticate the sender using the SIP infrastructure). Brandner, Conroy, Stastny Expires December, 2002 [Page 5] Internet-Draft Categorical enumservices June 2002 Existence of a "mailto:" URI within the globally-accessible ENUM infrastructure may well lead to reception of unwanted "junk email", as the ENUM infrastructure is trawled for potential target email addresses. Whilst this is not an issue with the 'msg' category itself, it should be considered by registrants when populating their domains. 3.3.4. msg with "enum:" URI The "enum:" URI scheme is intended to indicate the E.164 number that should be used in a re-submission to the ENUM system. The client should interpret this combination and process the URI only if it matches a "client interest" in sending a message. 4. 'info' categorical enumservice The info enumservice indicates that the associated resource can act as a source for information. It acts as the "opposite" of the msg enumservice, in that this indicates a source for data whilst that indicates a sink for data. 4.1. 'info' Expected Client Behaviour The 'info' enumservice is used by the registrant to indicate to potential correspondents a source of information. The implication for a client is that the registrant will allow any data indicated by the URI to be passed to the client. Note that, particularly in the case of use with the "tel:" URI, it is important to display the destination URL to the querying end user before acting on it. Telephone information services are often charged at a higher rate from other calls, and so the end user should have the chance to confirm the action. Also, an entry of this kind states that information is available from this URI. It does not guarantee access to everyone. The client may be called on to authenticate itself before access is granted. 4.2. 'info' Implied "low level" services The info enumservice is used for sources of information. The current list of low level services does not seem to fit with this category, so that the URI scheme is the only other identifier that can be used to help select between a set of NAPTRs. 4.3. 'info' Associated URI schemes The info enumservice can be used with several URI schemes. The most common is likely to be that with the "http:" URI-scheme. 4.3.1. info with "tel:" URI This combination may seem strange at first, but might be used where a recorded announcement or "information line" can be reached by dialling a particular telephone number. This is not an interactive call in that the recording is being played to the client rather than the client talking with a correspondent. Brandner, Conroy, Stastny Expires December, 2002 [Page 6] Internet-Draft Categorical enumservices June 2002 >From the perspective of client software, it seems likely that this combination will be treated very similarly to a normal 'talk' enumservice; the difference lies in the user and registrant's intent for this contact and the communication that will result. 4.3.2. info with "http:" URI This combination is used where the registrant wants to store a URI to a web site within their domain space. 4.3.3. info with "https:" URI This combination indicates that TLS or Secure Socket Layer connections are required to retrieve the information indicated. 4.3.4. info with "ftp:" URI This combination indicates that the information is retrieved using FTP. 4.3.5. info with "enum:" URI This combination implies that the URI value can be processed in an ENUM re-submission to find more information on communications contacts that fit with the 'info' category. 5. 'chat' categorical enumservice This category is used where the registrant is capable of engaging in a text chat session during which Instant Messages can be sent. It differs from the 'msg' category in that this category implies a session-oriented message exchange, whilst 'msg' implies a discrete message can be sent to the resource at this contact address. 5.1. 'chat' Expected Client Behaviour This category indicates that session oriented chat exchanges can be made via the associated URI. Presence of a chat/tel combination may suggest that the registrant prefers text communication; it SHOULD be displayed to the querying end user so they can choose how to proceed. 5.2. 'chat' Implied "low-level" services At present, the 'chat' category is associated only with one low-level service -IM. It is unclear whether or not text telephony would be expected with the IM service, whilst it is one option for the chat category. 5.3. 'chat' Associated URI schemes Initially, this category is likely to be used with two URI schemes; "sip:" and "tel:". There may well be other session oriented text 'chat' protocols developed, and these should be included in future updates of this document. Brandner, Conroy, Stastny Expires December, 2002 [Page 7] Internet-Draft Categorical enumservices June 2002 5.3.1. chat with "sip:" URI This combination indicates that, by using this address of record, the client can initiate a session during which Instant Messages can be exchanged. It may be appropriate to include a NAPTR with this combination if the registrant has more than one address of record with different (competing) providers for voice and instant messaging services. SIP has its own mechanisms for negotiating the kind of communications session to be initiated, so one would expect the 'srs' category to be used in many cases; where there are other reasons that the two addresses of record cannot be combined within one SIP service, discrete (category- specific) entries can be used. 5.3.2. chat with "tel:" URI This combination indicates that text chat sessions can be initiated over the telephone network to the destination. It is used, for example, to indicate a telephone number to which a text phone (such as a 'Minicom' or Telecommunications Device for the Deaf - TDD) unit is attached. The querying client SHOULD be informed that textphones are available if this combination is available within a NAPTR. It is difficult to determine whether or not text communication should be preferred over voice, and the end user SHOULD be able to choose. Note that there may be a privacy issue; including this data might be an indication that the registrant is hard of hearing, information that may be considered sensitive. 6. 'srs' categorical enumservice This category is used for entries that exit the ENUM system and continue communication service selection using external protocols. These external schemes are called "Service Resolution Services" (or SRS). Information on the kind of communication available is not stored within one of these ENUM entries; instead this may be delivered using the inbuilt procedures of the protocol specified by the associated URI scheme. 6.1. 'srs' Expected Client Behaviour This category indicates that the associated URI can be used for further negotiation on the available communications options available. Thus the protocol-specific mechanisms are used. It is assumed that, if the querying client can support these protocols, then the standard protocol handler techniques will be used. 6.2. 'srs' Implied "low-level" services By definition, a Service Resolution Service does not have a specific or "low level" service; the srs is used to negotiate outside of the ENUM system. This category does not fit with the concept of "low level" services indicated within ENUM. Brandner, Conroy, Stastny Expires December, 2002 [Page 8] Internet-Draft Categorical enumservices June 2002 6.3. 'srs' Associated URI schemes Initially, the two main protocols used with this category are SIP and LDAP. For details of the SIP negotiation mechanisms, see [6]. 6.3.1. srs with "sip:" URI This combination is likely to be commonly used. It avoids some potential privacy issues with publishing data within the (global) DNS. Full negotiation of session or contact is available within the SIP protocol, including authentication of the querying user. As mentioned in the sections on the 'msg' and 'talk' categories, it may be difficult to use a single entry within an ENUM domain. A registrant may have, for example, two discrete addresses of record for two categories and may choose to not combine these. However, where this is possible, an entry with 'srs' and "sip:" can be used to "off load" the negotiation to the SIP protocol rather than relying on the DDDS application. 6.3.2. srs with "ldap:" URI This combination indicates that further information can be gleaned by queries to the LDAP resource indicated by the URI. 7. 'all' categorical enumservice This is a special case of enumservice category. It may be used to indicate that the querying user is interested in any kind of communication, and so all NAPTRs should be considered (i.e. no filtering of NAPTRs based on enumservices should be applied by the DDDS application). This special category may also be used by a registrant who whishes to include a NAPTR or NAPTRs but does not want to specify (within the services field) the services for which each of the NAPTRs is valid. In this case, all NAPTRs are valid regardless of any querying client specified list of categories of interest. 7.1. 'all' expected client behaviour If a client receives a NAPTR that indicates that it is to be considered for all enumservices, then it is forced to act in a set of default behaviours. These behaviours are defined by the scheme of the associated URI, and are covered in section 7.3. There are two choices in the filtering behaviour of the client. In the first, a 'NAPTR' with an 'all' enumservice is treated first, before NAPTRs with a defined category or specific service set. This may be convenient for use with an "enum:" URI, so that the NAPTR is similar to a registrant using a CNAME to redirect requests to some other domain within ENUM space. The other choice is to attempt to match against the enumservices of interest, and only to treat a NAPTR with an 'all' enumservice if the others are not appropriate. This may be convenient if the querying user is Brandner, Conroy, Stastny Expires December, 2002 [Page 9] Internet-Draft Categorical enumservices June 2002 attempting to initiate a communication; they are interested in a particular kind of communication, and might consider the 'any' enumservice as a "less good" match. It seems that both choices are convenient for different URI schemes (the first where an "enum:" URI is used, the second for all others). Thus, it is proposed that the "order of processing" is that a NAPTR with an 'all' enumservice be treated first if and only if the associated URI scheme is "enum:", whilst it is treated last for all other URI-schemes. 7.2. 'all' Implied "low level" services By definition, the 'all' category implies that any "low-level" service might work. Which ones are not specified, and the client has to use the URI-scheme to select the appropriate action. 7.3. all with Associated URI schemes The 'all' category does not specify a particular enumservice, so the client behaviour will reflect default rules that must, perforce, be based on the associated URI scheme. 7.3.1. all with "sip:" URI This indicates that the associated SIP address of record can be used as a contact for all kinds of communications. This combination should be treated as a "fallback" case. NAPTRs with 'sip' and 'talk' or 'msg' or 'srs' should be compared to the category in which the querying user is interested, and only if there is no "more appropriate" NAPTR should this be chosen. 7.3.2. all with "tel:" URI The default behaviour for a "tel:" URI is to use it to initiate an interactive telephony call to a destination specified with the enclosed phone number. Note that the "tel:" URI may have a svc parameter, and this may indicate the specific services supported at this resource. If so, then the services indicated will specify the services (and kinds of communication) that can be used, and these should be displayed to the end user for their selection (or offered to some caller preference scheme within the client end point). 7.3.3. all with "mailto:" URI When used with the all category, this URI has the default meaning that the resource address can be used to send an email. In this case, this NAPTR acts as if it held the 'msg' categorical enumservice. 7.3.4. all with "http:"/"https:" URI In this case, the http or https URI has its default meaning, and the client can use this to extract a document (or other information) available at the resource location indicated. This behaviour is the same as if this NAPTR held the 'info' category. Brandner, Conroy, Stastny Expires December, 2002 [Page 10] Internet-Draft Categorical enumservices June 2002 7.3.5. all with "ftp:" URI In this case, the "ftp:" URI has the default meaning that a document can be extracted from the resource indicated. In this case, the NAPTR can be treated as if the category were 'info'. 7.3.6. all with "ldap:" URI The "ldap:" URI indicates that a query can be made using the associated URI. This can be treated in a similar way to the 'srs' category, in which detailed communications contact information is available using an LDAP query. 7.3.7. all with "enum:" URI One use of this category is to "re-direct" requests to another domain within the ENUM space. If the associated URI-scheme is "enum:" then this means that searches for all classes of communication contact information should be re-submitted using the "enum:" URI value. Note that the enum URI may have its own set of enumservice filters (held in the 'es' parameter). This should be combined with the set of 'enumservices of interest' passed by the querying client, and the set intersection of these two should be used for subsequent ENUM queries. 8. Security issues There are not thought to be any more security issues over and above those described in RFC2916bis. Note that there is a privacy issue in the use of enumservice identifiers. Including category information within the NAPTR makes it accessible to any querying user without authentication, and so exposes data that the registrant may consider sensitive. 9. IANA Considerations The categorical enumservices described in this document are enumservices within the meaning of RFC2916bis, and so this document forms a request for registration of these enumservice labels under the ENUM tree, as specified in sections 2.4.2.1 and 3 of RFC2916bis. 10. Acknowledgments Many thanks to the correspondents on the ENUM WG mailing list for their assistance and cajoling to refine these categories. Clive Feather pointed out that TDD phones are used for a session oriented text "chat" system. Brandner, Conroy, Stastny Expires December, 2002 [Page 11] Internet-Draft Categorical enumservices June 2002 11. Bibliography [1] P. Faltstrom, M. Mealling, "ENUM", draft-ietf-enum-rfc2916bis-0.txt, Work In Progress, February 2002 [2] R. Stastny, R. Brandner, L.Conroy, "Analysis of the Usage of ENUM and ENUM Services", draft-stastny-enum-services-analysis-00.txt, Work In Progress, June 2002 [3] H. Schulzrinne, A. Vaha-Sipila, "URIs for Telephone Calls", draft-antti-RFC2806bis-04.txt, Work in progress, May 2002 [4] R. Brandner, L.Conroy, R. Stastny, "The 'tel:' URI 'svc' parameter", draft-brandner-tel-svc-00.txt, Work in Progress, June 2002 [5] P.Hoffmann, L. Masinter, J. Zawinski, "The mailto URL scheme", RFC2368, Internet Engineering Task Force, July 1998 [6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,M. Handley,E. Schooler, "SIP: session initiation protocol", RFC3261, Internet Engineering task Force, June 2002 [7] R. Brandner, L.Conroy, R. Stastny, 'The "enum:" URI scheme', draft-brandner-enum-uri-00.txt, June 2002 Brandner, Conroy, Stastny Expires December, 2002 [Page 12] Internet-Draft Categorical enumservices June 2002 12. Authors' 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 - Richard Stastny OeFEG Postbox 147 1103 Vienna Austria Msg - Talk - Brandner, Conroy, Stastny Expires December, 2002 [Page 13] Internet-Draft Categorical enumservices June 2002 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Brandner, Conroy, Stastny Expires December, 2002 [Page 14]