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]
