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: <mailto:rudolf.brandner@icn.siemens.de>
Phone: <tel:+49-89-72251003>
URI: <http://www.siemens.com>
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
U.K.
Email: <mailto:lwc@roke.co.uk>
Phone: <tel:+44-1794-833666>
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: <mailto:richard.stastny@oefeg.at>
Phone: <tel:+43-664-420-4100>
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]