[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]