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 Root element for membership package. group member information Unique identification number. Communications address. 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: presence vehicleinfo presence presence foo presence presence foobar 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: From: Call-ID: 1234@app.example.com CSeq: 1001 SUBSCRIBE Max-Forwards: 70 Event: membership Accept: application/membership+xml Contact: 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: To: Call-ID: 1234@app.example.com Event: membership Subscription-State: active;expires=6660 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: Content-Type: application/membership+xml Content-Length: ... presence vehicle-info presence presence foo presence presence foobar 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: From: Call-ID: 12345@app.example.com CSeq: 1004 SUBSCRIBE Max-Forwards: 70 Event: vehicle-info Accept: application/vehicle-info+xml Contact: 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: ;tag=ffff To: ;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: ... 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: From: Call-ID: 123456@example.com CSeq: 1005 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: 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: ;tag=ffff To: ;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: ... 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]