SIPPING WG Mahfuzur Rahman Internet Draft Brijesh Kumar Expires: Dec 2005 Panasonic Bin Hu Motorola Ashir Ahmed NTT Communications June 16, 2005 A Session Initiation Protocol (SIP) Event Package for Device Information draft-rahman-sipping-device-info-02.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 December 16, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 December, 2005 [Page 1] Internet Draft device-info June 16, 2005 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 A Session Initiation Protocol (SIP) Event Package for Device Information.......................................................1 1. Introduction.................................................3 2. Terminology and Conventions..................................4 3. Scope and Limitations........................................4 4. Use Cases....................................................5 5. Event Package Definition.....................................7 5.1. Event Package Name.........................................7 5.2. Event Package Parameters...................................7 5.3. SUBSCRIBE Bodies...........................................7 5.4. SUBSCRIBE Duration.........................................8 5.5. NOTIFY Bodies..............................................8 5.6. Notifier Processing of Subscribe Requests..................8 5.6.1. Authentication............................................9 5.6.2. Authorization.............................................9 5.7. Notifier Generation of Notify Requests.....................9 5.8. Subscriber Processing of NOTIFY Requests..................10 5.9. Rate of Notifications.....................................10 5.10. State Agents..............................................10 6. XML Schema Definitions......................................11 7. Examples....................................................13 8. Example Call Flow...........................................14 9. IANA Considerations.........................................18 9.1. SIP Event Package Registration............................18 9.2. Content-type registration for 'application/device- profile+xml'.....................................................18 9.3. URN sub-namespace registration for........................20 'urn:ietf:params:xml:ns:device-profile'..........................20 10. Security Considerations.....................................21 11. Normative References........................................21 12. Informative References......................................22 13. Authors' and Editor's Addresses.............................22 14. Full Copyright Statement....................................23 15. Intellectual Property.......................................23 16. Acknowledgement:............................................23 Rahman, et al. Expires December, 2005 [Page 2] Internet Draft device-info June 16, 2005 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. There are forums such as UPnP, DLNA etc. defining schemas for classes of devices compatible with device definitions. 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 December, 2005 [Page 3] Internet Draft device-info June 16, 2005 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. There are forums that are responsible for defining common schemas for device status for classes of devices. For example, UPnP forum defines a number operating states for various classes of devices including Audio- Video devices. It is also possible for vendors to define their own device specific status formats and publish like they do for SNMP MIBs. A number of devices with similar category will likely have the same status format. Even though we do not define a common format for device status information for any particular devices, 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 device status schema, URL for the schema etc which we refer to as device profile information. The scope of this draft is to define a SIP event package that will be used to retrieve device profile and then use the schema name in the device profile to retrieve device status information using the same event package. Device status information can also be represented as presence information. The use of presence for device status is under investigation and we plan to address this issue in the future revision of the drafts. Rahman, et al. Expires December, 2005 [Page 4] Internet Draft device-info June 16, 2005 4. Use Cases This section describes examples of a few use cases for the device information. Let us assume that a user A records some contents using the built-in camera on a mobile device at some remote location. The user wants to transfer these contents to a media recorder attached to the userÆs home network. The user wants multimedia contents to be instantly shared with other family members. We assume that both devices are SIP capable. Unfortunately, the user can initiate any recording actions only after discovering the current state, network connectivity and other operational status of the networked PVR. For example, the user may need to continuously monitor availability of the PVR, and other device states such as if the PVR is scheduled to record other programs, or if the PVR is available only for during certain duration, or if it has any available disk space to accommodate the new contents without jeopardizing recording of programmed contents. By getting the information about the operational status in time, the user application may decide to use different PVR in the userÆs home, or transfer these contents to another PVR in another family memberÆs home, or reschedule transferring of contents from the remote location. Another example that can benefit with device information is from the realm of inter-personal communication between a group of friends. We assume that each device and its operational context vary. The examples of device operating status include Communication Capability, Language Setting, and Free Text Status. The examples of device availability include Availability Status, Preferred Communication Method and Free Text Availability. The examples of device location include PLMN code, Geographical Location, Time Zone and Free Text Location. The use case of using such device information is as follows: A group of friends, John, Mary, James and Jenny, have enjoyed chatting with each other with their smart phones that support voice, video and multimedia IM functions. One day, John wants to chat with his friends again. He first subscribes to the device information of his friends so that he can know what are the communication capabilities, preferred language, preferred communication method, availability status, and their locations. Rahman, et al. Expires December, 2005 [Page 5] Internet Draft device-info June 16, 2005 John now knows the following device information of each friend: Mary: ( { voice, IM, PoC, PTX }, { English }, { IM }, { N/A - in a conference }, { Rome } ) James: ( { voice, IM, PoC }, { English }, { PoC }, { Available }, { San Francisco } ) Jenny: ( { voice, PoC, PTX }, { English }, { PoC }, { Available }, { San Jose } ) John knows that Mary is in Rome for a conference, while she can be reached through IM. Both James and Jenny can be reached through PoC, while James is in San Francisco (SFO), and Jenny is in San Jose (SJ). John established a PoC session with James and Jenny, talking about going to the Tech Museum in SJ. At the same time, he is also chatting with Mary in IM. He notices that JamesÆ location is constantly changing; meaning James is driving to SJ. After a while, he also notices that MaryÆs availability is changed to "available", and her preferred communication method is changed to "PoC". So John adds Mary to this PoC session, and Mary shares her pictures in Rome with them by using "PTX". Noticing James does not have "PTX", John uses "IM" to share MaryÆs picture with James. Finally, John notices that James and JennyÆs location are in the same block as he is. He knows that they have arrived. So they enter into Tech Museum in SJ, and John also shares what he sees with Mary using PTX video. Another example where device information can be useful is related to remote monitoring using a SIP capable video camera. This means that a number of events from the camera such as detection of motion, change in its zoom parameters, its orientation etc., can be sent to the sip capable mobile device using the device information package. Similarly, there could be many such instances where notification of operating information of another peer could be useful for adjusting the application behavior. Rahman, et al. Expires December, 2005 [Page 6] Internet Draft device-info June 16, 2005 5. Event Package Definition This section provides the details for defining a SIP specific event package as defined in Section 5.4 of [2]. 5.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 5.2. Event Package Parameters No package specific Event header parameters are defined for this event package. 5.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 December, 2005 [Page 7] Internet Draft device-info June 16, 2005 5.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. 5.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. 5.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 December, 2005 [Page 8] Internet Draft device-info June 16, 2005 5.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. 5.6.2. Authorization A notifier 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. 5.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 December, 2005 [Page 9] Internet Draft device-info June 16, 2005 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. 5.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. 5.9. Rate of Notifications RFC 3265 requires each package to specify the maximum rate at which notifications can be sent. Device-profile/ Device-status notifiers SHOULD NOT generate notifications for a single device at a rate of more than once every five seconds. 5.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 document does not recommend any state agent for device-info event package. Rahman, et al. Expires December, 2005 [Page 10] Internet Draft device-info June 16, 2005 6. XML Schema Definitions Device Profile Information Rahman, et al. Expires December, 2005 [Page 11] Internet Draft device-info June 16, 2005 SchemaName: This defines a MIME type content name. The procedure to register a new mime type content is defined in section 9. Our proposed scheme to access device's status requires using standard MIME types corresponding to standard schemas. While not recommended, the use of proprietary MIME types corresponding to a device manufacturers proprietary schema is also supported. For example, the MIME type of a camera manufactured by XYZ Company could be either application/UPnPCameraStatusClass+xml for a UPnP capable camera or application/XYZCamera+xml for a proprietary device. SchemaURL: The purpose of this element is to provide a URL where the schema definition of the mime type can be found. A user agent who would like to monitor the status information of an UA can retrieve the schema definition of that device using the URL defined in the deviceÆs profile. The procedure an UA will use for retrieving the operating status of a device is as follows: o Subscribe to the device profile of the device. o Wait for the NOTIFY response containing the device profile specification. o Extract the SchemaName and SchemaURL. o Use the SchemaURL to retrieve a copy of the schema if the agent needs it. o Subscribe to device status event. o Wait for NOTIFY responses and use the status schema to extract and interpret the attributes in the body of the responses. Rahman, et al. Expires December, 2005 [Page 12] Internet Draft device-info June 16, 2005 7. Examples UPnPCameraStatusClass abcdef http://www.UPnPCameraStatusClass.com/Schema application/UPnPCameraStatusClass+xml XYZ Model123 http://www.UPnPCameraStatusClass.com/model23 MMNN1234-789-00 vxn1234 Rahman, et al. Expires December, 2005 [Page 13] Internet Draft device-info June 16, 2005 8. 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 December, 2005 [Page 14] Internet Draft device-info June 16, 2005 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: .. UPnPCameraStatusClass abcdef http://www.UPnPCameraStatusClass.com/Schema application/UPnPCameraStatusClass+xml XYZ Model123 http://www.UPnPCameraStatusClass.com/model23 MMNN1234-789-00 vxn1234 Rahman, et al. Expires December, 2005 [Page 15] Internet Draft device-info June 16, 2005 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/UPnPCameraStatusClass+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 December, 2005 [Page 16] Internet Draft device-info June 16, 2005 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/UPnPCameraStatusClass+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 December, 2005 [Page 17] Internet Draft device-info June 16, 2005 9. 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]. 9.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.) 9.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 December, 2005 [Page 18] Internet Draft device-info June 16, 2005 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 December, 2005 [Page 19] Internet Draft device-info June 16, 2005 9.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 December, 2005 [Page 20] Internet Draft device-info June 16, 2005 10. 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. 11. 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 December, 2005 [Page 21] Internet Draft device-info June 16, 2005 12. 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. 13. 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 Digital Networking Laboratory 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 December, 2005 [Page 22] Internet Draft device-info June 16, 2005 14. Intellectual Property Statement 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. 15. Disclaimer of Validity 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. 16. Copyright Statement Copyright (C) The Internet Society (2005). 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. 17. Acknowledgement: Funding for the RFC Editor function is currently provided by the Internet Society. Rahman, et al. Expires December, 2005 [Page 23]