SIPPING WG M. Rahman Internet Draft Panasonic Expires: January 2004 A. Ahmed NTT Communications B. Hu Motorola July 11, 2004 A Session Initiation Protocol (SIP) Event Package for Device Information draft-rahman-sipping-device-info-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other intellectual property right (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 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 made obsolete 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. 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 January, 2005 [Page 1] Internet Draft device-info July 11, 2004 Device status information is particularly important to networked appliances due to its dynamic nature where a user agent would be able to monitor the status of networked appliances 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 5. XML Schema Definitions.......................................8 6. Examples.....................................................9 7. Example Call Flow...........................................10 8. IANA Considerations.........................................14 8.1. SIP Event Package Registration............................14 8.2. Content-type registration for 'application/device- profile+xml'.....................................................14 8.3. URN sub-namespace registration for........................16 ĉurn:ietf:params:xml:ns:device-profile'..........................16 9. Security Considerations.....................................17 10. Normative References........................................17 11. Informative References......................................18 12. Authors' and Editor's Addresses.............................18 13. Intellectual Property Statement.............................19 14. Full Copyright Statement....................................19 15. Acknowledgement:............................................19 Rahman, et al. Expires January, 2005 [Page 2] Internet Draft device-info July 11, 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 networked attached 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. This package is particularly important to retrieve the operating status, availability, and location etc. of Networked Appliances. In order to retrieve the operating status of a Networked Appliance, a user agent will first subscribe for the common device profile information of the appliance. In the notification message, the user agent will receive the profile of the networked appliance, 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 appliance 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 July 11, 2004 2. Terminology and Conventions 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. Networked Appliance (NA): The term Networked Appliance has been defined in [7] as a dedicated function consumer device containing a networked processor. But more generally it is any non-general purpose device (i.e., not a PC, Palm Pilot, PDA, etc.) that has a network connection. Examples of NAs include: lamps, refrigerators, toasters, and TVs. 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 July 11, 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 July 11, 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. Rahman, et al. Expires January, 2005 [Page 6] Internet Draft device-info July 11, 2004 The format of device status information is vendor specific and the format of "application/device-profile+xml" has an attribute that defines the name of the format to be used for the status information of a device. The body of notification message for the status information of a specific device will contain vendor specific Mime content. This document does not define any vendor specific mime format for any device. It is expected that individual device vendor will register their device status specific Mime content with the IANA. It is also possible to have the same device status format for a number of devices of similar category. Rahman, et al. Expires January, 2005 [Page 7] Internet Draft device-info July 11, 2004 5. XML Schema Definitions Device Profile Information Rahman, et al. Expires January, 2005 [Page 8] Internet Draft device-info July 11, 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 9] Internet Draft device-info July 11, 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 10] Internet Draft device-info July 11, 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 11] Internet Draft device-info July 11, 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 12] Internet Draft device-info July 11, 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 13] Internet Draft device-info July 11, 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 14] Internet Draft device-info July 11, 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 networked appliances. 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 15] Internet Draft device-info July 11, 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 16] Internet Draft device-info July 11, 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] S. Tsang, S. Moyer, D. Marples, H. Schulzrinne and A. Roychowdhury, "Requirements for Networked Appliances: Wide-Area Access, Control, and Interworking," draft-tsang-appliances-reqs- 01.txt, Sept 2000. [8] B. Ramsdell, "S/MIME Version 3 Message Specification", draft- ietf-smime-rfc2633bis-03 (work in progress), January 2003. [9] N. Freed, J. Klensin, et al., "MIME Registration Procedures," RFC 2048, Internet Engineering Task Force, Nov. 1996. [10] 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 17] Internet Draft device-info July 11, 2004 11. Informative References [11] 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 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 Bin Hu Motorola Inc. 805 east Middlefield Road Mountain View CA 94043 Phone: +1 650 318 3201 Email: bhu@Motorola.com Rahman, et al. Expires January, 2005 [Page 18] Internet Draft device-info July 11, 2004 13. Intellectual Property Statement By submitting this Internet-Draft, we certify that any applicable patent or other intellectual property right (IPR) claims of which we am aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 14. Full Copyright Statement Copyright (C) The Internet Society 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 CONTRIBUTORS, THE ORGANIZATIONS THEY REPRESENT OR ARE 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. 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 implementers 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: The Internet Society currently provides funding for the RFC Editor function. Rahman, et al. Expires January, 2005 [Page 19]