Internet DRAFT - draft-zhou-simple-hierarchical-presence
draft-zhou-simple-hierarchical-presence
SIMPLE Hong. Zhou
Internet Draft Huawei Technologies
Expires: December 2006 June 9, 2006
Hierarchical presence event notification
draft-zhou-simple-hierarchical-presence-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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 December 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document describe a new method for the Presence Server to
process presence in inter-domain scenarios. The currently-defined
method according to RFC 3261 [1] and RFC 3265 [2] results in
duplicated messaging. This document provides a new method to avoid
this duplication.
Hong Expires December 9, 2006 [Page 1]
Internet-Draft Hierarchical presence June 2006
Conventions used in this document
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 RFC-2119 [5].
Table of Contents
1. Introduction............................................ 2
2. Process Presence in Inter-domain........................ 2
2.1. Currently-defined Method........................... 2
2.2. Hierarchical Method................................ 6
2.3. Compatible with RFC 3857........................... 8
3. Presence Server Behavior............................... 11
4. UA Considerations ..................................... 12
5. Security Considerations................................ 12
6. Acknowledgments........................................ 12
7. References............................................. 13
7.1. Normative References.............................. 13
7.2. Informative References............................ 13
Author's Addresses........................................ 13
Intellectual Property Statement .......................... 13
Disclaimer of Validity.................................... 14
Copyright Statement....................................... 14
Acknowledgment ........................................... 14
1. Introduction
RFC 3856 [3] describes the usage of SIP for subscriptions and
notifications of presence, but the method described in RFC 3261 [1]
and RFC3265 [2] (called "currently-defined method" in this document)
results in duplicated messaging for each listener between domains.
This document provides a additional way to process presence without
duplicated messaging. The new method is compatible with the
currently-defined Method and is called Hierarchical Method.
2. Processing Presence Information in Inter-domain
This section describes the duplicated messaging in the currently-
defined method and the hierarchical method being proposed.
2.1. Currently-defined Method
Consider this scenario: there are two domains(Domain A and Domain
B)in the SIP network, Server A is a presence server in Domain A and
Server B is a presence server in Domain B, both the user Watcher1 and
Hong Expires December 9, 2006 [Page 2]
Internet-Draft Hierarchical presence June 2006
Watcher2 in Domain A want to subscribe the Presence User Agent's
(PUA's) presence information and the PUA in Domain B. The main steps
are shown in Figure 1.:
o Watcher1 sends SUBSCRIBE to Server A and Server A forwards the
message to Server B.
o Server B accepts the request and responds 200, then sends NOTIFY
to Server A. Server A only forwards 200 for SUBSCRIBE and NOTIFY
to Watcher1.
o Watcher2 sends SUBSCRIBE to Server A and Server A forwards the
message to Server B.
o Server B accepts the request and responds 200, then sends NOTIFY
to Server A. Server A only forwards 200 for SUBSCRIBE and NOTIFY
to Watcher2.
o PUA tells Server B its new state if its state is changed.
o Server B sends NOTIFY to tell Watcher1 the new state.
o Server B sends NOTIFY to tell Watcher2 the new state.
Hong Expires December 9, 2006 [Page 3]
Internet-Draft Hierarchical presence June 2006
+---------Domain A -----------+ +----Domain B---+
| | | |
v v v v
Watcher1 Watcher2 Server A Server B PUA
| F1 SUBSCRIBE | | | |
|--------------|------------->| F2 SUBSCRIBE | |
| | |------------->| |
| | | F3 200 OK | |
| | |<-------------| |
| F4 200 OK | | | |
|<-------------|--------------| | |
| | | F5 NOTIFY | |
| | |<-------------| |
| F6 NOTIFY | | | |
|<-------------|--------------| | |
| F7 200 OK | | | |
|--------------|------------->| | |
| | | F8 200 OK | |
| | |------------->| |
| | F9 SUBSCRIBE | | |
| |------------->| | |
| | | F10 SUBSCRIBE| |
| | |------------->| |
| | | F11 200 OK | |
| | |<-------------| |
| | F12 200 OK | | |
| |<-------------| | |
| | | F13 NOTIFY | |
| | |<-------------| |
| | F14 NOTIFY | | |
| |<-------------| | |
| | F15 200 OK | | |
| |------------->| | |
| | | F16 200 OK | |
| | |------------->| |
| | | |Update presence|
| | | |<--------------|
| | | F17 NOTIFY | |
| | |<-------------| |
| F18 NOTIFY | | | |
|<-------------|--------------| | |
| F19 200 OK | | | |
|--------------|------------->| | |
| | | F20 200 OK | |
| | |------------->| |
| | | F21 NOTIFY | |
| | |<-------------| |
Hong Expires December 9, 2006 [Page 4]
Internet-Draft Hierarchical presence June 2006
| | F22 NOTIFY | | |
| |<-------------| | |
| | | | |
Watcher1 Watcher2 Server A Server B PUA
| | | | |
| | F23 200 OK | | |
| |------------->| | |
| | | F24 200 OK | |
| | |------------->| |
| | | | |
| | | | |
Figure 1
As we can see, the messages F17 and F21 carry the same information
about PUA'S presence. So if many users in Domain A subscribe the
PUA's presence information, and if the PUA's presence information is
changed, there will be many NOTIFYs (along with their responses)
carrying duplicated information between Server A and Server B.
Hong Expires December 9, 2006 [Page 5]
Internet-Draft Hierarchical presence June 2006
2.2. Hierarchical Method
The hierarchical method's basic concept is that Presence Servers
subscribe to presence information from other domain's Presence
Server.
An example is shown in Figure 2. The relationships among Watcher1,
Watcher2, PUA, Server A and Server B are the same as Section 2.1. The
main steps are:
o Watcher1 sends SUBSCRIBE to Server A, Server A responds 202.
o Server A itself sends SUBSCRIBE to Server B to subscribe the
PUA's presence state.
o Server B accepts the Server A's request and responds 200, then
sends NOTIFY to tell Server A the PUA's presence state.
o Server A gets the PUA's presence state and stores it, then sends
NOTIFY to Watcher1.
o Watcher2 sends SUBSCRIBE to Server A, Server A responds 202.
o Server A sends NOTIFY to Watcher2 as it knows the PUA's presence
state.
o PUA tells Server B its new state when its state is changed.
o Server B sends NOTIFY to tell Server A the new state.
o Server A sends NOTIFY to tell Watcher1 and Watcher2 the new
state.
Hong Expires December 9, 2006 [Page 6]
Internet-Draft Hierarchical presence June 2006
+---------Domain A -----------+ +----Domain B---+
| | | |
v v v v
Watcher1 Watcher2 Server A Server B PUA
| F1 SUBSCRIBE | | | |
|--------------|------------->| | |
| F2 202 Accepted | | |
|<-------------|--------------| | |
| | | F3 SUBSCRIBE | |
| | |------------->| |
| | | F4 200 OK | |
| | |<-------------| |
| | | F5 NOTIFY | |
| | |<-------------| |
| | | F6 200 OK | |
| F7 NOTIFY | |------------->| |
|<-------------|--------------| | |
| F8 200 OK | | | |
|--------------|------------->| | |
| | F9 SUBSCRIBE | | |
| |------------->| | |
| | F10 202 Accepted | |
| |<-------------| | |
| | F11 NOTIFY | | |
| |<-------------| | |
| | F12 200 OK | | |
| |------------->| | |
| | | |Update presence|
| | | |<--------------|
| | | F13 NOTIFY | |
| | |<-------------| |
| | | F14 200 OK | |
| | |------------->| |
| F15 NOTIFY | | | |
|<-------------|--------------| | |
| F16 200 OK | | | |
|--------------|------------->| | |
| | F17 NOTIFY | | |
| |<-------------| | |
| | F18 200 OK | | |
| |------------->| | |
| | | | |
Figure 2
Note: Authentication and authorization did not show in this figure.
That will be discussed in Section 2.3.
Hong Expires December 9, 2006 [Page 7]
Internet-Draft Hierarchical presence June 2006
The flow chart shows that the NOTIFY messages between Server A and
Server B are reduced. Assuming N users in Domain A subscribed the
PUA's presence information, and using Currently-defined Method, the
number of NOTIFY message sent from Server B to Server A is N. Using
Hierarchical Method, the number is 1. Additional, the user in Domain
A will quickly get the PUA's presence state if the Server A has
gotten this state.
2.3. Compatibility with RFC 3857
RFC 3856 says "In inter-domain scenarios, establishing an
authenticated identity of the subscriber is harder. It is
anticipated that authentication will often be established through
transitive trust". This document also uses this assumption.
Authorization is complex. This document provide one approach,
compatible with RFC 3857. Of course, this document does not exclude
other authorization mechanisms. Figure 2 shows a example, based on
Section 2.2.
Hong Expires December 9, 2006 [Page 8]
Internet-Draft Hierarchical presence June 2006
+---------Domain A -----------+ +----Domain B---+
| | | |
v v v v
Watcher1 Watcher2 Server A Server B PUA
| | | | |
| | | |notify presence|
| | | |<--------------|
| | | | F1 SUBSCRIBE |
| | | (event=presence.winfo)
| | | |<--------------|
| | | | F2 200 OK |
| | | |-------------->|
| | | | F3 NOTIFY |
| | | (event=presence.winfo)
| | | |-------------->|
| | | | F4 200 OK |
| | | |<--------------|
| | | | |
| F5 SUBSCRIBE(event=presence)| | |
|--------------|------------->| | |
| F6 407 Proxy Authentication Required | |
|<-------------|--------------| | |
| F7 SUBSCRIBE(event=presence)| | |
|--------------|------------->| | |
| F8 202 Accepted | | |
|<-------------|--------------| | |
| | | F9 SUBSCRIBE(event=presence) |
| | |------------->| |
| | | F10 200 OK | |
| | |<-------------| |
| | | F11 NOTIFY(event=presence) |
| | |<-------------| |
| | | F12 200 OK | |
| | |------------->| |
| | | | |
| | |F13 SUBSCRIBE(event=presence.winfo)
| | |<-------------| |
| | | F14 200 OK | |
| | |------------->| |
| | | F15 NOTIFY(event=presence.winfo)
| | |------------->| |
| | | F16 200 OK | |
| | |<-------------| |
| | | | F17 NOTIFY |
| | | (event=presence.winfo)
| | | |-------------->|
| | | | F18 200 OK |
Hong Expires December 9, 2006 [Page 9]
Internet-Draft Hierarchical presence June 2006
| | | |<--------------|
| | | make decision |
| | | | |
| F19 NOTIFY(event=presence) | | |
|<-------------|--------------| | |
| F20 200 OK | | | |
|--------------|------------->| | |
| | | | |
| | F21 SUBSCRIBE(event=presence) |
| |------------->| | |
| | F22 407 Proxy Authentication Required |
| |<-------------| | |
| | F23 SUBSCRIBE(event=presence) |
| |------------->| | |
| | F24 202 Accepted | |
| |<-------------| | |
| | | F25 NOTIFY(event=presence.winfo)
| | |------------->| |
| | | F26 200 OK | |
| | |<-------------| |
| | | | F27 NOTIFY |
| | | (event=presence.winfo)
| | | |-------------->|
| | | | F28 200 OK |
| | | |<--------------|
| | | make decision |
| | | | |
| | F29 NOTIFY(event=presence) | |
| |<-------------| | |
| | F30 200 OK | | |
| |------------->| | |
| | | |Update presence|
| | | |<--------------|
| | | | |
| | | F31 NOTIFY(event=presence) |
| | |<-------------| |
| | | F32 200 OK | |
| | |------------->| |
| F33 NOTIFY(event=presence) | | |
|<-------------|--------------| | |
| F34 200 OK | | | |
|--------------|------------->| | |
| | F35 NOTIFY(event=presence) | |
| |<-------------| | |
| | F36 200 OK | | |
| |------------->| | |
| | | | |
Hong Expires December 9, 2006 [Page 10]
Internet-Draft Hierarchical presence June 2006
Figure 3
3. Presence Server Behavior
First of all, the Presence Server MUST know whether the other
Domain's Presence Server supports Hierarchical Method. The simplest
approach is manual configuration. This document neither supports nor
excludes other approaches.
If a Presence Server receives a SUBSCRIBE request, the Presence
Server SHOULD process the message as follows:
o Presence Server got the subscribed user from the SUBSCRIBE
message.
o If the subscribed user belongs to its domain, then Presence
Server process the SUBSCRIBE message using the currently-defined
Method.
o If the subscribed user does not belong to its domain, but the
Presence Server can't use Hierarchical Method then it uses the
currently-defined Method.
o Otherwise, Presence Server use Hierarchical Method:
- Presence Server responds 202 for the SUBSCRIBE, and
simultaneously creates (if no dialog already exists) or
maintains (if dialog has already been created) dialog according
to RFC3265 [2].
- If Presence Server has the subscribed user's presence
information, then Presence Server sends NOTIFY message to
subscriber.
- Otherwise, Presence Server creates new SUBCRIBE according to
the Watcher's SUBSCRIBE and sends it to the other domain's
Presence Server.
- Presence Server distributes the NOTIFY to the subscribers
according to dialogs it created when it receives NOTIFY message
from other domain's Presence Server.
Hong Expires December 9, 2006 [Page 11]
Internet-Draft Hierarchical presence June 2006
4. UA Considerations
UA needn't know the Presence Server using Currently-defined Method or
Hierarchical Method, So UA need no additional behavior to support
this document.
5. Security Considerations
Security considerations of this document are unchanged from RFC 3856
[3] and RFC 3857 [4].
6. Acknowledgments
We would like to thank Spencer Dawkins, Feng Li, Xinyu Hu, Kewei Zhang,
Xia Qin, Changsheng Wan, Jian Chen, Palin Yang, Yuping Zhao, Hao Wang,
Qikun Wei and Rong Zou for their comments and support of this
specification.
Hong Expires December 9, 2006 [Page 12]
Internet-Draft Hierarchical presence June 2006
7. References
7.1. Normative References
[1] 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.
[2] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, July 2004.
[4] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857, August
2004.
[5] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[6] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", Work in
Progress, May 2004.
Author's Addresses
Hong Zhou
NanJing Institute,Huawei Technologies Co.,Ltd.
Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
NanJing, P.R. of China
Phone: +86 25 8456 5478
Email: zhouhong@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
Hong Expires December 9, 2006 [Page 13]
Internet-Draft Hierarchical presence June 2006
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hong Expires December 9, 2006 [Page 14]
