Internet DRAFT - draft-rahman-sipping-device-info

draft-rahman-sipping-device-info





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 
 
 
   <?xml version="1.0" encoding="UTF-8"?> 
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
              targetNamespace="urn:ietf:params:xml:ns:device-profile" 
              xmlns:tns="urn:ietf:params:xml:ns:device-profile"> 
 
   <!-- This import brings in the XML language attribute xml:lang--> 
 
   <xs:import namespace="http://www.w3.org/XML/1998/namespace" 
                schemaLocation="http://www.w3.org/2001/03/xml.xsd" />    
 
     <xs:element name="device-profile"> 
          <xs:annotation> 
           <xs:documentation> Device Profile 
           Information</xs:documentation> 
          </xs:annotation> 
          <xs:complexType> 
               <xs:sequence> 
                    <xs:element name="DeviceName" type="xs:string"/> 
                    <xs:element name="DeviceType" type="xs:string"/> 
                    <xs:element name="SchemaURL" type="xs:anyURI"/> 
                    <xs:element name="SchemaName" type="xs:token"/> 
                    <xs:element name="Manufacturer" type="xs:string"/> 
                    <xs:element name="ModelName" type="xs:string"/> 
                    <xs:element name="ModelNumber" type="xs:string"/> 
                    <xs:element name="ModelURL" type="xs:anyURI"/> 
                    <xs:element name="SerialNumber" type="xs:string"/> 
                    <xs:element name="ProductCode" type="xs:string"/> 
               </xs:sequence> 
          </xs:complexType> 
     </xs:element> 
   </xs:schema> 
      
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
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 
 
      <?xml version="1.0" encoding="UTF-8"?> 
         <device-profile xmlns="urn:ietf:params:xml:ns:device-profile"> 
               <DeviceName>UPnPCameraStatusClass</DeviceName> 
               <DeviceType>abcdef</DeviceType> 
               <SchemeURL>http://www.UPnPCameraStatusClass.com/Schema</
               SchemeURL> 
               <SchemeName>application/UPnPCameraStatusClass+xml</Schem
               eName> 
               <Manufacturer>XYZ</Manufacturer> 
               <ModelName>Model123</ModelName> 
               <ModelURL>http://www.UPnPCameraStatusClass.com/model23</
               ModelURL> 
               <SerialNumber>MMNN1234-789-00</SerialNumber> 
               <ProductCode>vxn1234</ProductCode> 
        </device-profile> 
    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    
         
    
    
    
    
    
    
    
    
    
    
    
    
    
 
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: <sip:alice-camera@example.com> 
     From: <sip:alice@example.com>;tag=78923 
     Call-Id: 1349882@alice-phone.example.com 
      CSeq: 1 SUBSCRIBE 
      Contact: <sip:alice-phone.example.com> 
      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: <sip:alice-camera@example.com>;tag=4442 
      From: <sip:alice@example.com>;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: <sip:alice@example.com>;tag=78923 
      From: <sip:alice-camera@example.com>;tag=4442 
      Call-Id: 1349882@alice-phone.example.com 
      CSeq: 20 NOTIFY 
      Contact: <sip:alice-camera.example.com> 
      Event:  device-info 
      Subscription-State: active; 
      Content-Type: application/device-profile+xml 
      Content-Length: .. 
    
        <?xml version="1.0" encoding="UTF-8"?> 
          <device-profile xmlns="urn:ietf:params:xml:ns:device-
          profile"> 
                 <DeviceName>UPnPCameraStatusClass</DeviceName> 
                 <DeviceType>abcdef</DeviceType> 
                 <SchemeURL>http://www.UPnPCameraStatusClass.com/Schema
                 </SchemeURL> 
                 <SchemeName>application/UPnPCameraStatusClass+xml</Sch
                 emeName> 
                 <Manufacturer>XYZ</Manufacturer> 
                 <ModelName>Model123</ModelName> 
                 <ModelURL>http://www.UPnPCameraStatusClass.com/model23
                 </ModelURL> 
                 <SerialNumber>MMNN1234-789-00</SerialNumber> 
                 <ProductCode>vxn1234</ProductCode> 
            </device-profile> 
    
    
    
    
    
 
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: <sip:alice@example.com>;tag=78923 
      From: <sip:alice-camera@example.com>;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: ... 
    
      <?xml version="1.0"?> 
          <device-camera-status 
          xmlns="urn:ietf:params:xml:ns:UPnPCameraStatusClass" 
          version="0" state="full"> 
          // other status parameters defined by vendors 
          </device-camera-status> 
    
     F8 200 OK Subscriber -> Notifier 
    
      SIP/2.0 200 OK 
      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 
      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, <mahfuz@research.panasonic.com> 
    
   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:<mahfuz@research.panasonic.com> 
 
           XML: 
    
                 BEGIN 
                   <?xml version="1.0"?> 
                    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 
                    1.0//EN" 
                    "http://www.w3.org/TR/xhtml-basic/xhtml-
                    basic10.dtd"> 
                   <html xmlns="http://www.w3.org/1999/xhtml 
                   <head> 
                        <meta http-equiv="content-type" 
                        content="text/html;charset=iso-8859-1"/> 
                    <title> Device Profile Information Data Format   
                    </title> 
                   </head> 
                   <body> 
                         <h1>Namespace for device profile information 
                         </h1> 
                       <h2>application/device-profile+xml</h2> 
                         <p>See <a href="[[[URL of published 
                         RFC]]]">RFCXXXX</a>.</p> 
                    </body> 
                    </html> 
                  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]