Internet-Draft R.Brandner Catogory: Standards Track Siemens L. Conroy Siemens R. Stastny OeFEG Expires: December, 2002 June, 2002 "The 'tel:' URI 'svc' Parameter" draft-brandner-tel-svc-00.txt 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 describes the 'svc' parameter for use within a 'tel:' URI. This is intended to indicate the uses to which a resource identified via the 'tel:' URI can be put. It is an optional parameter, and if not understood can be ignored. It allows the user to "hint" at the features supported at the resource. There are guidelines for how this parameter might be used, and for expected behaviour on detection of this parameter. Brandner, Conroy, Stastny Expires December, 2002 [Page 1] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 1. Introduction The 'tel:' URI [1] indicates a resource that can be addressed via a telephone number. This is useful both for session protocols (for example, with SIP [2]) and can also be used within the ENUM [3] domain space or as an element within a Web page as a "static" value. Within the GSTN, a telephone number may be associated with a device that supports only a limited number of features (or services). For example, a particular number may be associated with a Fax machine, whilst another is associated with a voice telephone only. Most mobile telephones can send and receive "Short Messages" and this support is being extended to fixed lines in regions. It can be useful to indicate support for this feature when defining the URI, as it is not possible to predict from inspection whether or not a terminal associated with this URI has support for this feature (or has an indirect service giving this support). This indication may be particularly important for individuals who use this text service in preference to voice. Similarly, some voice lines have a TDD (textphone) connected, and allowing a URI to indicate this may also be important to those people who want to use this means of communication rather than voice (or other services). 1.1 Document Structure This section has introduced the rationale for an aditional parameter to indicate services available with a particular 'tel:' URI. The next section decribes the proposed syntax and use of this parameter. Following on is a section clarifying the optionality of this parameter, together with the expected behaviour of a node in receiving such a parameterised URI. Finally the security and privacy issues are discussed; note that the main concerns here are privacy issues. 2. Teleservice feature indication 2.1 teleservices to be indicated There are a number of different teleservice features that might be associated with a resource contacted via a telephone number. The list of features shown in this document is general and covers only those services that do not include intrinsic negotiation as part of the feature. * voice - this resource supports voice communication * video - this resource supports video communication * fax - this resource supports reception of fax messages * sms - this resource supports reception of short messages * tdd - this resource supports TDD communication sessions Brandner, Conroy, Stastny Expires December, 2002 [Page 2] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 Note that, for example, the fax feature does not specify whether Group 2, Group 3, or even Group 4 fax is usable at this resource. This is because, in general, fax communication includes a negotiation phase by which the class of fax protocol is negotiated. In addition, the video feature does not specify any particular video system to use. It could be any system that is able to transmit video and audio. There are some variants on the above that may also be present. If these are used, then they can be considered in most circumstances as extensions of the above services. * ivoice - this resource supports voice communication AND is associated with an IP-connected end point * mms - this resource accepts reception of short messages AND multimedia messages The 'ivoice' term might be used, for example, if the holder of the URI is able to choose whether to use a direct GSTN connection or instead to use an IP-network connection. It might also be used in particular within a Telephony Service Provider's network to select the appropriate Point of Interconnection towards the destination. This can be important if that Service Provider uses IP-trunking or other network-internal schemes that have already introduced a transcoding step in the communications path. How a forward path can be found is out of scope of this document and is discussed further in [4]. For those holders of the URI not capable of selecting an optimised forward path for their communication, the 'ivoice' service can be considered identical to the 'voice' service. The 'mms' term is used to indicate that the resource is capable of receiving not only "standard" SMS messages but also the enhanced messages that are in the process of standardisation at present. All terminals capable of receiving these MMS messages are also capable of receving SMS messages, and so this is a pure superset of the 'sms' tag. 2.2 Syntax for 'svc' parameter The following is the ABNF for this parameter. It is intended as a parameter label followed by comma-separated list of value terms. The value terms indicate a set of potential teleservice features. The 'svc' parameter is defined using the ABNF (augmented Backus-Naur form) described in RFC 2234 [5]. Note that this parameter fits within the 'other' parameter syntax as described in [1]. Brandner, Conroy, Stastny Expires December, 2002 [Page 3] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 The syntax for the 'tel:' URI 'svc' parameter is: svc-param = svc-label "=" svc-values svc-label = "svc" svc-values = 1*(teleservice-term) [*("," teleservice-term)] teleservice-term = ( "fax" / "ivoice" / "mms" / "sms" / "tdd" / "video" / "voice" ) 3. Expected Behaviour In many ways, the 'tel:' URI scheme is unusual in that it is not tied to a particular Internet Protocol or set of protocols. Thus acting on receipt of a 'tel:' URI does not result in triggering a defined Internet protocol exchange. Normally one would expect a terminal either to run a dialer program that controls an external device connected to the GSTN (such as a telephone or fax modem) or, if it did not have access to such a device, to use this URI as a parameter to a session control program (such as a SIP User Agent). The control of an external GSTN-connected device can be either direct (as with an external modem/phone connected to a serial or USB port) or can be indirect, via one of the number of "Network Telephony Device Control" protocols. These schemes are not (and should not) be specified here; it is a subject of much standardisation in external fora, and of competition. All that can be assumed is that the recipient of a 'tel:' URI is aware of the local availability of a telephony device controller, or of a session control program that can use such a URI. In either case, the URI may be used to initiate a communication. However, the URI may still be used even if the recipient has no desire to start a communication; for example, the user may want to store this information in an address book or display it on a web page. The rest of this section covers the potential actions on receipt of a 'tel:' URI with a 'svc' parameter. Given the wide use of the URI scheme, this can only be advisory, and is NOT normative. 3.1 Optionality As defined in the 'tel:' URI specification [1], there are two classes or external parameters that may be used with a 'tel:' URI. These are mandatory parameters in which the parameter label starts with "m-", and optional parameters that must not start with this string. Mandatory parameters must be understood by the recipient of the URI and SHOULD NOT be ignored. Optional parameters however can be ignored safely and need not be understood by the client. In the case of the 'svc' parameter, the information carried is a list of 'hints' on the communications features associated with the resource. As these are hints, it is not appropriate for this parameter to be mandatory. Brandner, Conroy, Stastny Expires December, 2002 [Page 4] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 The value of the 'svc' parameter is a comma separated list of supported teleservice features. These are hints to the client, so that the client is aware of the appropriate communications program that can be run. Thus, although the parameter is optional, the hints should be considered as a filter when initiating communications. If this parameter is present in a URI, the client is not forced to initiate any one of the teleservices listed in the parameter value, but SHOULD NOT try to initiate a service that is not listed; the value is a filter to exclude possibilities. 3.2 Strategies for processing a 'tel:' URI with a 'svc' Parameter The aim of this sub-section is to highlight what an end user might expect to happen both having declared the information (i.e. to make available such a parameterised URI) and having received such a URI. As just mentioned, the svc parameter value is intended as a hint of the communications features supported at the resource. This means that a URI 'svc' parameter that includes, for example, fax, is capable of receiving a fax message. In this situation it is appropriate for the client to run fax software. If the value does NOT contain, for example, 'sms', then the client SHOULD NOT attempt to send an sms to the resource. Note that it is recommended that a 'tel:' URI containing a 'svc' parameter should not have that parameter stripped if the URI is passed onwards or copied unless it has good cause to do this. However, there are a number of issues that should be taken into account when using a 'tel:' URI. 3.2.1 Age Sensitivity of stored URIs If, for example, a parameterised 'tel:' URI is to be stored in a local "Address Book", then the "life expectancy" of that entry should be considered. This is a general issue with address book storage of old entries as people move and a number may be re-allocated to someone wholly unconnected with the original contact. It is also an issue for a URI with a 'svc' parameter. People do change the services associated with a number over time, and so caution should be taken when using (for example) a 'tel:' URI that indicates that the number is associated with a fax service, if that URI was last collected some time ago. If the potential target of a communication has swapped the line they use for their phone and fax machine, the resultant conversation may not be successful. Similarly, Telephony Service Operators may bring in new service features (such as, for example, support for SMS messages on a fixed line), so that over time the 'svc' list may be outdated or overly restrictive. Brandner, Conroy, Stastny Expires December, 2002 [Page 5] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 In this situation, the 'tel:' URI in an address book may have exceeded its "shelf life". In particular, the 'svc' parameter should be treated as advisory and either a new verion of the URI should be captured or, at least, the user should be informed explicitly of the success or otherwise of a communication based on an "old" URI. As the 'tel:' URI is often used with communications involving humans rather than machines, it is more of an issue that simply having an outdated 'http:' URl, for example. Sending a fax to a voice line can be irritating and could be considered offensive. 3.2.2 Privacy A 'tel:' URI containing a 'svc' parameter may have been passed to a user. This does not mean that the user has the right to pass on information on the capabilities associated with the resource to a third party. Thus, when using a 'tel:' URI in a session initiation, for example, it may be that the 'tel:' URI DOES have the 'svc' parameter stripped, if the holder of that URI is unsure whether or not the 'svc' information may be considered sensitive by the individual associated with the resource. Similarly, this stripping may be done by an intermediary on the same privacy grounds. 3.2.3 Extended Usage Issues It may be tempting to add this indication to all tel: URIs, regardless of how and where they are used. For example, it might seem useful to add a service indication to a SIP URI to show the available registrations and so the potential sessions that may be started. However, this is discouraged. Protocols designed for session initiation, such as SIP, have their own mechanisms for negotiation, and those should be used where available. 4. Security Issues As a general issue with 'tel:' URIs, a client application that collects a 'tel:' URI SHOULD present this in some way to its user before acting on it. The URI may result in a cost to the user, and that user has a right to select whether or not they want to incur this cost. This also means that they agree to the particular teleservice indicated by the 'svc' parameter. For example, in some regions choice of one service rather than another may well have cost implications. There are no other 'pure' security implications above those for a "standard" 'tel:' URI. The rest of these points focus on privacy issues. These should not be underestimated. If a 'tel:' URI is placed on a publicly accessible location such as a Web page (or within the ENUM domain space), then by definition anyone may collect the information. Thus the person who is associated with the destination resource should be aware of this fact and agree to it being published in context. Brandner, Conroy, Stastny Expires December, 2002 [Page 6] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 They may be comfortable making this information available at a server with restricted access (such as a Company Intranet or a server providing authenticated access only to a controlled group of people), but may not be comfortable with exactly the same information being made available to a global audience. Thus not only the agreement of the user should be sought to publish, but it should be confirmed that they accept the scope of this publication. As a more specific case, the individual who is associated with the resource will expose capability information by using the 'svc' parameter - that is, after all, the purpose of this parameter. This may be a privacy concern, particularly when a parameterised 'tel:' URI is stored in a globally accessible system like ENUM. Some capability information may be sensitive; for example, the person associated with the resource may be uncomfortable exposing the fact that a number is associated with a terminal from which some disability can be implied, such as a 'tdd' device. 5. IANA Considerations This document describes a parameter that can be used to carry teleservice feature information qualifying a 'tel:' URI. To ensure that this parameter tag value does not collide with other uses, it is necessary to register this token, when used within a 'tel:' URI, as specified in [1]. Thus this requests that this document be considered a specification for the 'tel:' parameter with the identifier 'svc', and that a registration be made for this use. 6. Acknowledgements Arnoud van Wijk pointed out sms as being important for non-hearing people, and that an indication of 'sms only' is very useful. Participants on the ENUM mailing list provided further clarification of the issues. Brandner, Conroy, Stastny Expires December, 2002 [Page 7] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 7. References [1] A. Vaha-Sipila, H. Schulzrinne, "URIs for Telephone Calls", draft-annti-rfc2806bis-04.txt, Work In Progress, May 2002 [2] Schulzrinne, H, Rosenberg, J, "Session Initiation Protocol", RFC3261, June 2002 [3] P. Faltstrom, "The E.164 to URI DDDS Application", draft-ietf-enum-rfc2916bis-00.txt, Work In Progress, March 2002 [4] J. Yu, "Extensions to the "tel" and "fax" URLs to Support Number Portability and Freephone Service", draft-ietf-enum-rfc2916bis-00.txt, Work In Progress, March 2002 [5] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF", RFC 2234, Internet Engineering Task Force, Nov. 1997. 8. Authors' Addresses Rudolf Brandner Siemens ICN Hofmannstrasse 51 Munich Germany Email: Phone: URI: Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey U.K. Email: Phone: Brandner, Conroy, Stastny Expires December, 2002 [Page 8] Internet-Draft The 'tel:' URI 'svc' Parameter June 2002 Richard Stastny OeFEG Postbox 147 1103 Vienna Austria Email: Phone: 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 9]