One document matched: draft-garcia-sip-associated-uri-04.txt
Differences from draft-garcia-sip-associated-uri-03.txt
Network Working Group M. Garcia
Internet Draft Ericsson
Expires: December 2002 June 2002
Private Session Initiation Protocol (SIP) extension for
Associated Uniform Resource Identifiers (URI)
<draft-garcia-sip-associated-uri-04.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments should
be directed to the authors.
Abstract
This memo describes a private extension to SIP [1] that allows a
registrar to return a set of associated URIs to a registered address-
of-record. We define the P-Associated-URI header field, used in the
200 OK response to a REGISTER request. The P-Associated-URI header
field transports the set of Associated URIs to the registered address-
of-record.
Table of contents
1. Introduction......................................................2
2. Protocol operation................................................2
3. Applicability statement...........................................3
Network Working Group Expiration 12/05/02 [Page 1]
Garcia The SIP Associated URI header June 2002
4. The Associated URI header.........................................3
5. Syntax and definition.............................................3
6. Usage.............................................................4
6.1 Procedures at the UA.............................................4
6.2 Procedures at the registrar......................................4
6.3 Procedures at the proxy..........................................5
7. Security Considerations...........................................5
8. IANA Considerations...............................................5
9. Author's Addresses................................................6
10. Acknowledgements.................................................6
11. References.......................................................6
11.1 Normative references............................................6
11.2 Informative references..........................................6
1. Introduction
We consider that a user has a business relationship with a service
provider. The service provider assigns one or more SIP or SIPS URIs to
the user, so he can use any of this URIs to get services in the
network. When the user is allocated with one or more URIs, he can
distribute them according to their needs. For instance, the user may
want to allocate a SIP URI for his private usage, whereas another URI
is used for business purposes. From the point of view of the service
provider, all these URIs are allocated to the same user.
In certain situations, the user may roam from one terminal to another.
In order to facilitate this roaming, it seems to be convenient that
the network provides the user, once he has been authenticated, with
the list of URIs allocated to him.
We define a new P-Associated-URI header field, used in the 200 OK
response to a REGISTER request. This header field conveys a list of
URIs that the service provider has allocated to the user.
2. Protocol operation
A user typically is assigned with one or more URIs. The service
provider is aware of the set of URIs that a particular user is able to
use. Once the user is authenticated, the service provider may want to
inform the user of the set of URIs allocated to him.
In this specification we introduce the concept of associated URI to an
address-of-record URI. An associated URI is a URI that the service
provider has allocated to a user for his own usage. A registrar
contains information that allows an address-of-record URI to be
associated with zero or more URIs. Usually, all these URIs (the
address-of-record URI and the associated URIs) are allocated for the
usage of a particular user. The extension to SIP we define in this
document allows the UAC to know, upon a successful authenticated
registration, which other URIs, if any, the service provider has
associated to an address-of-record URI.
Network Working Group Expiration 12/05/02 [Page 2]
Garcia The SIP Associated URI header June 2002
Note that, generally speaking, the registrar does not register the
associated URIs on behalf of the user. Only the address-of-record in
the Request-URI of the REGISTER is registered and bound to the contact
address. The only information conveyed is that the registrar is aware
of other URIs to be used by the same user.
It may be possible, however, that an application server (even the
registrar itself) registers any of the associated URIs on behalf of
the user by means of a third party registration. However, this third
party registration is out of the scope of this document. A UAC MUST
NOT consider the associated URIs to be registered.
If a UAC wants to check whether any of the associated URIs is
registered, it can do so by mechanisms specified outside this
document, e.g., the UA may send a REGISTER request with the To header
field value set to any of the associated URIs. If the associated URI
is not registered, the UA MAY register it prior to its utilization.
3. Applicability statement
This specification is applicable in SIP networks where the SIP
provider is allocating the set of identities that a user can claim (in
headers like the From field) in requests that it generates. It
furthermore assumes that the provider knows the entire set of
identities that a user can legitimately claim, and that the user is
willing to restrict its claimed identities to that set. In normal SIP
usage, the From field is explicitly an end-user specified field.
4. The Associated URI header
The registrar inserts the P-Associated-URI header field into the 200
OK response to a REGISTER request. The header field value is populated
with a list containing zero or more URIs that are associated to the
address-of-record.
If the registrar supports the P-Associated-URI header field, and there
are URIs to populate in it, the registrar always inserts the P-
Associated-URI header field in a 200 OK response to a REGISTER
request, regardless of whether the REGISTER was an initial
registration, re-registration, or de-registration and regardless of
whether there are zero or more associated URIs.
5. Syntax and definition
The P-Associated-URI is a SIP extension header. The syntax of the P-
Associated-URI header field is based on the ABNF of SIP [1] and its
syntax is described as follows:
P-Associated-URI = "P-Associated-URI" HCOLON (addr-spec
*(COMMA addr-spec))
Network Working Group Expiration 12/05/02 [Page 3]
Garcia The SIP Associated URI header June 2002
A registrar supporting this extension MUST insert a P-Associated-URI
header field into a 200 OK response for a REGISTER request. If the
address-of-record in the REGISTER does not have any associated URIs,
the registrar still inserts the header field, although without any
value in it.
Table 1 below is an addition of the P-Associated-URI to the Table 2 in
SIP [1], section 4.1 of the SIP-specific event notification [4],
tables 1 and 2 in the SIP INFO method [5], tables 1 and 2 in
Reliability of provisional responses in SIP [6], tables 1 and 2 in the
SIP UPDATE method [7], tables 1 and 2 in the SIP extension for Instant
Messaging [7] and table 1 in the SIP REFER method [8]:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Associated-URI 2xx - - - - - o
Header field SUB NOT PRA INF UPD MES REF
_______________________________________________________________
P-Associated-URI - - - - - - -
Table 1: Header field support
6. Usage
6.1 Procedures at the UA
A UAC may receive a P-Associated-URI header field in the 200 OK
response for a REGISTER. The presence of the header field in the 200
OK response for a REGISTER request implies that the extension is
supported at the registrar.
The header value contains a list of zero or more associated URIs to
the address-of-record URI. The UAC MAY use any of the associated URIs
to populate the From header value, or any other SIP header value that
provides information of the identity of the calling party, in a
subsequent request.
The UAC MAY check whether the associated URI is registered or not.
This check can be done, e.g., by populating the To header value in a
REGISTER sent to the registrar. As described in SIP [1], the 200 OK
response may contain a Contact header field with zero or more values
(zero meaning the address-of-record is not registered).
6.2 Procedures at the registrar
A registrar that receives and authorizes a REGISTER request, may
associate zero or more URIs with the address-of-record.
Network Working Group Expiration 12/05/02 [Page 4]
Garcia The SIP Associated URI header June 2002
A registrar that supports this specification MUST include a P-
Associated-URI header field in the 200 OK response to a REGISTER
request.
In case the address-of-record under registration does not have any
other SIP or SIPS URIs associated, the registrar MUST include an empty
P-Associated-URI header value.
In case the address-of-record under registration has one or more SIP
or SIPS URIs associated, the registrar MUST include a comma separated
list of URIs in the P-Associated-URI header value.
6.3 Procedures at the proxy
This memo does not define any procedures at the proxy.
7. Security Considerations
The information returned in the header value is not viewed as
particularly sensitive. Rather, it is simply informational in nature,
providing openness to the UAC with regard to the automatic association
performed by the registrar. If end-to-end protection is not used at
the SIP layer, it is possible for proxies between the registrar and
the UA to modify the contents of the header value. This attack, while
potentially annoying, should not have significant impacts.
The lack of encryption, either end-to-end or hop-by-hop, may lead to
leak some privacy regarding the list of authorized identities. For
instance, a user who registers an address-of-record of
sip:user1@example.com may get another SIP URI associated as
sip:first.last@example.com returned in the P-Associated-URI header
value. An eavesdropper could collect this information. If the user
does not want to disclose the associated URIs, the eavesdropper could
have gain access to private URIs. Therefore it is RECOMMENDED that
this extension is used in a secured environment, where encryption of
SIP messages is provided either end-to-end or hop-by-hop.
8. IANA Considerations
This document defines the SIP extension header field "P-Associated-
URI" which should be included in the registry of SIP header fields
defined in SIP [1]. As required by the SIP change process [3] the SIP
extension header field name "Associated-URI" should also be registered
in association with this extension.
However, "Associated-URI" MUST not be used until documented by a
standards-track RFC. Expert review as required for this process is
to be provided by the SIP Working Group.
The following is the registration for the P-Associated-URI header
field:
Network Working Group Expiration 12/05/02 [Page 5]
Garcia The SIP Associated URI header June 2002
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Field Name: P-Associated-URI
Compact Form: none
The following is the registration for the Associated-URI header field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.] (not yet specified, only reserved)
Header Field Name: Associated-URI
Compact Form: none
9. Author's Addresses
Miguel A. Garcia
Ericsson
FIN-02420, Jorvas, Finland
Tel: +358 9299 3553
e-mail: miguel.a.garcia@ericsson.com
10. Acknowledgements
The author would like to thank Andrew Allen, Gabor Bajko, Gonzalo
Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Jonathan
Rosenberg and the 3GPP CN1 WG members for the comments on this
document.
11. References
11.1 Normative references
1. J. Rosenberg, H. S., etc, Session Initiation Protocol, RFC 3261
March 2002.
11.2 Informative references
2. M. Garcia et al, 3GPP requirements on SIP, draft-sipping-garcia-
3gpp-reqs-03.txt, work in progress.
3. S. Bradner, R. Mahy, A. Mankin, J. Ott, B. Rosen, D. Willis, SIP
change process, draft-tsvarea-sipchange-01.txt, February 2002,
work in progress.
4. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002.
5. S. Donovan, The SIP INFO method, RFC 2976, October 2000.
6. J. Rosenberg, H. Schulzrinne, Reliability of Provisional
Responses in SIP, RFC 3262, March 2002.
7. J. Rosenberg, The Session Initiation Protocol UPDATE Method,
draft-ietf-sip-update-02.txt, April 2002, work in progress.
Network Working Group Expiration 12/05/02 [Page 6]
Garcia The SIP Associated URI header June 2002
8. B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle,
Session Initiation Protocol Extension for Instant Messaging,
draft-ietf-sip-message-04.txt, May 2002, work in progress.
9. R. Sparks, The SIP Refer method, draft-ietf-sip-refer-05.txt,
June 2002, work in progress.
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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."
Expiration Date
This memo is filed as <draft-garcia-sip-associated-uri-04.txt>, and
expires December 5, 2002.
Network Working Group Expiration 12/05/02 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 06:10:29 |