idnits 2.17.1 draft-brandner-tel-svc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 59 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 178: '...he recipient of the URI and SHOULD NOT...' RFC 2119 keyword, line 193: '...meter value, but SHOULD NOT try to ini...' RFC 2119 keyword, line 207: '...client SHOULD NOT attempt to send an s...' RFC 2119 keyword, line 264: '...'tel:' URI SHOULD present this in some...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-annti-rfc2806bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-07) exists of draft-ietf-enum-rfc2916bis-00 == Outdated reference: A later version (-07) exists of draft-ietf-enum-rfc2916bis-00 -- Duplicate reference: draft-ietf-enum-rfc2916bis, mentioned in '4', was also mentioned in '3'. ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft R.Brandner 2 Catogory: Standards Track Siemens 3 L. Conroy 4 Siemens 5 R. Stastny 6 OeFEG 8 Expires: December, 2002 June, 2002 10 "The 'tel:' URI 'svc' Parameter" 11 draft-brandner-tel-svc-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 38 This document describes the 'svc' parameter for use within a 'tel:' URI. 39 This is intended to indicate the uses to which a resource identified 40 via the 'tel:' URI can be put. It is an optional parameter, and if not 41 understood can be ignored. It allows the user to "hint" at the features 42 supported at the resource. There are guidelines for how this parameter 43 might be used, and for expected behaviour on detection of this parameter. 45 1. Introduction 46 The 'tel:' URI [1] indicates a resource that can be addressed via a 47 telephone number. This is useful both for session protocols (for example, 48 with SIP [2]) and can also be used within the ENUM [3] domain space or 49 as an element within a Web page as a "static" value. 51 Within the GSTN, a telephone number may be associated with a device that 52 supports only a limited number of features (or services). For example, a 53 particular number may be associated with a Fax machine, whilst another is 54 associated with a voice telephone only. 56 Most mobile telephones can send and receive "Short Messages" and this 57 support is being extended to fixed lines in regions. It can be useful to 58 indicate support for this feature when defining the URI, as it is not 59 possible to predict from inspection whether or not a terminal associated 60 with this URI has support for this feature (or has an indirect service 61 giving this support). This indication may be particularly important for 62 individuals who use this text service in preference to voice. 64 Similarly, some voice lines have a TDD (textphone) connected, and allowing 65 a URI to indicate this may also be important to those people who want to 66 use this means of communication rather than voice (or other services). 68 1.1 Document Structure 69 This section has introduced the rationale for an aditional parameter to 70 indicate services available with a particular 'tel:' URI. The next section 71 decribes the proposed syntax and use of this parameter. Following on is a 72 section clarifying the optionality of this parameter, together with the 73 expected behaviour of a node in receiving such a parameterised URI. 74 Finally the security and privacy issues are discussed; note that the main 75 concerns here are privacy issues. 77 2. Teleservice feature indication 79 2.1 teleservices to be indicated 80 There are a number of different teleservice features that might be 81 associated with a resource contacted via a telephone number. The list 82 of features shown in this document is general and covers only those 83 services that do not include intrinsic negotiation as part of the 84 feature. 86 * voice - this resource supports voice communication 87 * video - this resource supports video communication 88 * fax - this resource supports reception of fax messages 89 * sms - this resource supports reception of short messages 90 * tdd - this resource supports TDD communication sessions 91 Note that, for example, the fax feature does not specify whether Group 2, 92 Group 3, or even Group 4 fax is usable at this resource. This is because, 93 in general, fax communication includes a negotiation phase by which the 94 class of fax protocol is negotiated. 96 In addition, the video feature does not specify any particular video 97 system to use. It could be any system that is able to transmit video 98 and audio. 100 There are some variants on the above that may also be present. If 101 these are used, then they can be considered in most circumstances as 102 extensions of the above services. 104 * ivoice - this resource supports voice communication 105 AND is associated with an IP-connected end point 106 * mms - this resource accepts reception of short messages 107 AND multimedia messages 109 The 'ivoice' term might be used, for example, if the holder of the URI is 110 able to choose whether to use a direct GSTN connection or instead to use 111 an IP-network connection. It might also be used in particular within a 112 Telephony Service Provider's network to select the appropriate Point of 113 Interconnection towards the destination. This can be important if that 114 Service Provider uses IP-trunking or other network-internal schemes that 115 have already introduced a transcoding step in the communications path. 116 How a forward path can be found is out of scope of this document and is 117 discussed further in [4]. 118 For those holders of the URI not capable of selecting an optimised forward 119 path for their communication, the 'ivoice' service can be considered 120 identical to the 'voice' service. 122 The 'mms' term is used to indicate that the resource is capable of 123 receiving not only "standard" SMS messages but also the enhanced messages 124 that are in the process of standardisation at present. All terminals 125 capable of receiving these MMS messages are also capable of receving SMS 126 messages, and so this is a pure superset of the 'sms' tag. 128 2.2 Syntax for 'svc' parameter 129 The following is the ABNF for this parameter. It is intended as a 130 parameter label followed by comma-separated list of value terms. 131 The value terms indicate a set of potential teleservice features. 133 The 'svc' parameter is defined using the ABNF (augmented Backus-Naur 134 form) described in RFC 2234 [5]. Note that this parameter fits within 135 the 'other' parameter syntax as described in [1]. 137 The syntax for the 'tel:' URI 'svc' parameter is: 139 svc-param = svc-label "=" svc-values 140 svc-label = "svc" 141 svc-values = 1*(teleservice-term) [*("," teleservice-term)] 142 teleservice-term = ( "fax" / "ivoice" / "mms" / "sms" / "tdd" / 143 "video" / "voice" ) 145 3. Expected Behaviour 146 In many ways, the 'tel:' URI scheme is unusual in that it is not tied to 147 a particular Internet Protocol or set of protocols. Thus acting on receipt 148 of a 'tel:' URI does not result in triggering a defined Internet protocol 149 exchange. 151 Normally one would expect a terminal either to run a dialer program that 152 controls an external device connected to the GSTN (such as a telephone 153 or fax modem) or, if it did not have access to such a device, to use 154 this URI as a parameter to a session control program (such as a SIP User 155 Agent). 157 The control of an external GSTN-connected device can be either direct (as 158 with an external modem/phone connected to a serial or USB port) or can be 159 indirect, via one of the number of "Network Telephony Device Control" 160 protocols. These schemes are not (and should not) be specified here; it is 161 a subject of much standardisation in external fora, and of competition. 163 All that can be assumed is that the recipient of a 'tel:' URI is aware of 164 the local availability of a telephony device controller, or of a session 165 control program that can use such a URI. In either case, the URI may be 166 used to initiate a communication. However, the URI may still be used even 167 if the recipient has no desire to start a communication; for example, the 168 user may want to store this information in an address book or display it 169 on a web page. The rest of this section covers the potential actions on 170 receipt of a 'tel:' URI with a 'svc' parameter. Given the wide use of the 171 URI scheme, this can only be advisory, and is NOT normative. 173 3.1 Optionality 174 As defined in the 'tel:' URI specification [1], there are two classes 175 or external parameters that may be used with a 'tel:' URI. These are 176 mandatory parameters in which the parameter label starts with "m-", and 177 optional parameters that must not start with this string. Mandatory 178 parameters must be understood by the recipient of the URI and SHOULD NOT 179 be ignored. Optional parameters however can be ignored safely and need 180 not be understood by the client. 182 In the case of the 'svc' parameter, the information carried is a list of 183 'hints' on the communications features associated with the resource. As 184 these are hints, it is not appropriate for this parameter to be mandatory. 186 The value of the 'svc' parameter is a comma separated list of supported 187 teleservice features. These are hints to the client, so that the client is 188 aware of the appropriate communications program that can be run. 190 Thus, although the parameter is optional, the hints should be considered 191 as a filter when initiating communications. If this parameter is present 192 in a URI, the client is not forced to initiate any one of the teleservices 193 listed in the parameter value, but SHOULD NOT try to initiate a service 194 that is not listed; the value is a filter to exclude possibilities. 196 3.2 Strategies for processing a 'tel:' URI with a 'svc' Parameter 198 The aim of this sub-section is to highlight what an end user might expect 199 to happen both having declared the information (i.e. to make available 200 such a parameterised URI) and having received such a URI. 202 As just mentioned, the svc parameter value is intended as a hint of the 203 communications features supported at the resource. This means that a URI 204 'svc' parameter that includes, for example, fax, is capable of receiving a 205 fax message. In this situation it is appropriate for the client to run fax 206 software. If the value does NOT contain, for example, 'sms', then the 207 client SHOULD NOT attempt to send an sms to the resource. 209 Note that it is recommended that a 'tel:' URI containing a 'svc' parameter 210 should not have that parameter stripped if the URI is passed onwards or 211 copied unless it has good cause to do this. However, there are a 212 number of issues that should be taken into account when using a 213 'tel:' URI. 215 3.2.1 Age Sensitivity of stored URIs 216 If, for example, a parameterised 'tel:' URI is to be stored in a local 217 "Address Book", then the "life expectancy" of that entry should be 218 considered. This is a general issue with address book storage of old 219 entries as people move and a number may be re-allocated to someone wholly 220 unconnected with the original contact. 222 It is also an issue for a URI with a 'svc' parameter. People do change the 223 services associated with a number over time, and so caution should be 224 taken when using (for example) a 'tel:' URI that indicates that the number 225 is associated with a fax service, if that URI was last collected some time 226 ago. If the potential target of a communication has swapped the line they 227 use for their phone and fax machine, the resultant conversation may not be 228 successful. Similarly, Telephony Service Operators may bring in new 229 service features (such as, for example, support for SMS messages on a 230 fixed line), so that over time the 'svc' list may be outdated or overly 231 restrictive. 233 In this situation, the 'tel:' URI in an address book may have exceeded its 234 "shelf life". In particular, the 'svc' parameter should be treated as 235 advisory and either a new verion of the URI should be captured or, at 236 least, the user should be informed explicitly of the success or otherwise 237 of a communication based on an "old" URI. As the 'tel:' URI is often used 238 with communications involving humans rather than machines, it is more of 239 an issue that simply having an outdated 'http:' URl, for example. Sending 240 a fax to a voice line can be irritating and could be considered offensive. 242 3.2.2 Privacy 243 A 'tel:' URI containing a 'svc' parameter may have been passed to a user. 244 This does not mean that the user has the right to pass on information on 245 the capabilities associated with the resource to a third party. Thus, when 246 using a 'tel:' URI in a session initiation, for example, it may be that 247 the 'tel:' URI DOES have the 'svc' parameter stripped, if the holder of 248 that URI is unsure whether or not the 'svc' information may be considered 249 sensitive by the individual associated with the resource. Similarly, this 250 stripping may be done by an intermediary on the same privacy grounds. 252 3.2.3 Extended Usage Issues 253 It may be tempting to add this indication to all tel: URIs, regardless of 254 how and where they are used. For example, it might seem useful to add a 255 service indication to a SIP URI to show the available registrations and so 256 the potential sessions that may be started. However, this is discouraged. 258 Protocols designed for session initiation, such as SIP, have their own 259 mechanisms for negotiation, and those should be used where available. 261 4. Security Issues 263 As a general issue with 'tel:' URIs, a client application that collects a 264 'tel:' URI SHOULD present this in some way to its user before acting on 265 it. The URI may result in a cost to the user, and that user has a right 266 to select whether or not they want to incur this cost. This also means 267 that they agree to the particular teleservice indicated by the 'svc' 268 parameter. For example, in some regions choice of one service rather 269 than another may well have cost implications. 271 There are no other 'pure' security implications above those for a 272 "standard" 273 'tel:' URI. The rest of these points focus on privacy issues. These should 274 not be underestimated. 276 If a 'tel:' URI is placed on a publicly accessible location such as a 277 Web page (or within the ENUM domain space), then by definition anyone 278 may collect the information. Thus the person who is associated with the 279 destination resource should be aware of this fact and agree to it being 280 published in context. 282 They may be comfortable making this information available at a server with 283 restricted access (such as a Company Intranet or a server providing 284 authenticated access only to a controlled group of people), but may not be 285 comfortable with exactly the same information being made available to a 286 global audience. Thus not only the agreement of the user should be sought 287 to publish, but it should be confirmed that they accept the scope of this 288 publication. 290 As a more specific case, the individual who is associated with the 291 resource will expose capability information by using the 'svc' parameter - 292 that is, after all, the purpose of this parameter. This may be a privacy 293 concern, particularly when a parameterised 'tel:' URI is stored in a 294 globally accessible system like ENUM. 296 Some capability information may be sensitive; for example, the person 297 associated with the resource may be uncomfortable exposing the fact that 298 a number is associated with a terminal from which some disability can be 299 implied, such as a 'tdd' device. 301 5. IANA Considerations 303 This document describes a parameter that can be used to carry 304 teleservice feature information qualifying a 'tel:' URI. 306 To ensure that this parameter tag value does not collide with other 307 uses, it is necessary to register this token, when used within a 308 'tel:' URI, as specified in [1]. 309 Thus this requests that this document be considered a specification 310 for the 'tel:' parameter with the identifier 'svc', and that a 311 registration be made for this use. 313 6. Acknowledgements 314 Arnoud van Wijk pointed out sms as being important for non-hearing 315 people, and that an indication of 'sms only' is very useful. 316 Participants on the ENUM mailing list provided further clarification 317 of the issues. 319 7. References 321 [1] A. Vaha-Sipila, H. Schulzrinne, "URIs for Telephone Calls", 322 draft-annti-rfc2806bis-04.txt, 323 Work In Progress, May 2002 325 [2] Schulzrinne, H, Rosenberg, J, 326 "Session Initiation Protocol", RFC3261, June 2002 328 [3] P. Faltstrom, "The E.164 to URI DDDS Application", 329 draft-ietf-enum-rfc2916bis-00.txt, 330 Work In Progress, March 2002 332 [4] J. Yu, "Extensions to the "tel" and "fax" URLs to Support 333 Number Portability and Freephone Service", 334 draft-ietf-enum-rfc2916bis-00.txt, 335 Work In Progress, March 2002 337 [5] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax 338 specifications: ABNF", RFC 2234, Internet Engineering Task Force, 339 Nov. 1997. 341 8. Authors' Addresses 343 Rudolf Brandner 344 Siemens ICN 345 Hofmannstrasse 51 346 Munich 347 Germany 349 Email: 350 Phone: 351 URI: 353 Lawrence Conroy 354 Siemens Roke Manor Research 355 Roke Manor 356 Romsey 357 U.K. 359 Email: 360 Phone: 361 Richard Stastny 362 OeFEG 363 Postbox 147 364 1103 Vienna 365 Austria 367 Email: 368 Phone: 370 Full Copyright Statement 372 Copyright (C) The Internet Society (2000). All Rights Reserved. 374 This document and translations of it may be copied and furnished to 375 others, and derivative works that comment on or otherwise explain it 376 or assist in its implementation may be prepared, copied, published 377 and distributed, in whole or in part, without restriction of any 378 kind, provided that the above copyright notice and this paragraph are 379 included on all such copies and derivative works. However, this 380 document itself may not be modified in any way, such as by removing 381 the copyright notice or references to the Internet Society or other 382 Internet organizations, except as needed for the purpose of 383 developing Internet standards in which case the procedures for 384 copyrights defined in the Internet Standards process must be 385 followed, or as required to translate it into languages other than 386 English. 388 The limited permissions granted above are perpetual and will not be 389 revoked by the Internet Society or its successors or assigns. 391 This document and the information contained herein is provided on an 392 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 393 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 394 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 395 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 396 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.