ENUM Working Group R. Brandner Internet-Draft Siemens L. Conroy Siemens R. Stastny OeFEG Expires: March, 2003 September 13th, 2002 "A compendium of enumservice registrations" 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 includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. The enumservice names are 'talk', 'voice', 'ivoice', 'video', 'msg', 'fax', 'sms', 'ems', 'mms', 'email', 'chat', 'tp', 'im', 'info', 'web', 'ft', 'srs', and 'all'. 1. Background ENUM is a system consisting of two main elements; it defines an algorithm by which an E.164 number can be mapped to a domain name, together with a means of storing URI information in domain space rooted within a reserved domain label. The URI information is stored within NAPTR Resource Records [1]. Their overall structure and use with ENUM is defined in RFC2916-bis [2]. As defined there, the service field of a NAPTR may have a set of one or more enumservice elements. These enumservice elements are not defined in that document; instead, the enumservices are described separately. This current document specifies a set of such enumservices and requests IANA registration of the enumservice identifiers "under" the ENUM service tree, as laid out in section 3 of RFC2916-bis. 2. Introduction An enumservice acts as a hint, indicating the kind of service with which the URI constructed using the regexp field is associated. There can be more than one enumservice included within a single NAPTR; this indicates that there is more than one service that can be achieved using the associated URI. The common thread with this set of definitions is that they reflect the kind of service that the end user will hope to achieve with the communication session using the associated URI. They also do not require a sub-field to further qualify them; the definition is complete with the main enumservice tag. Services The set of services defined here is intended NOT to specify the protocol or even method of connection that MUST be used to achieve each service. Instead they define the kind of interactive behaviour that an end user will expect, leaving the end system to decide (based on policies outside the remit of this specification) how to execute the service. There are a set of services that may be achieved using telephone connections (where the associated URI scheme is likely to be 'tel:' as described in [3]); several of these service can, however, be achieved using other means. For example, a voice call could be initiated by driving a local PSTN interface, or by connecting to an Internet Telephony Gateway (using an IP network connection) that in turn has a connection to the PSTN. It may be that the destination end point described in the URI is not connected directly to the PSTN but is instead a VoIP end point that is merely identified using a telephone number. In these cases the same service (from the end user's perspective) is achieved by using different methods of connection. It may matter to the end user whether or not their voice call is arranged using a Voice over IP session or using a PSTN connection (for example, there may be a cost to this choice), so it is recommended that the querying User Agent terminal should report the choices to the end user. However, this is a matter for local policy and is outside the scope of this specification. Service Categories For ENUM to be successful, there is an implied cooperation between the registrant who specifies the information to be stored within the ENUM domain space and the querying User Agent that retrieves this data from the DNS. When the registrant specifies the enumservice tag values, the User Agent must share a common understanding of the enumservice tags. The enumservice sub-fields act as a filter, and if the User Agent is "interested in" one set of enumservice tags whilst the Registrant has specified another (disjoint) set of tags, then the NAPTR containing these will be filtered out of consideration. It is possible for an enumservice tag to be too specific; if a querying end user is interested in sending a message to a correspondent, then they may not care whether this message is sent using email, or fax, or SMS (Short Message Service) text, assuming that the equipment they use is capable of sending a message using these services. In this case, a "service category" that subsumes the more specific services is appropriate; this category acts like one of the more specific services and has its own unique tag; the behaviour differs in that it will match both with the same tag but also with the individual services that fall into the category. The querying end user can specify the service category and this will match against a NAPTR that the registrant has specified as supporting one (or more) of the specific services in that category. In the enumservices described in the rest of this document, the "specific" services each fall into a discrete category; thus each category has its own comprised services. For each service description, the enclosing category into which it falls is listed, whilst for each category, the comprised services are listed. Other than this, each definition includes an initial description section, a section on the expected client behaviour if the enumservice is selected by the end system, a section on the URIs that may be associated with the service or category, a definition of the tag string used to identify the enumservice, and the security issues that have been considered for use of the enumservice. 3. 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. 3.1. Comprised Services This category comprises three services. These are voice and its variant ivoice, plus video. This implies that if 'talk' is listed by the end user as being an "enumservice of interest" it will match with itself and also with 'voice', 'ivoice', or 'video' if these are listed within a NAPTR in the queried domain. Likewise, if the Registrant has listed only 'talk' whist the end user has specified 'voice', 'ivoice', or 'video' as being of interest, then again there will be a match. 3.2. 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 client's 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. Note also that, where this category is associated with a "tel:" URI, the expected behaviour is to place a call using the URI. Although possible, the end system SHOULD NOT use the E.164 number that is within the URI to re-submit a request to ENUM. The ENUM DDDS Application describes the standard method for re-submission; this is to mark the NAPTR as being "non-terminal" (i.e. to have an empty flag field), with the resulting processed replacement number being used in the "next round" of the domain discovery process. In such non-terminal NAPTRs there will still be a populated service field, and so this can be used to filter each returned NAPTR record appropriately. 3.3. Appropriate URIs 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. In principle, the category can be associated with any URI that is appropriate for one of its comprised services. 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. 3.3.1. Use 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 category. 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. 3.3.2. Use 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 (see [4]) that specifies the teleservices the resource supports. The 'talk' category implies either voice or video services may be used; if one of these is specified in the 'svc' parameter then this defines which service can be used. If there is no such parameter, or it lists 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. 3.3.3. Use 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. 3.4. Tag String The unique enumservice tag string for the talk categorical service is 'talk'. 3.5. Security Issues The security issues reflect those of its comprised services. Thus the issues are discussed under the 'voice', 'ivoice' and 'video' enumservices. 4. voice service 4.1. Description This indicates that the resource identified by the associated URI is capable of being contacted to provide a communication session during which interactive media streams carrying voice data can be exchanged. 4.2. Enclosing Service Category This service falls into the 'talk' service category. Thus, if the voice service is included either in the end user's list of "enumservices of interest" or in the registrant's list of enumservices supported, it will be matched with the category 'talk' where specified in the corresponding list. 4.3. Expected Client Behaviour The expected client behaviour on selecting this enumservice is to use the URI to contact the remote resource identified by the associated URI (either directly or indirectly) to initiate an interactive voice call. 4.4. Appropriate URIs There are several URI schemes that are appropriate for use with the voice service. These are "tel:", "sip:", and (potentially) "h323:". In each case, the implication is that the resource identified with the URI is capable of engaging in a voice call. 4.5. Tag String The unique enumservice tag string for the voice service is 'voice'. 4.6. Security Requirements The intent of this enumservice is to initiate a voice call. There may be cost implications in this, and particularly where a particular method is used to execute the service. For example, use of the GSTN may incur a cost for the calling (and/or called) user. This cost may vary depending on the destination and the teleservice invoked by initiating the voice call, and the cost may be considerable (as in calls to "information" teleservices). Where the NAPTR generates a "tel:" URI, this cost may not be known by the end user a priori. The end user's expectation of cost may be conditioned by the E.164 number that is input to the ENUM process rather than the E.164 number contained in the "tel:" URI that is its result. Thus it is important either to report the eventual E.164 number to the end user so that they can decide whether or not to proceed with the session, or to employ some pre-arranged policy by which the end system is aware of the user's choices. Where a "sip:" or "h323:" URI is generated, the situation may be more complex; it is possible that the end user incurs a cost in proceeding with a voice call even if the "first step" is carried using a VoIP session over an IP network. With SIP, the initial negotiation included in that protocol may result in a re-direction, providing a new URI that is then processed further. Again, it is important to either present the URI to the end user or to implement some pre-arranged policy. Where the resulting URI holds an E.164 number, there is a risk of looping if this is used to re-submit a query to the ENUM infrastructure. This issue only arises where an associated "tel:" URI is present. To avoid this risk, the E.164 number held in a "tel:" URI that is associated with a NAPTR that results from an ENUM query SHOULD NOT be used to re-submit a query to the ENUM infrastructure. This risk is also present in the basic DDDS algorithm, as a non-terminal NAPTR may either have a mis-configured replacement field that, when processed, results in a loop, or a mis-configured regexp field that, once processed, has a similar effect. The recommendation that a "tel:" URI not be used to re-submit a query to ENUM removes one avenue for mistake or attack. 5. ivoice service 5.1. Description This is a variant on the voice service. It can be used as a convenient way of indicating that the resource indicated by the associated URI is connected to an IP network, and that it can be used to engage in a voice call (i.e. it is otherwise identical in operation to the voice service). 5.2. Enclosing Service Category This service falls into the 'talk' service category. Thus, if included either in the end user's list of "enumservices of interest" or in the registrant's list of enumservices supported, it will be matched with the category 'talk' where specified in the corresponding list. 5.3. Expected Client Behaviour The expected client behaviour on selecting this enumservice is to use the URI to contact the remote resource identified by the associated URI to initiate an interactive voice call. In particular, if the end system is capable of using a Voice over IP method of communication rather than delivering the call request to the PSTN, then this may result in better voice quality (through minimizing the number of media transcodings the voice traffic encounters). It acts as a "hint" only, and can be considered otherwise identical to the voice service, and can be matched against this. 5.4. Appropriate URIs There are several URI schemes that are appropriate for use with the ivoice service. These are "tel:", "sip:", and (potentially) "h323:". In each case, the implication is that the resource identified with the URI is capable of engaging in a voice call. This service differs from the voice service only in that, in the case of an end system that is capable both of initiating a call via a local GSTN interface and using an IP connection to a service provider, the ivoice service hints that the latter approach should be used. Some service providers may use E.164 numbers natively, even though the destination is actually an IP connected resource. If the end user has an association with such a service provider, then they may choose to initiate the call via that provider rather than attempting to place the call via a local GSTN interface. 5.5. Tag String The unique enumservice tag string for the ivoice service is 'ivoice'. 5.6. Security Requirements The security issues for this enumservice are believed to be identical to those for the voice enumservice. 6. video service 6.1. Description This indicates that the resource identified by the associated URI is capable of being contacted to provide a communication session during which interactive media streams carrying video data can be exchanged. 6.2. Enclosing Service Category This service falls into the 'talk' service category. Thus, if included either in the end user's list of "enumservices of interest" or in the registrant's list of enumservices supported, it will be matched with the category 'talk' where specified in the corresponding list. 6.3. Expected Client Behaviour The expected client behaviour on selecting this enumservice is to use the URI to contact the remote resource identified by the associated URI to initiate an interactive video call. For further details, see the specific comments in the URI section, next. 6.4. Appropriate URIs Several URI schemes may be used with this service. These are "sip:", potentially "h323:", and "tel:". If a URI has been included within a NAPTR indicating this service, then it can be assumed that the resource so identified is capable of exchanging video data. In the "tel:" case, the PSTN-based video teleservice also includes a channel for voice communications, so that this enumservice, when it occurs with a "tel:" URI, can be assumed to provide voice as well as video communications. This is not necessarily the case for "sip:" and "h323:", where the registrant is asserting only that the resource identified is capable of supporting video communications. Whether or not this resource also supports voice media exchange will be uncovered during the negotiation phase associated with those protocols. 6.5. Tag String The unique enumservice tag string for the video service is 'video'. 6.6. Security Requirements The security issues for this enumservice subsume those for the voice service. In addition, if the associated URI addresses a remote resource that is capable only of providing video stream exchange, there MAY be a privacy issue. Where voice calls are to be initiated, it is normal to alert the called user; however, for video only exchanges, this is less common. If contact addressing information is published within ENUM domain space, then it is available globally, and there is an implication that this addressing information can be used to initiate a video call from anywhere. Thus it is important that the registrant is aware of the configuration of their equipment and that, having told everyone how to contact their video camera, this information may be used to make such a call. 7. msg categorical service 7.1. Description 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. 7.2. Comprised Services This category comprises the 'fax', 'sms', 'ems', 'mms' and 'email' services. Thus, if either the Registrant or the user lists one of these services as being supported or of interest, whilst the other lists the 'msg' enumservice, then these lists will match. 7.3. Expected Client Behaviour When the end user selects the msg category as being of interest and there is a match within the queried domain, the URI that results from regexp processing of the NAPTR can be used as the destination address of a remote resource that is capable of receiving a (non-session related) message. Thus the end system can initiate a connection to that resource and can transfer a message or document to it. The detailed end system behaviour depends on the associated URI scheme. This is described in more detail under the Appropriate URIs sub-section. There are two main behaviours; if the URI scheme is "mailto:" (defined in [5]) then the behaviour will be similar to that of the 'email' service. However, if the URI scheme is "tel:" then the end system may have to evaluate the URI in order to choose which program (and communication method) it must activate. The "tel:" URI can include a 'svc' parameter. If so, this parameter value can identify the kind of teleservice the resource supports. This might be 'fax', or 'sms', 'ems', or 'mms'. If there is no such parameter, then Fax service may be assumed to be "the default", and a fax program can be started using the associated URI as the destination address. Only if the svc parameter exists and includes 'sms', 'ems', or 'mms' should an attempt be made to send such a message towards the remote terminal. 7.4. Appropriate URIs As just mentioned, there are two URIs associated with this category; these are "tel:" and "mailto:". 7.5. Tag String The unique enumservice tag string for the talk categorical service is 'msg'. 7.6. Security Issues The security issues reflect those of its comprised services. Thus the issues are discussed under the 'fax', 'sms', 'ems', 'mms', and 'email' enumservices. 8. fax service 8.1. Description This indicates that the resource identified by the associated URI is capable of being contacted to provide a communication session during which facsimile documents can be sent. 8.2 Enclosing Service Category This service falls into the 'msg' service category. Thus, if included either in the end user's list of "enumservices of interest" or in the registrant's list of enumservices supported, it will be matched with the category 'msg' where specified in the corresponding list. 8.3. Expected Client Behaviour The expected client behaviour on selecting this enumservice is to use the URI to contact the remote resource identified by the associated URI to initiate an interactive fax call, during which it can send documents to that remote resource. 8.4. Appropriate URIs There is one URI scheme that is appropriate for use with the fax service. This is "tel:". Under some circumstances, it may be possible to use another URI scheme to send a fax document, such as "sip:", (potentially) "h323:", or even "mailto:". However, these schemes are not considered in this document. 8.5. Tag String The unique enumservice tag string for the voice service is 'fax'. 8.6. Security Requirements There are similar security concerns here to those associated with voice. 9. sms service 9.1. Description This indicates that the resource identified by the associated URI is capable of receiving a message using the Short Message Service (SMS). 9.2. Enclosing Service Category This service falls into the 'msg' service category. Thus, if included either in the end user's list of "enumservices of interest" or in the registrant's list of enumservices supported, it will be matched with the category 'msg' where specified in the corresponding list. 9.3. Expected Client Behaviour The expected client behaviour on selecting this enumservice is to use the URI to contact the remote resource identified by the associated URI to send a message using SMS. For further details, see the specific comments in the URI section, next. 9.4. Appropriate URIs Only the "tel:" URI scheme may be used with this service. Potentially the "sip:" or "mailto:" schemes might be used, IF the end user has a relationship with a service provider that can gateway to an SMS-capable destination. Such gateway services are not specified in this document. If a URI has been included within a NAPTR indicating this service, then it can be assumed that the resource so identified is capable of receiving and processing SMS messages. 9.5. Tag String The unique enumservice tag string for the SMS service is 'sms'. 9.6. Security Requirements The security issues for this enumservice subsume those for the voice service. There is a further issue with privacy. ENUM is a globally accessible system, and indication that a resource is used only for sms may expose the fact that the registrant may have hearing difficulties. 10. ems service 10.1. Description This indicates that the resource identified by the associated URI is capable of receiving "enhanced message service" (EMS) messages. This is a variant on SMS, and shares many features with it. 10.2. Enclosing Service Category This service falls into the 'msg' category. Thus it can be matched with an entry of 'msg' in the corresponding list of enumservices supported or "of interest". In addition, support for EMS implies support for SMS as EMS is a superset of the basic Short Message Service. Thus if EMS is shown as a service supported by a registrant's resource, then it will match with SMS if that is included in an end users list of "enumservices of interest". 10.3. Expected Client Behaviour On selecting this enumservice (and its enclosing NAPTR) the client is expected to contact the remote resource (indirectly) to send an Enhanced Message to it, using the associated URI to address the destination. However, the end system MAY report to the user that SMS is available at the remote resource even though the user has selected EMS as being of interest - SMS is a sub-set of EMS and so may form a valid communication method. 10.4. Appropriate URIs The EMS service is a superset of SMS, and also may only be used with a "tel:" URI. 10.5. Tag String The unique enumservice tag string for the EMS service is 'ems'. 10.6. Security Requirements The security issues are identical to those for the SMS enumservice. 11. mms service 11.1. Description This indicates that the remote resource identified by the associated URI is capable of receiving Multimedia Messaging Service (MMS) messages. In this specification, it is assumed that the destination is connected to a Mobile Service Provider and has an MMS-capable terminal. Current deployments of MMS allow a Multimedia Message to be sent to a destination email address via a Service provider operated gateway. They also allow MMS messages to be sent when these are addressed to terminals that can only receive SMS messages; the MMS message is processed and stored at a Gateway, with a notification SMS message being sent to the intended destination along with authorisation codes for access to the storage portal. These are part of a developing infrastructure, but this service is intended solely to indicate that the remote resource is capable of receiving an MMS and of processing it itself. 11.2. Enclosing Service Category This service falls into the 'msg' category. This means that it will match against an entry in the corresponding service list that holds 'msg'. Where indicated in a NAPTR, the mms service will also match against EMS and SMS services requested by the end user, as MMS-capable terminals can process both Enhanced and Short Message Service messages. 11.3. Expected Client Behaviour When this service is selected by the end user, the end system is expected to use the associated URI to address the remote resource to transfer an MMS message (via the local Service Provider's MMS Service Centre) to the destination device. 11.4. Appropriate URIs This document considers only a remote destination that is an MMS-capable mobile terminal. At present these are addressed using E.164 numbers, so that the only appropriate URI that can be associated with this service is the "tel:" URI. In future, this may need to be re-considered, as the MMS architecture is still under development and the current documents suggest that ENUM may be used to expand the possible list of addressing modes. It is not yet clear how the gateway systems will be developed, so that email addressing may allow other URI schemes to be used later. 11.5. Tag String The unique enumservice tag string for the MMS service is 'mms'. 11.6. Security Requirements The security issues are identical to those for the SMS enumservice, when used with a "tel:" URI. If other methods are used to deliver MMS messages, then there may be further issues. As the MMS architecture (and way in which these messages can be delivered) becomes clear with deployment, this may need to be re-considered. 12. email service 12.1. Description This service indicates that a remote resource can be addressed by the associated URI in order to send emails. 12.2. Enclosing Service Category This service falls into the 'msg' service category. Thus, if included either in the end user's list of "enumservices of interest" or in the registrant's list of enumservices supported, it will be matched with the category 'msg' where specified in the corresponding list. 12.3. Expected Client Behaviour If the end user system has selected the email service, then it is expected to use its chosen local application to send an email towards the remote email address held in the "mailto:" URI. Note that the inclusion of this service in a NAPTR implies that the registrant's resource is capable of receiving an email; the connection method and protocol chosen by the registrant and by the sending end user need not be related. For example, the registrant may have access to a Service Provider portal that displays incoming emails in a Web browser window, whilst the sender uses a proprietary scheme like MAPI to deliver the mail to their local server. Assuming that the destination is capable of receiving SMTP emails, then this service will function. 12.4. Appropriate URIs This service is associated only with the "mailto:" URI. 12.5. Tag String The unique enumservice tag string for the email service is 'email'. 12.6. Security Requirements If a registrant populates their domain with a NAPTR indicating this service, then, as ENUM is a globally accessible system, this listing may be harvested by "junk email" senders. Thus the registrant should be aware that such a listing is likely to expose them to a great deal of junk email. 13. chat categorical service 13.1. Description This service category indicates that the remote resource is capable of engaging in chat sessions (i.e. session-oriented message exchanges). 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. 13.2. Comprised Services There are two services that are included within this category. These are the 'tp' and 'im' services. This means that, if an end user has indicated interest in the chat category, then this will match with a NAPTR that includes either the 'tp' or 'im' service tags (as well as with itself). Similarly, if the end user has registered an interest in a 'tp' or 'im' session but the registrant lists the 'chat' category, then this will match as well; thus the end system may have to carry out further evaluation of the NAPTR to decide if it is appropriate. 13.3. Expected Client Behaviour The use of a category can imply some further evaluation is needed. If the registrant lists only the chat category within a NAPTR whilst the end user has specified either of the enclosed services, then the end system may need to evaluate the associated URI to decide if they have local support for this protocol and so can use it for their communication session. Conversely, if the end user has specified only that they are interested in a chat session, whilst the registrant has specified support for either 'tp' or 'im', then as the end system is aware of its capabilities, it can decide without further evaluation whether or not this NAPTR is appropriate. Finally, if both end user and registrant have specified only the chat category, then the end system must evaluate the NAPTR to decide if the resulting URI matches its capabilities for protocol handling. It is possible to duplicate the URI scheme string as the sub-field for this categorical enumservice as a convenience for the end system, so avoiding the regexp processing step before the usability of the NAPTR can be decided. This is optional, but should be considered by registrants when populating their domain with NAPTRs. 13.4. Associated URIs This category matches with the services it comprises. Thus, it may be encountered with any of the URIs that the 'tp' or 'im' services may use. 13.5. Tag String The unique enumservice tag string for the chat service category is 'chat'. 13.6. Security Requirements The security issues for this category include those of the services it comprises. This category may be chosen as a way of obscuring the presence of a textphone resource. Given the simple evaluation mentioned in the Client Behaviour section above, this is not particularly opaque, but it may make the registrant more comfortable with a listing in the globally accessible ENUM infrastructure. 14. textphone service 14.1. Description This service indicates that a remote resource addressed by the associated URI is capable of involvement in a textphone session. This is a group of systems that use the telephone network to transfer character data between compatible terminals. These are commonly used by users who have hearing problems. 14.2. Enclosing Service Category This service falls into the chat category. This means that if either the Registrant or the end user lists 'tp' whilst the corresponding person lists 'chat', a match will be considered to occur. 14.3. Expected Client Behaviour When this service is selected by the user, the end system can activate its local textphone terminal and initiate a call to the remote terminal addressed using the associated URI. 14.4. Appropriate URIs Textphone systems all use the telephone network, and so the appropriate URI is "tel:". There are several kinds of textphone in use. For example, in the United Kingdom, the variant is the 'minicom' system, whilst elsewhere there are systems that conform to the "Telecommunications Device for the Deaf" (TDD) scheme. The "tel:" URI can include a svc parameter, and one of the values for this parameter is 'tdd'. This can be used to indicate that the remote resource interoperates to this system. [Note - it is intended to update the specification document for the "tel:" 'svc' parameter to include other values to help delineate between the different textphone systems - any help in identifying the discrete textphone systems in use would be appreciated] Thus, it may be necessary for the end system to evaluate the URI before it can be sure whether it supports the particular textphone system "advertised" in the NAPTR. 14.5. Tag String The unique service tag string for the textphone service is 'textphone'. 14.6. Security Requirements Textphone terminals tend to be dedicated devices, and so there do not seem to be many security concerns (from an Internet perspective). However, there may be a privacy issue. A registrant may not feel comfortable in specifying this service is a directory that is globally accessible, even if they are willing to indicate support for this service in other places. Thus, under no circumstances should they be forced to list this capability. One option is to obscure this slightly by being less specific in the services listed in the NAPTRs; thus, the 'chat' category might be listed instead of the more specific 'tp'. Such a choice adds no security at all, but may be considered preferable by the Registrant. 15. im service 15.1. Description This service indicates that the remote resource is capable of engaging in a session-oriented "instant message" exchange. 15.2. Enclosing Service Category This service falls into the chat category. Thus if one party lists this service whilst the other lists the chat category, there will be a match. 15.3. Expected Client Behaviour If this service is selected by the user, then their end system can try to initiate an instant messaging session to the remote messaging entity addressed by the associated URI. 15.4. Appropriate URIs At present, the only URI scheme that is appropriate for this service is "sip:", as specified for the SIMPLE instant messaging scheme. As other (session-oriented) messaging URI schemes are standardised, so the user might expect their end system to evaluate the URI and decide whether or not this scheme can be supported. Note that the listing of an im service within a NAPTR does not indicate whether or not the registrant (or their terminal) is actually available for an instant messaging session at any given time. The particular IM protocol will include its own procedures to initiate the session. 15.5. Tag String The unique enumservice tag string for the im service is 'im'. 15.6. Security Requirements The inclusion of a listing within the ENUM system does not seem to add new security issues over those for any use of instant messaging. 16. info categorical service 16.1. Description 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. 16.2. Comprised Services The info category comprises the services 'web', 'ft'. This means that, if either of these is selected by the end user (or listed by the registrant) then there will be a match with 'info' if it is within the corresponding list. 16.3. 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. The end system may have to perform further evaluation of the associated URI to decide whether or not it can support the URI scheme. As an option, the registrant may choose to duplicate the URI scheme tag by using this as the content of the "protocol" sub-field of this enumservice field; doing so may allow the end system to select the appropriateness of the NAPTR without performing a regexp operation. Note that one use of this enumservice is to indicate an announcement or information line. This is particularly convenient when used with the "tel:" URI, but might be used with other URI schemes. However, it may require further evaluation of the associated URI before the appropriate action can be performed. The "tel:" URI may include an 'svc' parameter (described in [4]), and this may need to be evaluated before appropriate action can be performed. Note 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. 16.4. Appropriate URIs This enumservice can be used with several URI schemes. The behaviour in these cases is listed next. 16.4.1. Use with an "http:" or "https:" URI This will perform identically to the 'web' enumservice. 16.4.2. Use with an "ftp:" URI This will perform identically to the 'ft' enumservice. 16.4.3. Use with a "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. 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. 16.5. Tag String The unique enumservice tag string for the info category is 'info'. 16.6. Security Requirements Security issues for this category have not been fully analysed yet. Some issues are immediately clear, however, when it is used with certain URI schemes. For example, when used 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. 17. web service 17.1. Description This enumservice indicates that the remote resource identified by the associated URI is capable of providing documents when contacted using web protocols; in short, it acts as a web server for the data addressed by the associated URL. 17.2. Enclosing Service Category This service falls into the 'info' category. This means that if included in either the end user's list of "services of interest" or in the listings specified by the registrant, it will match with the 'info' category in the corresponding list. 17.3. Expected Client Behaviour When the web service is selected, the end system can use a web protocol to contact the remote resource addressed by the content of the associated URI. In practice, this normally means that a local Web Browser will be activated with the URI as the target to be returned. 17.4. Appropriate URIs This service is associated with the two URI schemes "http:" and "https:". If the end system is not capable of dealing with an SSL/TLS session, it may be necessary for it to evaluate the associated URI before deciding whether or not it can support the service. Whilst this is not an issue for personal computers, it may well be an issue for small devices (such as mobile phones). It is possible for the registrant to duplicate the URI scheme tag as the content of the 'web' enumservice protocol sub-field. In so doing, the end system would be saved from having to perform the regexp processing before deciding on whether or not the URI would be appropriate. 17.5. Tag String The unique enumservice tag string for the web service is 'web'. 17.6. Security Requirements Whilst in principle the security issues are similar to any use of HTTP or SSL/TLS, there are some issues in performance and on automatic web download. For example, it is possible for a terminal that receives "Calling Line Identity Presentation" teleservice to use ENUM to find further information on the caller, automatically downloading and displaying the 'web' content. Whilst this "Super Caller Display" may be a useful service, it does open the end system to the risks of insecure Web Browser implementations without the end user being given any hint of what's going on. It is important, therefore, that the kind of content automatically downloaded is limited. Similarly, some terminals that perform ENUM queries may have a limited data bandwidth. Thus it is recommended that the data size for the resource addressed by the URI be limited, and that this potential behaviour should be considered by the registrant. Not every user will have a broadband connection. Finally, there are situations in which there is a cost implication to data download; the end user may be charged per unit of data transferred. Thus, if the end system is set to download automatically the resource indicated by the associated URI, then the registrant's choice of large resources may have a significant cost implication on the end user. 18. file transfer service 18.1. Description This service implies that the associated URI identifies a remote resource provides a file service from which an addressed document (or file listing) can be retrieved. 18.2. Enclosing Service Category This enumservice falls into the info category. This means that if either the Registrant or the End user lists the 'ft' tag, whilst the other lists the 'info' tag, then there will be a match. 18.3. Expected Client Behaviour If this service is selected then the end system can start a file transfer client program, using the associated URI as the address of the remote item to be retrieved. 18.4. Appropriate URIs At present, the only URI specified for use with this is "ftp:". It is possible in the future that other URIs might be used, for other file transfer schemes (such as the proprietary "afp:" or "smb:"). However, it is unclear yet whether these are useful for a system that is accessible globally; they are used mostly in corporate environments and are unlikely to be (intentionally) available across the Internet. 18.5. Tag String The unique enumservice tag string for the file transfer service is 'ft'. 18.6. Security Requirements The file transfer service suffers from the same security considerations as for any use of the FTP protocol. The inclusion of a listing in the ENUM system does not appear to add any further issues. 19. srs categorical enumservice 19.1. Description This category is used where the Registrant wants to use a specialised "Service Resolution Service" above and beyond ENUM. It can be used where the services available depend on factors that cannot be covered in the global ENUM system; for example, the services "advertised" may depend on the person asking, and so requires authentication to be performed before any detailed information is returned. 19.2. Comprised Services This category comprises two main services; dap and sip. Of these, the 'sip' service has a rich feature set and will be described in a separate document. 19.3. Expected Client Behaviour If the end user has selected this as an "enumservice of interest" then the client should filter out all NAPTRs but those containing either the 'srs', 'sip', or 'dap' tags, together with any NAPTRs showing the 'all' category and where the processed URIs indicate either "sip:" or "ldap:". If the Registrant has chosen to include only a NAPTR with either the 'srs' tag or that of one if its constituent enumservices, then the client can either initiate the "next stage" of service resolution directly, or report that this is required and await the end user's response. In either case, this is the end of ENUM processing; further evaluation continues using the features of the constructed URI. 19.4. Associated URIs At present, there are expected to be two URIs that can be associated with this category; "sip:" and "ldap:". 19.5. Tag String The unique enumservice tag string for this category is 'srs'. 19.6. Security Requirements The security issues of this category reflect the services of which it is comprised. There is intended to be a separate document to specify the sip enumservice and this will address the security issues of the evaluation and session initiation process. 20. dap service 20.1. Description This service indicates that further evaluation and addressing information for sessions can be obtained using the "ldap:" associated URI. 20.2. Enclosing Service Category This service falls into the srs category. 20.3. Expected Client Behaviour --- TBC --- 20.4. Associated URIs This service is associated only with the "ldap:" URI scheme. 20.5. Tag String The unique enumservice tag string for the dap service is 'dap'. 20.6. Security Requirements --- TBC --- 21. 'all' categorical enumservice 21.1. Description This category is a special case in that it includes all other enumservices within it. The goal is to provide a default category. This may be used to indicate that the services supported with a NAPTR are not specified in any more detail. In effect, the Registrant is asserting that this NAPTR supports ALL enumservices. However, in practice it means that further processing (by evaluating the regexp and so constructing the associated URI) is needed before the end system can be sure whether to discard the record or not. When the end user specifies this category as the "enumservice of interest" they are stating that ANY returned NAPTR is acceptable to them. 21.2. Comprised Services This category comprises all other enumservices. 21.3. Expected Client Behaviour When processing a NAPTR that indicates the 'all' enumservice, the client will have to evaluate the NAPTR to extract the URI, as there is no other information in the service field to help it filter the returned NAPTR set. Of course, the normal order and preference field values can be used to prioritise processing of the NAPTRs, but further processing may be needed to decide whether or not the NAPTRs meet the interests of the end user. However, if the end user has specified their "enumservices of interest" to include this category, then the end system ENUM client has little choice but to pass the returned NAPTRs to the calling client application for it to handle using its own decision process. 21.4. Appropriate URIs This compendium category can be used with all URIs listed as appropriate for use with any other enumservice. 21.5. Tag String The unique enumservice tag string for the "all" category is 'all'. 21.6. Security Issues The security issues in the use of this category have not been analysed yet. 22. General Security Issues There are not thought to be any more security issues over and above those described in RFC2916-bis or in the descriptions above. 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. 23. IANA Considerations The services and categories described in this document are enumservices within the meaning of RFC2916-bis, 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 RFC2916-bis. 24. Acknowledgments Many thanks to the correspondents on the ENUM WG mailing list for their assistance and cajoling to come out with "concrete proposals". Arnoud van Wijk pointed out sms as being important for non-hearing people, and that it is useful to indicate "sms only!" for a mobile phone number. Clive Feather pointed out that TDD phones are used for a session oriented text "chat" system. 25. Bibliography [1] M. Mealling, "DDDS - The DNS Database", May 2002, draft-ietf-urn-dns-ddds-database-09.txt - Work In Progress [2] P. Faltstrom, M.Mealling, "The E.164 to URI DDDS Application", June 2002, draft-ietf-enum-rfc2916bis-01.txt - Work In Progress [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 26. 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 - 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.