SIPPING WG Mahfuzur Rahman Internet Draft Brijesh Kumar Expires: April 2005 Panasonic Bin Hu Motorola Ashir Ahmed NTT Communications October 24, 2004 A Session Initiation Protocol (SIP) Event Package for Device Information draft-rahman-sipping-device-info-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, accordance with RFC 3668. 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 April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a Session Initiation Protocol (SIP) event package to carry device information including device status and device profile. Device status refers to a set of dynamic attributes that describe device's operating state, availability, and location information etc. Device profile on the other hand refers to a limited set of static attributes including device type, name, format type of status information, and model etc. of a particular device. Rahman, et al. Expires April, 2005 [Page 1] Internet Draft device-info October 24, 2004 Device status information is particularly important to monitoring applications where a user agent would be able to monitor the status of a SIP device from a remote location and be notified of the changes of status. Table of Contents 1. Introduction.................................................3 2. Terminology and Conventions..................................4 3. Scope and Limitations........................................4 4. Event Package Definition.....................................5 4.1. Event Package Name.........................................5 4.2. Event Package Parameters...................................5 4.3. SUBSCRIBE Bodies...........................................5 4.4. SUBSCRIBE Duration.........................................6 4.5. NOTIFY Bodies..............................................6 4.6. Notifier Processing of Subscribe Requests..................6 4.6.1. Authentication............................................7 4.6.2. Authorization.............................................7 4.7. Notifier Generation of Notify Requests.....................7 4.8. Subscriber Processing of NOTIFY Requests...................8 4.9. Rate of Notifications......................................8 4.10. State Agents...............................................8 5. XML Schema Definitions.......................................9 6. Examples....................................................10 7. Example Call Flow...........................................11 8. IANA Considerations.........................................15 8.1. SIP Event Package Registration............................15 8.2. Content-type registration for 'application/device- profile+xml'.....................................................15 8.3. URN sub-namespace registration for........................17 ĉurn:ietf:params:xml:ns:device-profile'..........................17 9. Security Considerations.....................................18 10. Normative References........................................18 11. Informative References......................................19 12. Authors' and Editor's Addresses.............................19 13. Full Copyright Statement....................................20 14. Intellectual Property.......................................20 15. Acknowledgement:............................................20 Rahman, et al. Expires January, 2005 [Page 2] Internet Draft device-info October 24, 2004 1. Introduction The Session Initiation Protocol (SIP) [1] specific event notification mechanism provides a user agent with a way to subscribe to and receive notifications of events within a SIP networks. SIP also has the notion of event package. An event package is an instantiation of a generalized event framework where a set of state information to be reported by a notifier to a subscriber. Here we define an event package for device status and device profile information. This event package can be used by a user agent who would like to monitor the status of network attached SIP devices from a remote location and be notified of the changes of status. This document does not define a common format for device status information. The format of device status information should be vendor specific. Instead, we define a common format for device profile information, which has an attribute that defines the vendor specific format type of the device status information to be used for that particular device. This event package defines a mechanism by which a user agent can retrieve device profile information and then use the format type of the device status information to request status notifications. While focus of the current draft is to retrieve device status information, it can easily be extended to include user, application or network or any other profiles for a device. This package is particularly important to retrieve the operating status, availability, and location etc. of SIP devices. In order to retrieve the operating status of a SIP device, a user agent will first subscribe for the common device profile information of the SIP device. In the notification message, the user agent will receive the profile of the SIP device, which contains the name of vendor specific device status format. The user agent will then subscribe for the vendor specific device status attributes that correspond to the status of the SIP device and in response notification events will be generated to the user agent with the values of the attributes the user has subscribed for. The specific detail of this event package and the sequence of operation are described in the later part of this document. Rahman, et al. Expires January, 2005 [Page 3] Internet Draft device-info October 24, 2004 2. Terminology and Conventions Device: A software or hardware appliance, which is represented by a SIP UA Device Status: A set of dynamic attributes describing the operating state, availability, and location information etc. of a device. Device Profile: A limited set of static attributes including device type, name, format of status information and model etc. of a particular device to be used for identification purposes. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 3. Scope and Limitations Status information of a device is primarily the operating state, availability and location of the device. It is not the intent of this draft to encode all these as status attributes and provide a common format for all kind of devices. In fact it would be very difficult to define a single comprehensive ontology for all kinds of Network-attached devices. The vendors can define their own device specific status format. It is possible that a number of devices with similar category MAY have the same status format. Even though we do not define a common format for device status information but in this document we define a basic set of static attributes that are common to all kind of devices such as device name, type, manufacturer name, name of the format of mode etc which we refer to as device profile information. Rahman, et al. Expires January, 2005 [Page 4] Internet Draft device-info October 24, 2004 4. Event Package Definition This section provides the details for defining a SIP specific event package as defined in Section 5.4 of [2]. 4.1. Event Package Name The specification of SIP specific event package [2] requires event package definition to specify the name of the Package. The token name of this event package is: "device-info" This value appears in the event header present in SUBSCRIBE and NOTIFY requests. Example: Event: device-info 4.2. Event Package Parameters No package specific Event header parameters are defined for this event package. 4.3. SUBSCRIBE Bodies The SIP event specification [2] requires definitions of subscribe bodies. The SUBSCRIBE message for device profile information does not contain any body. A SUBSCRIBE for vendor defined device status information MAY contain a body. The body will primarily be used for the filtering of subscription. The definition of such subscription body is outside the scope of this document. If the SUBSCRIBE message does not contain any body then the default filtering policy will be adopted. The rules for default filtering policy is as follows: o Notifications are generated every time when there is a change in the state of device status information. o Notifications usually do not contain full state. They rather indicate the state that has changed. However, notification triggered from a response of SUBSCRIBE message will contain full device status information. Rahman, et al. Expires January, 2005 [Page 5] Internet Draft device-info October 24, 2004 4.4. SUBSCRIBE Duration The subscription for device profile information is a one-time subscription as device profile contains only static information and does not change over time. This one-time subscription is necessary to find out vendor specific MIME type definition of device status information, which can be used for subsequent subscription for device status. So the "expires" header of SUBSCRIBE message for device profile information will specify "0" duration which is basically a fetch operation for device profile information. Once, device profile information is retrieved using the fetch operation, a subsequent SUBSCRIBE message should be sent to retrieve device status information with "Accept" header indicating the vendor specific MIME type name for the device status information. The event package name for both device profile and status information is the same, which is "device-info". A notifier can easily determine which MIME type is requested from this subscription by looking at the "Accept" header. The vendor specific MIME type name for device status information will be contained in the device profile information. The duration of subscription for device specific status information May range from minutes to several hours. Subscriptions in hours are more typical and recommended. The default subscription duration for device status information is 1 hour. 4.5. NOTIFY Bodies The SIP specific event specification [2] requires package definition to specify a set of allowed body types in NOTIFY message. RFC 3265 [2] also requires to specify the default value to be used when there is no Accept header in the SUBSCRIBE request. The body of notification message for a response to SUBSCRIBE message for device profile information will contain Mime Type content "application/device-profile+xml". As we are defining a single event package for both device profile and device status information, the determination of type of information is requested can be made by looking at the Accept header of SUBSCRIBE message. As the Accept header is being used to differentiate between data types, in order to implement this event package the use of Accept header is mandatory. 4.6. Notifier Processing of Subscribe Requests This section describes the processing to be performed by the notifier upon receipt of a SUBSCRIBE request for the device-info event package. Rahman, et al. Expires January, 2005 [Page 6] Internet Draft device-info October 24, 2004 4.6.1. Authentication The contents of a device-info document contain sensitive information about the devices in a SIP domain. Therefore, a notifier MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in RFC 3261 [4] and other authentication extensions. 4.6.2. Authorization A notifer MUST NOT accept a subscription unless authorization has been provided for the device. Authorization may have been provided ahead of time using any of the local access control mechanisms. 4.7. Notifier Generation of Notify Requests RFC 3265 describes the formatting and structure of NOTIFY messages. However, packages are required to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes this information for device information event package. A notifier MAY send a notify at any time. Typically, it will send one at any time device status changes. The times at which NOTIFY is sent for a particular subscriber, and the contents of the body in that notification, are subject to any rules specified by the authorization policy that governs the subscription. In the case of a pending subscription, when final authorization is determined, a NOTIFY can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a complete device status document with the deviceĈs current status information. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265, the Subscription-State header field indicates the state of the subscription. The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/device-profile+xml" if no Accept header field was present. Notifiers will typically act as Event State Compositors (ESC) and thus, will learn the device-information event state via PUBLISH requests sent from the user's Event Publication Agent (EPA) when the user changes one of those settings. Rahman, et al. Expires January, 2005 [Page 7] Internet Draft device-info October 24, 2004 For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using S/MIME. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications MAY provide authentication and message integrity using S/MIME. Since the NOTIFY is generated by the notifier, which may not have access to the key of the device represented by the device-profile, it will frequently be the case that the NOTIFY is signed by a third party. It is RECOMMENDED that the signature be by an authority over the domain to which the device is connected. In other words, for a user sip:user@abc.com, the signator of the NOTIFY SHOULD be the authority for example.com. 4.8. Subscriber Processing of NOTIFY Requests RFC 3265 leaves it to event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state. In this specification, each NOTIFY request contains either no Device-profile document, or a document representing one or more device-profile related data. Within a dialog, the device-profile document in the NOTIFY request with the highest CSeq header field value is the current one. When no document is present in that NOTIFY, the device-profile document present in the NOTIFY with the next highest CSeq value is used. 4.9. Rate of Notifications RFC 3265 requires each package to specify the maximum rate at which notifications can be sent. Device-profile notifiers SHOULD NOT generate notifications for a single device at a rate of more than once every five seconds. 4.10. State Agents RFC 3265 requires each package to consider the role of state agents in the package, and if they are used, to specify how authentication and authorization are done. This detail will be provided the next revision of this document. Rahman, et al. Expires January, 2005 [Page 8] Internet Draft device-info October 24, 2004 5. XML Schema Definitions Device Profile Information Rahman, et al. Expires January, 2005 [Page 9] Internet Draft device-info October 24, 2004 6. Examples MyCamera abcdef http://www.MyCamera.com/Schema application/MyCamera+xml XYZ Model123 http://www.MyCamera.com/model23 MMNN1234-789-00 vxn1234 Rahman, et al. Expires January, 2005 [Page 10] Internet Draft device-info October 24, 2004 7. Example Call Flow Subscriber Notifier | | | SUBSCRIBE (Expires =0)| | For device-profile F1 | |------------------ ---->| | F2 200 OK | |<-----------------------| | F3 NOTIFY | |<-----------------------| | F4 200 OK | |----------------------->| | | | SUBSCRIBE for Device | | Status Information F5 | |----------------------->| | F6 200 OK | |<-----------------------| | | | F7 NOTIFY | |<-----------------------| | F8 200 OK | |----------------------->| | | F1 SUBSCRIBE Subscriber -> Notifier Alice wants to know the status of her camera. She subscribes for device-profile of the camera SUBSCRIBE sip:alice-camera@example.com SIP/2.0 To: From: ;tag=78923 Call-Id: 1349882@alice-phone.example.com CSeq: 1 SUBSCRIBE Contact: Event: device-info Expires:0 Accept: application/device-profile+xml Content-Length: 0 Rahman, et al. Expires January, 2005 [Page 11] Internet Draft device-info October 24, 2004 F2 200 OK Notifier -> Subscriber SIP/2.0 200 OK To: ;tag=4442 From: ;tag=78923 Call-Id: 1349882@alice-phone.example.com CSeq: 1 SUBSCRIBE Expires: 0 Content-Length: 0 F3 NOTIFY Notifier -> Subscriber AliceĈs camera notifies her of the device profile, which has a URL indicating the location of the schema of status data format of the camera. It also specifies Mime type schema name. NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: ;tag=78923 From: ;tag=4442 Call-Id: 1349882@alice-phone.example.com CSeq: 20 NOTIFY Contact: Event: device-info Subscription-State: active; Content-Type: application/device-profile+xml Content-Length: .. MyCamera abcdef http://www.MyCamera.com/Schema application/MyCamera+xml XYZ Model123 http://www.MyCamera.com/model23 MMNN1234-789-00 vxn1234 Rahman, et al. Expires January, 2005 [Page 12] Internet Draft device-info October 24, 2004 F4 200 OK Subscriber -> Notifier SIP/2.0 200 OK To: ;tag=78923 From: ;tag=4442 Call-Id:1349882@alice-phone.example.com CSeq: 20 NOTIFY Content-Length: 0 F5 SUBSCRIBE Subscribe for camera status Alice has the Status data format for the camera. Alice now subscribes for the camera status SUBSCRIBE sip:alice-camera@example.com SIP/2.0 To: sip:alice-camera@example.com From: sip:alice@example.com ;tag=78923 Call-ID: 9987@alice-phone.example.com CSeq: 9887 SUBSCRIBE Contact: sip:alice-phone.example.com Event: device-info Expires:3600 Max-Forwards: 70 Accept: application/MyCamera+xml F6 200 OK SIP/2.0 200 OK To: sip:alice-camera@example.com;tag=4442 From: sip:alice@example.com ; tag=78923 Call-ID: 9987@alice-phone.example.com CSeq: 9987 SUBSCRIBE Contact: sip:alice-phone.example.com Expires: 3600 Rahman, et al. Expires January, 2005 [Page 13] Internet Draft device-info October 24, 2004 F7 NOTIFY Alice is notified of the status of the camera. The body of the notification message contains Mime type content. NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: sip:alice@example.com ;tag=78923 From: sip:alice-camera@example.com;tag=4442 Call-ID: 9987@alice-phone.example.com CSeq: 1288 NOTIFY Contact: sip:alice-camera.example.com Event: device-info Subscription-State:active Content-Type: application/MYCamera+xml Content-Length: ... // other status parameters defined by vendors F8 200 OK Subscriber -> Notifier SIP/2.0 200 OK To: ;tag=78923 From: ;tag=4442 Call-Id:9987@alice-phone.example.com CSeq: 1288 NOTIFY Content-Length: 0 Rahman, et al. Expires January, 2005 [Page 14] Internet Draft device-info October 24, 2004 8. IANA Considerations This memo calls for IANA to: - Register a new event package as per [2]. - Register a new MIME content-type application/device-profile+xml, per [9], - Register a new XML namespace URN for device profile information per [6]. 8.1. SIP Event Package Registration This document registers a new event package based on the registration procedures defined in RFC 3265 [2]. Package name: device-info Type: package Contact: Mahfuzur Rahman, Published Specification: RFCXXXX (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification.) 8.2. Content-type registration for 'application/device-profile+xml' To: ietf-types@iana.org Subject: Registration of MIME media type application/device- profile+xml MIME media type name: application MIME subtype name: device-profile+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC 3023], section 3.2. Security considerations: See section 10 of RFC 3023 [10] and section 8 of this specification. Rahman, et al. Expires January, 2005 [Page 15] Internet Draft device-info October 24, 2004 Interoperability considerations: This content type provides a common format for exchange of device profile information across the Internet. Published specification: RFCXXXX (this document) Applications which use this media type: This document is to be used by applications that monitor status of network-attached devices especially SIP devices. Additional information: Magic number(s): File extension(s): Macintosh File Type Code(s): Person & email address to contact for further information: Mahfuzur Rahman E-mail: mahfuz@research.panasonic.com Intended usage: LIMITED USE Author/Change controller: Send comments to Mahfuzur Rahman E-mail: mahfuz@research.panasonic.com Other information: This media type is a specialization of application/xml [RFC 3023], and many of the considerations described there also apply to application/device-profile+xml. Rahman, et al. Expires January, 2005 [Page 16] Internet Draft device-info October 24, 2004 8.3. URN sub-namespace registration for ĉurn:ietf:params:xml:ns:device-profile' Description: This is the XML namespace for XML elements defined by RFCXXXX to describe device profile information for the application/device-profile+xml content type. Registrant Contact: Mahfuzur Rahman, E-mail: XML: BEGIN Device Profile Information Data Format

Namespace for device profile information

application/device-profile+xml

See RFCXXXX.

END Rahman, et al. Expires January, 2005 [Page 17] Internet Draft device-info October 24, 2004 9. Security Considerations The status information of a network-attached device MAY contain sensitive information and hence a security mechanism is needed to protect the content of status information document. We will consider only securing the entire status document as element by element is not required for the particular usage of the status document. Device specific status information will be defined using MIME type by individual vendors of device manufacturer. S/MIME [9] provides several security properties i.e., confidentiality, integrity and authentication. S/MIME also provides end-to-end security. We do not see any instance where device specific status information defined by vendors needs to be modified in the middle by a proxy or a server while communicating between two peers. So it is appropriate to use S/MIME to provide end-to-end security. 10. 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., "Session Initiation Protocol (SIP)-Specific Event Notification," RFC 3265, June 2002. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [4] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task Force, May 1997. [5] R. Moats, "A URN namespace for IETF documents," RFC 2648, Internet Engineering Task Force, Aug. 1999. [6] M. Mealling, "The IETF XML registry," internet draft, Internet Engineering Task Force, June 2003. Work in progress. [7] B. Ramsdell, "S/MIME Version 3 Message Specification", draft- ietf-smime-rfc2633bis-03 (work in progress), January 2003. [8] N. Freed, J. Klensin, et al., "MIME Registration Procedures," RFC 2048, Internet Engineering Task Force, Nov. 1996. [9] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 3023, Internet Engineering Task Force, Jan. 2001. Rahman, et al. Expires January, 2005 [Page 18] Internet Draft device-info October 24, 2004 11. Informative References [10] Rosenberg, J., Roach, A. and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-04 (work in progress), June 2003. 12. Authors' and Editor's Addresses The addresses of authors and editors are listed below. Mahfuzur Rahman Panasonic Digital Networking Laboratory 2 Research Way Princeton, New Jersey 08540 USA Phone: +1 609 734 7332 E-mail: mahfuz@research.panasonic.com Brijesh Kumar Panasonic Technologies Company 2 Research Way Princeton, New Jersey 08540 USA Phone: +1 609 734 7329 E-mail: kumarb@research.panasonic.com Bin Hu Motorola Inc. 805 east Middlefield Road Mountain View CA 94043 Phone: +1 650 318 3201 Email: bhu@Motorola.com Ashir Ahmed NTT Communications Corporation 3-20-2 Nishi-Shinjuku Shinjuku-ku, Tokyo 163-1421 JAPAN Phone: +81 3 6800 2029 Email: a.ahmed@ntt.com Rahman, et al. Expires January, 2005 [Page 19] Internet Draft device-info October 24, 2004 13. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. 14. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. 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 implementors or users of this specification can be obtained from the IETF on-line 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 which may cover technology that may be required to practice this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 15. Acknowledgement: Funding for the RFC Editor function is currently provided by the Internet Society. Rahman, et al. Expires January, 2005 [Page 20]