Network Working Group V. Singh
Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia U.
Expires: January 15, 2009 P. Boni
Verizon
July 14, 2008
Membership Event Package
draft-singh-simple-membership-01.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 January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines a new event membership package that allows to
track changes in membership in groups. Groups can represent entities
contained within a physical space, such as a room or vehicle, or a
logical group of entities, such as a call center team. Each member
of a group can support a different set of event packages.
Singh, et al. Expires January 15, 2009 [Page 1]
Internet-Draft Membership Event Package July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Membership Event Package Description . . . . . . . . . . . . . 3
3.1. Message Flow Diagram . . . . . . . . . . . . . . . . . . . 4
4. Membership Event Package . . . . . . . . . . . . . . . . . . . 5
4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6
4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
4.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Example of membership event package XML . . . . . . . . . 8
6.2. Message Flow Example . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Authorization Considerations . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Singh, et al. Expires January 15, 2009 [Page 2]
Internet-Draft Membership Event Package July 2008
1. Introduction
Currently, presence information describes individuals or devices.
However, there are cases where groups and their membership are of
interest. The event package described in this document allows the
watcher to be notified when group membership changes.
In presence-related applications, we encounter groups defined by
physical and logical properties. Groups defined by physical
properties include all presentities located in a vehicle, room or
building. Groups defined by logical properties include teams in call
centers or other groups of personnel where each member can reasonably
respond to a request for assistance. For example, the group
"sysadmin@example.com" may consist of all on-call system
administrators.
As a use case for a group defined by physical properties, consider
that a user may want to communicate with whoever is occupying a
meeting room at the moment. With the help of the membership event
package, the user would subscribe to the membership events for that
room and thus obtain presence information for whoever happens to be
in the room, presumably identified by some kind of tracking or user
location system. Membership in a group representing a vehicle may
include the vehicle itself, as well as the driver and passengers.
Membership in logical and physical groups can change over time. For
the examples, a meeting room is typically used by multiple different
sets of people during the day, while a repair truck may be used by
different repair crews. Below, we define a simple event package that
tracks such membership changes. In addition to group membership, the
package also tracks what events each member supports.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
3. Membership Event Package Description
This document defines a new event membership package that allows to
track changes in membership in groups. Groups can represent entities
contained within a physical space, such as a room or vehicle, or a
logical group of entities, such as a call center team. Each member
of a group can support a different set of event packages. The event
package defines an XML-based schema for describing the membership
Singh, et al. Expires January 15, 2009 [Page 3]
Internet-Draft Membership Event Package July 2008
information.
3.1. Message Flow Diagram
+------------+ +------------+ +-----------+ +-----------+
| ES2 | | ES1 | | MES | |Application|
|Event Server| |Event Server| |Membership | |/PS |
| (p2) | | (p1) | |EventServer| |/Watcher |
+------------+ +------------+ +-----------+ +-----------+
| | | |
| | | |
| | | SUBSCRIBE (1) |
| | |<-------------------|
| | | Event:membership |
| | | |
| | | NOTIFY (2) |
| | |------------------->|
| | | Event:membership |
| | | |
| | SUBSCRIBE (3) | |
| |<----------------+--------------------|
| | Event:p1 | |
| | | |
| | NOTIFY (4) | |
| |-----------------+------------------->|
| | Event:p1 | |
| | | |
| SUBSCRIBE (5) | | |
|<-------------------+-----------------+--------------------|
| Event:p2 | | |
| | | |
| NOTIFY (6) | | |
|--------------------+-----------------+------------------->|
| Event:p2 | | |
| | | |
Figure 1: Distributing membership information
In the message flow diagram above, the application subscribes in step
(1) to membership events of the the specific group (e.g., a vehicle)
on the membership event server (MES). The MES will send a NOTIFY
request (step (2)) with all the current members and the event
packages they are supporting. The application, such as a watcher or
a presence server, may then choose to obtain information on each or
Singh, et al. Expires January 15, 2009 [Page 4]
Internet-Draft Membership Event Package July 2008
some entities contained in the membership list. It will send one or
more SUBSCRIBE requests to appropriate event servers handling the
specific event package for the entity. In the diagram, the
application sends a SUBSCRIBE request (step (3)) with event package
p1 to ES1 and receives a corresponding NOTIFY request (step (4)).
Similarly, the application generates a subscription (step (5)) to ES2
for the p2 event package and receives back notification (step (6)).
The application may aggregate event information it has obtained in
many different ways. Subscriptions (3) and (5) may relate to
different entities or to the same entity using identical or different
event packages.
As an example, when user Alice gets into her GPS-equipped car, a
sensor in the car discovers her identity, for example by recognizing
the Bluetooth identifier of her cell phone or the code on her smart
key. The car electronics then updates the car's membership list, for
example by using SIP PUBLISH or XCAP. Alternatively, if Alice is
authorized to obtain and update car-related group membership
information, she can obtain the current membership list and publish
an updated version with her identity added. The membership change
results in the application receiving a NOTIFY request with Alice's
and the vehicle's entities in the membership list. The application
already subscribes to Alice's presentity, but now starts subscription
to two vehicle-related event packages, one for the telematics and
other information (vehicle-info event package [5]) and one for the
GPS location data (presence event package, PIDF-LO [6], [7], [2]).
The application aggregates incoming data across multiple event
packages to render Alice's extended presence information to
authorized users.
In some situations, an application may know the individual entity,
but may not know the names of the groups the entity currently belongs
to. However, that information can be published as part of the
presentity's presence information and then lead the application to
other members of her group, such as fellow passengers in a vehicle or
fellow team members. Rather than enhancing presence information, we
can define an event package that records the groups that a person
belongs to. Both approaches are beyond the scope of this document.
4. Membership Event Package
4.1. Event Package Name
The name of this event package is "membership". This package name is
carried in the SIP Event and Allow-Events header fields, as defined
in RFC 3265 [8].
Singh, et al. Expires January 15, 2009 [Page 5]
Internet-Draft Membership Event Package July 2008
4.2. Event Package Parameters
RFC 3265 [8] allows event packages to define additional parameters
carried in the Event header field. This event package does not
define additional parameters.
4.3. SUBSCRIBE Bodies
The SUBSCRIBE bodies may contain the watcher filters (RFC 4660) [9]
to specify triggers of when and what data the watcher is interested
in. The mechanism to specify the filter remains same as specified in
event filter format document [10].
4.4. NOTIFY Bodies
All subscribers and notifiers MUST support the "application/
membership+xml". By default, if no Accept header field is specified
in a SUBSCRIBE request, the NOTIFY request will contain a body in the
"application/membership+xml" data format.
5. XML Schema
The following is the schema definition of the membership package:
Singh, et al. Expires January 15, 2009 [Page 6]
Internet-Draft Membership Event Package July 2008
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:membership"
xmlns:group="urn:ietf:params:xml:ns:membership"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:include schemaLocation="membership-schema.xsd"/>
<xs:element name="membership" type="group:membership"/>
<xs:annotation>
<xs:documentation>
Root element for membership package.
</xs:documentation>
</xs:annotation>
<xs:complexType name="membership">
<xs:sequence>
<xs:element name="member" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:annotation>
<xs:documentation>group member information
</xs:documentation>
</xs:annotation>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:attribute name="id"
type="xs:nonNegativeInteger"
use="required"/>
<xs:annotation>
<xs:documentation>Unique identification number.
</xs:documentation>
</xs:annotation>
<xs:attribute name="entity" type="xs:anyURI"
use="required"/>
<xs:annotation>
<xs:documentation>Communications address.
</xs:documentation>
</xs:annotation>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
<xs:attribute name="state" type="xs:string"/>
<xs:attribute name="version" type="xs:unsignedInt"/>
</xs:complexType>
</xs:schema>
Singh, et al. Expires January 15, 2009 [Page 7]
Internet-Draft Membership Event Package July 2008
Figure 2: XML schema
6. Examples
6.1. Example of membership event package XML
An example of membership event package XML is given below:
<?xml version="1.0" encoding="utf-8" ?>
<membership xmlns="urn:ietf:params:xml:ns:membership"
entity="sip:ur351f@nj.cars.gov"
state="full"
version="1" >
<member id=87553EBFA0D4
entity="sip:ur351f@nj.cars.gov">presence vehicleinfo</member>
<member id=8572770D69C3
entity="sip:alice@example.com">presence</member>
<member id=F547D3C519A0
entity="sip:bob@example.com">presence foo</member>
<member id=FB280604CEAF
entity="pres:piotr@anotherexample.com">presence </member>
<member id=0C6247D54256
entity="sip:carol@example.com">presence foobar</member>
</membership>
Figure 3: XML example
6.2. Message Flow Example
The application or a presence agent of the user subscribes to
membership events of the the specific group, in this case a vehicle
sip:ur351f@nj.cars.gov, on the membership event server to get the
member list for that group.
Singh, et al. Expires January 15, 2009 [Page 8]
Internet-Draft Membership Event Package July 2008
SUBSCRIBE sip:ur351f@nj.cars.gov SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKnashds7
To: <sip:ur351f@nj.cars.gov>
From: <sip:app.example.com>
Call-ID: 1234@app.example.com
CSeq: 1001 SUBSCRIBE
Max-Forwards: 70
Event: membership
Accept: application/membership+xml
Contact: <sip:app.example.com>
Expires: 86400
Content-Length: 0
Membership event server,which maintains the membership list for
the group ur351f@nj.cars.gov, responds with a NOTIFY request.
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/TCP membership.example.com;branch= z9hG4bKnashds7
From: <sip: ur351f@nj.cars.gov>
To: <sip:app.example.com>
Call-ID: 1234@app.example.com
Event: membership
Subscription-State: active;expires=6660
Max-Forwards: 70
CSeq: 8775 NOTIFY
Contact: <sip:membership.example.com>
Content-Type: application/membership+xml
Content-Length: ...
<?xml version="1.0" encoding="utf-8" ?>
<membership xmlns="urn:ietf:params:xml:ns:membership"
entity="sip:ur351f@nj.cars.gov"
state="full"
version="1" >
<member id=87553EBFA0D4
entity="sip:ur351f@nj.cars.gov">
presence vehicle-info</member>
<member id=8572770D69C3
entity="sip:alice@example.com">presence</member>
<member id=F547D3C519A0
entity="sip:bob@example.com">presence foo</member>
<member id=FB280604CEAF
entity="pres:piotr@anotherexample.com">presence </member>
<member id=0C6247D54256
entity="sip:carol@example.com">presence foobar</member>
</membership>
Singh, et al. Expires January 15, 2009 [Page 9]
Internet-Draft Membership Event Package July 2008
Figure 4: Membership event package message flow example
The NOTIFY request body indicates that the user Alice is in the car
with some other passengers. Alice's presentity can be extended by
information from vehicle entity. This requires subscription to
vehicle-info (vehicle specific information, e.g., telematics) and
presence (GPS location) event packages of the ur351f@nj.cars.gov
vehicle entity. The application sends SUBSCRIBE requests to a
vehicle using event=vehicle-info and event=presence and then
processes the obtained information to derive user's presence
information.
Using event=vehicle-info:
SUBSCRIBE sip:ur351f@nj.cars.gov SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKnashds7
To: <sip:ur351f@nj.cars.gov>
From: <sip:app.example.com>
Call-ID: 12345@app.example.com
CSeq: 1004 SUBSCRIBE
Max-Forwards: 70
Event: vehicle-info
Accept: application/vehicle-info+xml
Contact: <sip:app.example.com>
Expires: 86400
Content-Length: 0
The vehicle-info event server sends back a NOTIFY
request with the vehicle information.
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/TCP es1.avis.com;branch=z9hG4bKna998sk
From: <sip:ur351f@nj.cars.gov>;tag=ffff
To: <sip:app.example.com>;tag=ght5
Call-ID: 12345@app.example.com
Event: vehicle-info
Subscription-State: active;expires=86660
Max-Forwards: 70
CSeq: 1104 NOTIFY
Contact: sip:es1.avis.com
Content-Type: application/vehicle-info+xml
Content-Length: ...
<vehicle-info body>
Singh, et al. Expires January 15, 2009 [Page 10]
Internet-Draft Membership Event Package July 2008
Using event=presence:
SUBSCRIBE sip:ur351f@nj.cars.gov SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKnashds7
To: <sip:ur351f@nj.cars.gov>
From: <sip:app.example.com>
Call-ID: 123456@example.com
CSeq: 1005 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip:app.example.com>
Expires: 86400
Content-Length: 0
The presence event server sends back a NOTIFY request
with vehicle location information.
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/TCP es2.avis.com;branch=z9hG4bKna998sk
From: <sip:ur351f@nj.cars.gov>;tag=ffff
To: <sip:app.example.com>;tag=ght5
Call-ID: 123456@app.example.com
Event: presence
Subscription-State: active;expires=86660
Max-Forwards: 70
CSeq: 1105 NOTIFY
Contact: sip:es2.avis.com
Content-Type: application/pidf+xml
Content-Length: ...
<PIDF body>
The application (e.g., presence server) may use the information
from the last two NOTIFY requests to compose user's presence
state and to send expanded PIDF to requesting watchers.
For example, the PIDF/RPID status (the activity tag) could be
set to 'driving' if the car is moving.The vehicle location
information, if present, will be included in user's expanded
PIDF.
Figure 5: Use of information from NOTIFY [membership] to derive
presence information of user
In another flow, membership information from the NOTIFY request could
simply be used to extend the PIDF/RPID status to 'driving' (the
Singh, et al. Expires January 15, 2009 [Page 11]
Internet-Draft Membership Event Package July 2008
activity tag) for all members.
7. Security Considerations
7.1. Authorization Considerations
The group membership data contains a privacy sensitive information as
it can be used to deduce more detailed presence information of the
user from different entities or to obtain a list of users
participating in common activities such as traveling, meetings and
on-call duties. Hence, access to membership lists should be
controlled and be unavailable to unauthorized entities.
There may be many consumers of information contained in the group
membership lists and in the data received from event packages, which
group members support. For example, a vehicle management company may
be authorized to obtain the vehicle information using vehicle-info
event package. Conversely, a vehicle management server may allow
vehicle-info data to be passed to a user presentity only if the user
is a member of a group representing this vehicle. In the car rental
scenario example, apart from car rental company, only the presentity
associated with the car is authorized by the car rental company to
get vehicle-info data for the car. The same applies to the vehicle
location data. The presentity may have this data aggregated into its
extended presence information.
In many cases, other users may get the membership data indirectly.
Watchers, who want to get presentity's extended presence information
can obtain it by subscribing to presentity using the presence event
package. The PA would send presence information based on
presentity's privacy preferences as described in the common policy
specification [11].
8. IANA Considerations
A future version of this document will provide IANA considerations.
9. Acknowledgements
10. References
Singh, et al. Expires January 15, 2009 [Page 12]
Internet-Draft Membership Event Package July 2008
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[4] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format (PIDF) to Indicate Status Information
for Past and Future Time Intervals", RFC 4481, July 2006.
10.2. Informative References
[5] Singh, V., "Vehicle Info Event Package",
draft-singh-simple-vehicle-info-01 (work in progress),
July 2007.
[6] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[9] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Filtering", RFC 4660, September 2006.
[10] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format for
Event Notification Filtering", RFC 4661, September 2006.
[11] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007.
[12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and
J. Polk, "Geolocation Policy: A Document Format for Expressing
Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-17 (work in progress), June 2008.
Singh, et al. Expires January 15, 2009 [Page 13]
Internet-Draft Membership Event Package July 2008
[13] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic
Feature Extensions to the Presence Information Data Format
Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-03 (work in progress),
July 2008.
Authors' Addresses
Vishal Singh
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Email: vs2140@cs.columbia.edu
URI: http://www.cs.columbia.edu/~vs2140
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+simple@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Piotr Boni
Verizon Communications
40 Sylvan Rd
Waltham, MA 02451
US
Phone: +1 781 466 2903
Email: piotr.boni@verizon.com
Singh, et al. Expires January 15, 2009 [Page 14]
Internet-Draft Membership Event Package July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Singh, et al. Expires January 15, 2009 [Page 15]