One document matched: draft-hiller-uri-list-index-01.txt
Differences from draft-hiller-uri-list-index-00.txt
AAA Working Group Tom Hiller
Internet Draft Lucent Technologies
draft-hiller-uri-list-index-01.com Adam Roach
Category: Standards Track Dean Willis
dynamicsoft
July 2004
SIP URI List Index
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This draft extends the schema of the resource list specified in
draft-ietf-simple-xcap-list-usage-01 by defining an index attribute
(membercode). It also defines two MIME types that refer to subsets
of a resource list. These MIME types can be used to identify subsets
of a resource list for use with SIP requests.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
Table of Contents
1. Problem Statement................................................2
2. General Solution.................................................3
2.1. Summary......................................................3
2.2. Membercode Attribute Management..............................3
2.3. MIME Types...................................................3
Hiller et al Standards Track - December 2004 1
URI List Index February 2004
3. Definition of Membercode Attribute for Resource List.............4
4. IANA Considerations..............................................5
4.1. Index List...................................................5
4.2. Bit Map MIME.................................................6
5. Security Considerations..........................................8
6. References.......................................................8
6.1. Normative....................................................8
7. Acknowledgements.................................................9
8. Authors' Addresses...............................................9
1. Problem Statement
The SIPPING WG is developing mechanisms to by which a SIP request can
target a list of recipient URIs (a URI-list). These URI-lists may be
transported either within the associated request (a request-contained
list) or stored externally and referenced by the request [URI-LIST]
[LIST-CONF]. This specification extends the second case by allowing a
request to reference a subset of the URIs contained in a referenced
URI-list. This is achieved my extending the schema of the URI-list so
that each list element is associated with a locally-unique index
value, and extending the referencing syntax to allow a request to
carry a list reference and a set of index values indicating elements
to be selected from the referenced list.
For wireless, this avoids the need for a mobile to have to send a SIP
request multiple times over the air, thereby conserving spectrum and
extending battery lifetime, both of which are valuable goals in
wireless. The 3G wireless technology cdma2000 has various transport
mechanisms, some of which only support rather low data rates. The
cdma2000 mechanism "1X-RTT", has an effective payload data rate of
8500bps after various physical overhead are deducted from the
absolute physical bit rate. So, for 1X-RTT, a kilobyte long SIP
request causes one second of over-the-air transport latency, which is
a problem for some services, such as push-to-talk conferencing that
have tight latency requirements.
Yet another cdma2000 transport mechanism called "short data burst",
has severe message length restrictions; for example based on radio
engineering considerations, the PPP frames should be under 100 bytes
total including PPP overhead. This mechanism also features low data
rates as the 1X-RTT mechanism mentioned above.
For these cdma2000 transport mechanisms, it is highly desirable to
minimize the length of SIP requests especially for those destinations
that are contacted frequently. Based on this, it is desirable to
minimize the number of bytes required to transport the URI-lists in
the SIP requests, and therefore to define a highly compact means to
convey a URI List in SIP Request bodies. This draft proposes an
index to elements of the resource list schema [RF]. The index
results in shorter SIP requests for SIP applications that require
Hiller Standards Track - Expires June 2004 2
URI List Index February 2004
transport over lower data rate and/or message length restricted
cdma2000 transport mechanisms.
2. General Solution
2.1. Summary
This draft adds an attribute called "membercode" to elements of the
resource list schema of [RL] and defines two MIME [MIME-1] types to
convey (represent) a URI List [URI-LIST] [LIST-CONF] in the body of a
SIP request. The MIME types are based on the identity of the user's
resource list along with indices (the membercodes) that have been
previously stored in a user's resource list. Both MIME types require
that the server hosting the list assign membercodes to all URIs of
the user's Resource List entries. The MIME type conveys identity of
the resource list and the membercodes associated with the URIs on a
URI List. The MIME instance replaces the actual URI elements,
thereby saving many bytes and reducing over-the-air transport
latency.
The membercode is a non-negative integer that is unique within a
given resource list. The maximum value (size) of the membercode
should be on the order of the number of lists and list entries of the
resource list.
2.2. Membercode Attribute Management
The document draft-ietf-simple-xcap-list-usage-01 [RL] states the
requirements on XCAP for a client to manipulate the resource list.
An XCAP client does not include the membercode attribute when it
creates or modifies a resource list element, as the membercode is
optional. Instead the server creates a unique membercode when the
resource is created. The server leaves the membercode unchanged when
a list or list element is modified. The addition of an index to the
resource list is transparent to XCAP. Having the presence list
server assigns membercodes to resource list elements avoids conflicts
and/or race conditions that could arise due to multiple users
creating or modifying resource list elements.
Users of the resource list may subscribe for updates to receive
presence notifications [RL-NOTIFY] that carry the assigned
membercodes. Also, users may access the resource list directly via
XCAP to learn the membercode attributes created. Otherwise, a means
to synchronize the membercodes in user devices must be provided by
means outside the scope of this document.
In order for a users learn the values of membercode attributes via
presence notifications [RL-NOTIFY] the user has to subscribe for
notifications and the resource list's "subscribe" flag MUST be set).
2.3. MIME Types
Hiller Standards Track - Expires June 2004 3
URI List Index February 2004
The first MIME, application/resource-lists-indices, is a list of the
membercodes of the elements of a URI list.
The second MIME, application/resource-lists-bitmap, is a bit map of
the membercodes of the elements of the URI list. In the latter case,
a bit set at location 'x' in the bit map corresponds to a membercode
of value '2**x".
MIME bodies may be further compressed with procedures that are part
of a general SIGCOMP [SIGCOMP] "program".
3. Definition of Membercode Attribute for Resource List
As explained above, this draft adds an attribute called "membercode"
to elements of the resource list schema of [RL]. , The resulting
schema is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists"
xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand"
xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:xcap-must-
understand"/>
<xs:element name="resource-lists">
<xs:complexType>
<xs:sequence>
<xs:element ref="xcap:mandatory-ns" minOccurs="0"/>
<xs:element name="list" type="listType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="listType">
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="list" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension base="listType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="external" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="entry" type="entryType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="entry-ref" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
Hiller Standards Track - Expires June 2004 4
URI List Index February 2004
</xs:choice>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/>
<xs:attribute name="uri" type="xs:anyURI" use="optional"/>
<xs:attribute name="subscribeable" type="xs:boolean"
use="optional"/>
<xs:anyAttribute namespace="##other"/>
<xs: attribute name="membercode"
type="unique positiveInteger" use="optional" />
</xs:complexType>
<xs:complexType name="entryType">
<xs:sequence>
<xs:element name="display-name" type="display-nameType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs: attribute name="membercode"
type="unique positiveInteger" use="optional" />
</xs:complexType>
<xs:simpleType name="display-nameType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:schema>
4. IANA Considerations
The document draft-camarillo-uri-list-00.txt defines a "list"
parameter for SIP and SIPS URIs that points to an XCAP resource list.
This document defines two MIME types to which the list parameter may
point and is consistent with [MIME-2] and [MIME-4].
4.1. Index List
The MIME Content-Type is "application/resource-lists-indices" and is
a list of membercodes separated by white space. The presence of an
membercode in the list means that the associated URI is to be
included on the URI list. The MIME type includes the resource list
URI.
The URI and membercode are encoded as is encoded in UTF-8. The
membercode attributes, which are numbers, are coded as hex digits.
The URI and member codes are separated by a white space. The exact
efficiency of the encoding of membercodes is less important because a
SIGCOMP program can compress these digits, which are represented as
characters, to binary numbers.
The ABNF [ABNF] for this MIME type is as follows.
resource-lists-indices = (resource-list-URI SP *(membercode SP))
Hiller Standards Track - Expires June 2004 5
URI List Index February 2004
resource-list-URI = SIP-URI
; this is an SIP URI to the resource list
; see [SIP]
membercode = *HEXDIG
; the member code is on the list if the
; associated URI is on the URI list
Information per [MIME-4] is as follows:
MIME media type name: application
MIME subtype name: resource-lists-indices
Mandatory parameters: none
Optional parameters: none
Encoding considerations: UTF-8
Security considerations: See the security section of this
specification
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: SIP Requests with an
EXPLODE method based URI list.
Additional Information:
Magic Number: None
File Extension: tbd
Macintosh file type code: tbd
Personal and email address for further information: Tom Hiller,
tomhiller@lucent.com
Intended usage: COMMON
Author/Change controller: The IETF
4.2. Bit Map MIME
The MIME Content-Type is an "application/resource-lists-bitmap", and
is a binary string whose individual bit positions correspond to the
values of membercodes. A bit set in the bit map means the URI
Hiller Standards Track - Expires June 2004 6
URI List Index February 2004
associated with the membercode whose value matches that bit position
is on the URI list. The MIME type includes the resource list URI.
If the bit map has fewer bits than the maximum value of the
membercode, then URIs corresponding to "missing" bit positions are
not included in the URI list. If the bit map has bit positions that
do not correspond to membercodes or more bits than the maximum value
possible of the membercode, then the "extra" bits MUST be ignored.
The URI and bitmap are encoded as is encoded in UTF-8. The bit flags
of the membercode are coded as four bits to a hex digit. Any bits in
hex digit for which membercodes do not exist are set to zero, which
occurs if the number of bits in the bit map isn't a multiple of four.
The bit map positions correspond to the power of two in the resulting
hex number. Therefore, in string of hex digits, the most significant
bit of the most significant hex digit represents the highest value
membercode of the resource list.
The bit map MIME type's ABNF is as follows:
resource-lists-bitmap = (resource-list-URI *membercode-hex)
resource-list-URI = SIP-URI
; this is a SIP URI to the resource list
; see [SIP]
membercode-hex = HEXDIG
; a bit position M of the membercode-hex N
; is set if a URI on the URI list
; has a membercode of value 2**(4*N+M)
; where N starts at 1 (so the first character
; is M=1) and M is value of 2**M in the hex
; character (so the least bit is 2**0).
Information per [MIME-4] is as follows:
MIME media type name: application
MIME subtype name: resource-lists-bitmap
Mandatory parameters: none
Optional parameters: none
Encoding considerations: UTF-8
Security considerations: See the security section of this
specification
Interoperability considerations: none.
Published specification: This document.
Hiller Standards Track - Expires June 2004 7
URI List Index February 2004
Applications which use this media type: SIP Requests with an
EXPLODE method based URI list.
Additional Information:
Magic Number: None
File Extension: tbd
Macintosh file type code: tbd
Personal and email address for further information: Tom Hiller,
tomhiller@lucent.com
Intended usage: COMMON
Author/Change controller: The IETF
5. Security Considerations
The index proposed herein is a way to access a user on the resource
list, which is used to invite people to calls, etc. However, the
security of the index is no more nor less important than any other
data already contained on the list, and therefore, this document does
not imply additional security concerns or considerations.
6. References
6.1. Normative
[ABNF] Crocker, "Augmented BNF for Syntax Specifications:
ABNF", RFC2234, November 1997
[LIST-CONF] Conference Establishment Using Request-Contained Lists
in the Session Initiation Protocol (SIP),
draft-ietf-sipping-uri-list-conferencing-00.txt,
July 7, 2004
[IANA] Narten, Alvestrand, "Guidelines for Writing an IANA C
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998
[MIME-1] Freed, Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet
Message Bodies, RFC2045, November 1996
[MIME-2] Freed, Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types"
RFC2046, November 1996
[MIME-4] Freed et al, "Multipurpose Internet Mail
Hiller Standards Track - Expires June 2004 8
URI List Index February 2004
Extensions (MIME) Part Four: Registration
Procedures", RFC2048, November 1996
[RL] Rosenberg, "draft-ietf-simple-xcap-list-usage-02",
October 27, 2003
[RL-NOTIFY] Roach, Rosenberg, Campbell, A Session Initiation
Protocol (SIP) Event Notification Extension for
Resource Lists, draft-ietf-simple-event-list-04,
June 13, 2003
[SIGCOMP] Price et al, Signaling Compression (SigComp), RFC3320,
January 2003
[SIP] Rosenberg et al, "The Session Initiation Protocol",
RFC3261, June 2002
[URI-LIST] Camarillo, Roach, Providing a Session Initiation
Protocol (SIP) Application Server with a List of URIs,
draft-camarillo-uri-list-02.txt, March 27, 2004
7. Acknowledgements
Chris Bennet of Togabi suggested the use of the MIME type that
conveys a list of indices.
8. Authors' Addresses
Questions about this memo can be directed to:
Tom Hiller
Lucent Technologies
1960 Lucent Lane
Naperville, IL 60566
USA
Phone: +1 630-979-7673
E-mail: tomhiller@lucent.com
Dean Willis
dynamicsoft Inc.
5100 Tennyson Parkway
Suite 1200
Plano, TX 75028
US
Phone: +1 972 473 5455
E-mail: dean.willis@softarmor.com
URI: http://www.dynamicsoft.com/
Adam Roach
dynamicsoft
Hiller Standards Track - Expires June 2004 9
URI List Index February 2004
5100 Tennyson Pkwy
Suite 1200
Plano, TX 75024
USA
E-mail: adam@dynamicsoft.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
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 practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
Hiller Standards Track - Expires June 2004 10
URI List Index February 2004
TASK FORCE DISCLAIMS 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.
Hiller Standards Track - Expires June 2004 11 | PAFTECH AB 2003-2026 | 2026-04-22 23:26:29 |