Internet DRAFT - draft-wang-simple-presence-ril
draft-wang-simple-presence-ril
Network Working Group Xiao. Wang
Internet-Draft Peili. Xu
Expires: August 17, 2006 Huawei Technologies
February 13, 2006
A Method to deliver Resource Information List for Presence Information
draft-wang-simple-presence-ril-01
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 August 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Presence Information Data Format(PIDF) [1] and Rich Presence
Extensions to the Presence Information Data Format(RPID) [2] have
definition for a lot of presence information. Notifier can filter
the presence information to subscriber according to local policy .
But the notifier may not support all the presence information. It is
a matter how to inform the subscriber the allowed, forbidden and
unsupported presence information. This document provides a method to
solve this problem by introducing the concept of Resource Information
Wang & Xu Expires August 17, 2006 [Page 1]
Internet-Draft A Method of RIL February 2006
List(RIL).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Negotiation of RIL . . . . . . . . . . . . . . . . . . . . . . 6
5. Definition of RIL . . . . . . . . . . . . . . . . . . . . . . 7
6. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Description of Notifier Behavior . . . . . . . . . . . . . 8
6.2. Description of Subscriber Behavior . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. XML Schema for RIL . . . . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. New SIP Option Tag: RIL . . . . . . . . . . . . . . . . . 19
10.2. New MIME type for RIL . . . . . . . . . . . . . . . . . . 19
10.3. URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . 19
11. Change control . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Changes from draft-wang-simple-presence-ril-00.txt . . . . 21
12. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Wang & Xu Expires August 17, 2006 [Page 2]
Internet-Draft A Method of RIL February 2006
1. Introduction
RFC 3265 [3] described a general framework by which notification of
event, and the rules of creating SUBSCRIBE request and NOTIFY
request. SUBSCRIBE applies to subscription and NOTIFY applies to
notification when the resource state has changed.
Presence is an important part of SIMPLE. PIDF [1] and RPID [2]
defined a lot of presence information. One user can achieve the
presence information of other users by sending SUBSCRIBE request.
Whereas, the presence information has privacy, notifier can have a
local policy to control who can have what part of presence
information. This policy can be configured through Web, Terminal
User Interface etc.
Another issue to be considered is that the Notifier MAY NOT support
all the presence information defined by PIDF [1] and RPID [2] for the
reason of physical device, environment, or the notifier itself etc.
Currently, if the notifier provide partial presence information in
PIDF, the subscriber can not know the exact reason for the missing
part, whether it is not supported, temporarily not available or
forbidden to expose.
This document introduces a method to solve the above issues by
allowing NOTIFY to deliver RIL(Resource Information List) to
subscriber.
Wang & Xu Expires August 17, 2006 [Page 3]
Internet-Draft A Method of RIL February 2006
2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 and
indicate requirement levels for compliant implementations.
Wang & Xu Expires August 17, 2006 [Page 4]
Internet-Draft A Method of RIL February 2006
3. Definitions
USRIL: Unsupported Resource Information List, base on a set which
describe all presence element that the RFC and Draft supported, but
in this set notifier can not support some presence element, the
unsupported part of this set is called USRIL. USRIL can be some
single presence element or some presence element set or the both.
ASPE: Allowed Subscribe Presence Element, notifier perform local
policy to decide which presence element can be subscribed, and with
the subscriber wish to obtain presence element together making "and"
operation, that is called ASPE. ASPE can be some single presence
element or some presence element set or the both. But purpose to
make ASPE simple, ASPE may include a subset of FSPE.
FSPE: Forbidden Subscribe Presence Element, notifier perform local
policy to decide which presence element can not be subscribed, and
with the subscriber wish to obtain presence element together making
"and" operation, that is called FSPE. FSPE can be some single
presence element or some presence element set or the both.
FASPE: Final Allowed Subscribe Presence Element, subscriber make
"and" operation by ASPE and FSPE. In the FASPE exclude any subset of
FSPE and USRIL.
RIL: Resource Information List, include ASPE, FSPE and USRIL.
Wang & Xu Expires August 17, 2006 [Page 5]
Internet-Draft A Method of RIL February 2006
4. Negotiation of RIL
This specification uses the SIP option tag mechanism for negotiating
support for the extension defined herein. Refer to RFC3261 [5] for
the normative description of processing of the "Supported" and
"Require" header fields and the 421 (Extension Required) response
code. If subscriber want to get RIL in the subsequent NOTIFY
request, MUST include the "Supported" or "Require" header field with
"RIL" in a SUBSCRIBE request.
When SUBSCRIBE request includes "RIL" in the "Supported" header
field, if notifier supports RIL then it MUST include "Supported"
header field with "RIL" in the 2xx response, otherwise it MUST NOT
include "RIL" in the "Supported" header field. When SUBSCRIBE
request includes "RIL" in the "Require" header field, if notifier
doesn't support then according to RFC3261 it returns the 421 response
code. If SUBSCRIBE request or refreshing SUBSCRIBE request doesn't
include "RIL" in "Supported" or "Require" header field, it means that
subscriber doesn't want to obtain RIL, the notifier MUST NOT insert
RIL in the subsequence NOTIFY message.
Wang & Xu Expires August 17, 2006 [Page 6]
Internet-Draft A Method of RIL February 2006
5. Definition of RIL
RIL is an XML document [7] that MUST be well-formed and MUST be valid
according to schemas, including extension schemas, available to the
validater and applicable to the XML document. The RIL documents MUST
be based on XML 1.0 and MUST be encoded using UTF-8. The namespace
identifier for elements defined by this specification is a URN [8],
using the namespace identifier 'ietf' defined by [9] and extended by
[10]. This urn is: urn:ietf:params:xml:ns:ril.
The MIME type for the RIL document is "application/ril+xml".
The root element of the RIL is <ril>. The <ril> element contains the
namespace definition mentioned above. The <ril> element contains at
most one <aspe> element and one <fspe> element and one <usril>
element.
The <aspe>, <fspe> and <usril> elements have meaning as ASPE, FSPE
and USRIL. Every element of the three have zero or more <set>
elements. The value of <set> is the elements defined in the PIDF
[1], RPID [2], and other specification defines presence elements.
The following example selects the <basic> element defined in the PIDF
[1]. This results in the selection of the <basic> element as well as
all the ancestors. I.e. <status> and <tuple>.
<set>/presence/tuple/status/basic</set>.
Wang & Xu Expires August 17, 2006 [Page 7]
Internet-Draft A Method of RIL February 2006
6. Node Behavior
6.1. Description of Notifier Behavior
RIL is conveyed as an independent message body in NOTIFY message.
Certainly, the NOTIFY message body may only contain RIL.
The RIL may be conveyed in the following scenarios:
1) Initial Subscription: The Notifier may contain RIL in the first
NOTIFY, just after the subscription is accepted.
2) Presence notification: The Notifier may convey RIL in the
NOTIFY delivered during subscription to provide the latest RIL
especially when the local policy for presence information
publication is changed.
3) Subscription refresh: The Notifier may also convey the latest
RIL in NOTIFY when the Subscriber refreshs the subscription if the
RIL is changed.
6.2. Description of Subscriber Behavior
RFC 3265 [3] describes the manner of obtaining presence information,
one is immediate fetch manner, another is persistent subscription
manner. Subscriber can obtain the currently RIL through any of them
if required.
Subscriber can directly get USRIL and FSPE from RIL in NOTIFY
message, and also can make use of intersection operation to obtain
FASPE by ASPE , FSPE and USRIL.
The rule to calculate FASPE is as follow:
1) If ASPE is NULL then FASPE is NULL.
2) If ASPE and FSPE is not NULL then FASPE equal ASPE not belong
FSPE part.
3) If ASPE and USRIL is not NULL then FASPE equal ASPE not belong
USRIL part.
4) If ASPE, FSPE and USRIL is not NULL then FASPE equal ASPE not
belong FSPE and USRIL part
Wang & Xu Expires August 17, 2006 [Page 8]
Internet-Draft A Method of RIL February 2006
7. Examples
If a notifier supports all the presence element, in the other words
RIL excludes USRIL, then RIL can be described by [4]. This example
assumes subscriber called Bob, notifier called Alice. Alice
supported all the presence information as follow:
urn:ietf:params:xml:ns:pidf,
urn:ietf:params:xml:ns:pidf:rpid
Bob is interested only in part of Alice's presence element such as:
status, contact, activities, mood, place-type
1) Bob send SUBSCRIBE message to Alice with "RIL" in Supported
header field.
Wang & Xu Expires August 17, 2006 [Page 9]
Internet-Draft A Method of RIL February 2006
SUBSCRIBE sip:Alice@example.com SIP/2.0
Via: SIP/2.0/TCP [6666::1:2:3:4]:5060;branch=z9hG4bKxjfdsjfk
To: <sip:Alice@example.com>
From: <sip:Bob@example.com>;tag=12341111
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Expires: 3600
Event: Presence
Supported: RIL
Contact: <sip: [6666::1:2:3:4]:5060>
Content-Type: application/simple-filter+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
</ns-bindings>
<filter id="123" uri="sip:Alice@example.com">
<what>
<include type="xpath">
/pidf:tuple/pidf:status
</include>
<include type="xpath">
/pidf:tuple/pidf:contact
</include>
<include type="xpath">
/pidf:tuple/rpid:activities
</include>
<include type="xpath">
/pidf:tuple/rpid:mood
</include>
<include type="xpath">
/pidf:tuple/rpid:place-type
</include>
</what>
</filter>
</filter-set>
2) Alice send back 200 OK to Bob, and include "RIL" in the Suppored
header field.
Wang & Xu Expires August 17, 2006 [Page 10]
Internet-Draft A Method of RIL February 2006
SIP/2.0 200 OK
Via: SIP/2.0/TCP [5555::1:2:3:4]:5060;branch=z9hG4bKxjfder
To: <sip:Bob@example.com>;tag=12341111
From: <sip:Alice@example.com>;tag=232321
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Supported: RIL
Contact: <sip:[5555::1:2:3:4]:5060>
Expires: 3600
Content-Length: 0
3) Alice's local policy only allows Bob to subscribe to the
following presence element: status, activities, status-icon, the
first NOTIFY the current presence state information and RIL.
NOTIFY sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TCP [5555::1:2:3:4]:5060;branch=z9hG4bKxjfder
To: <sip:Bob@example.com>;tag=12341111
From: <sip:Alice@example.com>;tag=232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Event: Presence
Subscription-State: active; expires=3599
Contact: <sip:[5555::1:2:3:4]:5060>
Content-Type: multipart/related;type="application/ril+xml";
start="<nXYxAE@example.com>";
boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: ...
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@example.com>
Content-Type: application/ril+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<ril xmlns="urn:ietf:params:xml:ns:ril"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid">
<aspe>
<set>
/pidf:tuple/pidf:status
</set>
<set>
/pidf:tuple/rpid:activities
</set>
</aspe>
Wang & Xu Expires August 17, 2006 [Page 11]
Internet-Draft A Method of RIL February 2006
<fspe>
<set>
/pidf:tuple/pidf:contact
</set>
<set>
/pidf:tuple/rpid:mood
</set>
<set>
/pidf:tuple/rpid:place-type
</set>
</fspe>
</ril>
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:ns:rpid-tuple"
entity="sip:Alice@example.com">
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:activities>lunch</rpid:activities>
</tuple>
</presence>
--50UBfW7LSCVLtggUPe5z
4) During the subscription, Alice wants to change the local policy,
the new local policy allows more presence information as follows
to be subscribed: status, activities, status-icon, contact, mood.
So Alice's user agent actively send a NOTIFY including the
updated RIL to Bob
NOTIFY sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TCP [5555::1:2:3:4]:5060;branch=z9hG4bKxjfder
To: <sip:Bob@example.com>;tag=12341111
From: <sip:Alice@example.com>;tag=232321
Call-ID: 32432udfidfjmk342
Cseq: 2 NOTIFY
Event: Presence
Wang & Xu Expires August 17, 2006 [Page 12]
Internet-Draft A Method of RIL February 2006
Subscription-State: active; expires=3512
Contact: <sip:[5555::1:2:3:4]:5060>
Content-Type: multipart/related;type="application/ril+xml";
start="<nXYxAE@example.com>";
boundary="50UBdsLtfghggUPe5z"
Content-Length: ...
--50UBdsLtfghggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@example.com>
Content-Type: application/ril+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<ril xmlns="urn:ietf:params:xml:ns:ril"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid">
<aspe>
<set>
/pidf:tuple/pidf:status
</set>
<set>
/pidf:tuple/rpid:activities
</set>
<set>
/pidf:tuple/pidf:contact
</set>
<set>
/pidf:tuple/rpid:mood
</set>
</aspe>
<fspe>
<set>
/pidf:tuple/rpid:place-type
</set>
</fspe>
</ril>
--50UBdsLtfghggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:ns:rpid-tuple"
entity="sip:Alice@example.com">
<tuple id="thr76jk">
Wang & Xu Expires August 17, 2006 [Page 13]
Internet-Draft A Method of RIL February 2006
<status>
<basic>open</basic>
</status>
<contact>sip:Alice@example.com</contact>
<rpid:activities>lunch</rpid:activities>
<rpid:mood>happy</rpid:mood>
</tuple>
</presence>
--50UBdsLtfghggUPe5z
5) When the updated RIL is received, Bob may want to refresh the
subscription to get more presence information which is allowed
now. He changes the element: status, activities, mood, deviceID,
status-icon, Alice's user agent acknowledges the subscription
refresh and then send a NOTIFY containing the current presence
information and also RIL to Bob now.
NOTIFY sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TCP [5555::1:2:3:4]:5060;branch=z9hG4bKxjfder
To: <sip:Bob@example.com>;tag=12341111
From: <sip:Alice@example.com>;tag=232321
Call-ID: 32432udfidfjmk342
Cseq: 3 NOTIFY
Event: Presence
Subscription-State: active; expires=3512
Contact: <sip:[5555::1:2:3:4]:5060>
Content-Type: multipart/related;type="application/ril+xml";
start="<nXYxAE@example.com>";
boundary="50UBdsLtfghggUPe5z"
Content-Length: ...
--rtdBdsLtfghasqPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@example.com>
Content-Type: application/ril+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<ril xmlns="urn:ietf:params:xml:ns:ril"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid">
<aspe>
<set>
/pidf:tuple/pidf:status
</set>
<set>
Wang & Xu Expires August 17, 2006 [Page 14]
Internet-Draft A Method of RIL February 2006
/pidf:tuple/rpid:activities
</set>
<set>
/pidf:tuple/rpid:mood
</set>
<set>
/pidf:tuple/pidf:status-icon
</set>
</aspe>
<fspe>
<set>
/pidf:tuple/rpid:deviceID
</set>
</fspe>
</ril>
--rtdBdsLtfghasqPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:ns:rpid-tuple"
entity="sip:Alice@example.com">
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<status-icon>http://example.com/open.ico</status-icon>
<rpid:activities>lunch</rpid:activities>
<rpid:mood>happy</rpid:mood>
</tuple>
</presence>
--rtdBdsLtfghasqPe5z
Wang & Xu Expires August 17, 2006 [Page 15]
Internet-Draft A Method of RIL February 2006
8. Security Considerations
It is important to user that include RIL in NOTIFY message body. As
a result, it is especially important that messages containing this
extension be authenticated and authorized. Authentication can be
achieved using the Digest Authentication mechanism described in RFC
3261 [5]. The authorization decision is made based on the
permissions that the resource (notifier) has given to the watcher.
An example of such authorization policy can be found in [6].
The RIL may concerns by revealing sensitive policy information, that
the notifier may not want to provide to subscriber. This
specification only provide a way to transfer RIL, whether providing
this information may according to the notifyer's policy. The
notifier can follow the negotiation mechanism in this specification
to decide to privide RIL or not.
Wang & Xu Expires August 17, 2006 [Page 16]
Internet-Draft A Method of RIL February 2006
9. XML Schema for RIL
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:ril"
xmlns="urn:ietf:params:xml:ns:ril"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition for SIP RIL.
</xs:documentation>
</xs:annotation>
<xs:element name="ril" type="RILType"/>
<xs:complexType name="RILType">
<xs:sequence>
<xs:element name="aspe" type="ASPEType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="fspe" type="FSPEType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="usril" type="USRILType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ASPEType">
<xs:sequence>
<xs:element name="set" type="SETType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FSPEType">
<xs:sequence>
<xs:element name="set" type="SETType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Wang & Xu Expires August 17, 2006 [Page 17]
Internet-Draft A Method of RIL February 2006
<xs:complexType name="USRILType">
<xs:sequence>
<xs:element name="set" type="SETType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SETType">
<xs:simpleContent>
<xs:extension base="xs:string"/>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Wang & Xu Expires August 17, 2006 [Page 18]
Internet-Draft A Method of RIL February 2006
10. IANA Considerations
10.1. New SIP Option Tag: RIL
This section defines a new option tag for the registry established by
section 27.1 of RFC3261 [5].
Option Tag Name: RIL
Description: Resource Information List.
Published specification: RFC xxxx [[Note to RFC editor: replace xxxx
with the RFC number of this document when published]]
10.2. New MIME type for RIL
MIME Media Type Name: application
MIME subtype name: ril+xml
Required parameters: None
Optional parameters: charset
See RFC3023 [11] for a discussion of the charset parameter on XML-
derived MIME types. Since this MIME type is used exclusively in SIP,
the use of UTF-8 encoding is strongly encouraged.
Encoding considerations: 8-bit text
Security considerations: Security considerations specific to uses of
this this MIME type are discussed in RFC xxxx [[Note to RFC editor:
replace xxxx with the RFC number of this document when published]].
RFC1874 [12] and RFC3023 [11] discuss security issues common to all
uses of XML.
10.3. URN Sub-Namespace
URI: urn:ietf:params:xml:ns:ril
Description: This is the XML namespace URI for XML elements defined
by [RFCXXXX] to describe information about refreshing many
subscriptions by a message. It is used in the application/ril+xml
body type.
Registrant Contact:
Name: Xiao Wang
Wang & Xu Expires August 17, 2006 [Page 19]
Internet-Draft A Method of RIL February 2006
E-Mail: wangsmile@huawei.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=utf-8"/>
<title>Namespace for SIP RIL</title>
</head>
<body>
<h1>Namespace for SIP RIL</h1>
<h2>application/ril+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">
RFCXXXX</a>.</p>
</body>
</html>
END
Wang & Xu Expires August 17, 2006 [Page 20]
Internet-Draft A Method of RIL February 2006
11. Change control
11.1. Changes from draft-wang-simple-presence-ril-00.txt
Add negotiation mechanism of RIL.
Add definition of RIL. RIL is an XML document and the MIME type for
the RIL document is "application/ril+xml".
Add description of security consideration.
12. Normative References
[1] Sugano, H., "Presence Information Data Format", RFC 3863,
Auguest 2004.
[2] Schulzrinne, H., "RPID -- Rich Presence Information Data
Format", Draft draft-ietf-simple-rpid-08, Auguest 2004.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] Khartabil, H., "An Extensible Markup Language (XML) Based
Format for Event Notification Filtering",
Draft draft-ietf-simple-filter-format-05, February 2005.
[5] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[6] Rosenberg, J., "Presence Authorization Rules",
Draft draft-ietf-simple-presence-rules-03, February 2005.
[7] Bray, T., "Exensible Markup Language (XML) 1.0 (Second
Edition)", W3C CR CR-xml11-20011006, October 2000.
[8] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[9] Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
August 1999.
[10] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[11] Murata, M., Laurent, St., and S. Kohn, "XML Media Types",
RFC 3023, January 2001.
[12] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
Wang & Xu Expires August 17, 2006 [Page 21]
Internet-Draft A Method of RIL February 2006
Authors' Addresses
Xiao Wang
Huawei Technologies
Bantian
Shenzhen, Longgang 518129
China
Phone: +86 755 28788996
Email: wangsmile@huawei.com
Peili Xu
Huawei Technologies
Bantian
Shenzhen, Longgang 518129
China
Phone: +86 755 28780808
Email: xupeili@huawei.com
Wang & Xu Expires August 17, 2006 [Page 22]
Internet-Draft A Method of RIL February 2006
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.
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wang & Xu Expires August 17, 2006 [Page 23]
