Network Working Group K. Drage
Internet-Draft Alcatel-Lucent
Intended status: Informational January 28, 2010
Expires: August 1, 2010
A SIP/SIPS URI parameter for passing subscription data
draft-drage-dispatch-sub-data-01
Drage Expires August 1, 2010 [Page 1]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
Abstract
This document provides a SIP/SIPS URI parameter to enable
subscription data related to a SIP/SIPS URI to accompany that SIP/
SIPS URI when required by other entities in the same system. This
can then be used by the receiving entity to assist in the provision
of capabilities associated with that SIP/SIPS URI, either in this
request or in other subsequent requests.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on August 1, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Drage Expires August 1, 2010 [Page 2]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
1. Introduction
In a system of proxies or other SIP entities that form a network,
there is often a need to deliver subscription data related to a
particular subscriber or user (as represented by a SIP URI or SIPS
URI, to other entities within the system. This document provides a
SIP/SIPS URI parameter that can contain such information.
This information is primarily intended to be transferred from one
entity to another either by attachment to SIP URIs or SIPS URIs
within the P-Associated-URI header field (as defined in RFC 3455
[RFC3455], or to SIP URIs or SIPS URIs within the reg event package
(as defined in RFC 3680 [RFC3680] and RFC 5628 [RFC5628]). However
usage is not precluded on SIP URIs or SIPS URIs in other SIP requests
or responses.
The content of this information is intended to be specific to a
system or network as defined by a single standards organisation or
operator, so the contents of this parameter are not defined further
in this document. However a possible example of such information is
given in the following paragraph.
For the use of the Resource-Priority header field defined in RFC 4412
[RFC4412], other proxies in the system need to learn what namespaces
and priority levels within that namespace are legitimate for that
user. Suppose a user is entitled to use the GETS namespace, and is
allowed to use priority levels 2 and 3 within that namespace, then a
representation of the subscription data is needed that conveys:
1. multiple subscription data entries to represent both possible
combinations above, separated by a separator, e.g. "-".
2. that it is the capability represented by the Resource-Priority
header field that is being represented, e.g. "rph".
3. that the GETS namespace is allowed to be used, e.g. "gets".
4. that a priority level is allowed to be used, e.g. "2" or "3".
All characters used will need to be legal characters within a SIP/
SIPS URI parameter.
In this example it would be assumed that the absence of such
information conveys no right to use the capability.
Using the above elements, a representation of this data could be:
P-Associated-URI: <sip:example.com;subdata=rphgets2-rhpgets3>
Drage Expires August 1, 2010 [Page 3]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
2. Applicability Statement
The information is only intended for use within a system, and
therefore it is desirable that it is only be attached to URIs that
are for consumption within the system, or information should only be
included that contains information that is already known by the
recipient outside the system.
This implies that there is a danger in attaching the information to
URIs in ordinary requests and responses exchanged between users, as
the normal proxy behaviour is to pass this information through the
system to the end user, no matter who that end user is. If such
usage is envisaged, then some sort of trust domain must be defined
which encompasses the system where it is intended to be used, and
where this SIP/SIPS URI parameter is removed when the trust domain is
exited.
Drage Expires August 1, 2010 [Page 4]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
Drage Expires August 1, 2010 [Page 5]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
4. Definition of configuration data SIP/SIPS URI parameter
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC5234 [RFC5234]..
The "subdata" URI parameter is a "uri-parameter", as defined by RFC
3261 [RFC3261].
uri-parameter =/ sub-data-param
sub-data-param = "subdata=" sub-data-value
sub-data-value = token
The token string is as defined in RFC 3261 [RFC3261]. The contents
of this string is not defined in this document, and is defined by the
specification of the system to which the data relates.
It is up to the system designer to specify appropriate forward and
backward compatibility rules for the content of this string. A rule
such as ignoring parts of the string between separators that are not
recognised may be sufficient.
Drage Expires August 1, 2010 [Page 6]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
5. Procedures at the including entity
When a SIP user agent or proxy is passing on on SIP URI, or sending a
SIP URI for purposes of its own, and wishes to also pass on user
subscription information, the SIP user agent or proxy MAY include a
"subdata" SIP URI parameter with the SIP URI, provided:
1. the included subscription information relates to the SIP URI; and
2. it is known that the privacy policy for the information can be
met, see the security considerations.
Drage Expires August 1, 2010 [Page 7]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
6. Procedures at subsequent entities
When a SIP user agent or proxy receives a SIP URI, the SIP user agent
or proxy:
1. MUST remove the "subdata" SIP URI parameter if it knows the
privacy requirements cannot be met by subsequent entities, if
any; and
2. MAY retain the information within the "subdata" SIP URI
parameter, and the relationship to the SIP URI, if it has a
purpose for such data.
Drage Expires August 1, 2010 [Page 8]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
7. Security considerations
No specific security considerations apply. However a policy on the
privacy of the information is expected to be defined for systems that
use this information, and that privacy policy should then be adhered
to in its usage.
The information is only intended for use within a system, and
therefore it is desirable that it is only be attached to URIs that
are for consumption within the system, or information should only be
included that contains information that is already known by the
recipient outside the system.
For example, if use is restricted to the reg event package defined in
RFC 3680 [RFC3680], then the information should only be included in
event package information where the subscriber is known (by existing
SIP authentication mechanisms) to be another entity within the
system. It could also potentially be revealed to the owner of the
SIP or SIPS URI where it is envisaged that the subscription data is
already known by such a user.
This implies that there is a danger in attaching the information to
URIs in ordinary requests and responses exchanged between users, as
the normal proxy behaviour is to pass this information through the
system to the end user, no matter who that end user is. If such
usage is envisaged, then some sort of trust domain must be defined
which encompasses the system where it is intended to be used, and
where this SIP/SIPS URI parameter is removed when the trust domain is
exited.
Drage Expires August 1, 2010 [Page 9]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
8. IANA considerations
8.1. Registration of SIP/SIPS URI Parameter
This document specifies one new SIP/SIPS URI paramter: subdata. The
syntax is given in Section 3. These headers are defined by the
following information, which is to be added to the SIP/SIPS URI
parameter sub-registry under
http://www.iana.org/assignments/sip-parameters.
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
subdata No [RFCxxxx]
Note to the RFC editor: substitute xxxx with the RFC number of this
document.
Drage Expires August 1, 2010 [Page 10]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
9. APPENDIX: Changes history
Note to RFC Editor: Please remove this entire appendix before
publication
Drage Expires August 1, 2010 [Page 11]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)", RFC 3455, January 2003.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[RFC5628] Kyzivat, P., "Registration Event Package Extension for
Session Initiation Protocol (SIP) Globally Routable User
Agent URIs (GRUUs)", RFC 5628, October 2009.
Drage Expires August 1, 2010 [Page 12]
Internet-Draft Subscription Data SIP/SIPS URI parameter January 2010
Author's Address
Keith Drage
Alcatel-Lucent
Quadrant, Stonehill Green, Westlea
Swindon, Wilts
UK
Email: drage@alcatel-lucent.com
Drage Expires August 1, 2010 [Page 13]