AAA Working Group Tom Hiller
Internet Draft Lucent Technologies
draft-hiller-uri-list-index-00.txt Adam Roach
Category: Standards Track Dean Willis
dynamicsoft
March 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.................................................2
2.1. Summary......................................................2
2.2. Membercode Attribute Management..............................3
2.3. MIME Types...................................................3
Hiller et al Standards Track - October 2004 1
URI List Index February 2004
3. Definition of Membercode Attribute for Resource List.............3
4. IANA Considerations..............................................5
4.1. Index List...................................................5
4.2. Bit Map MIME.................................................6
5. Security Considerations..........................................7
6. References.......................................................8
6.1. Normative....................................................8
7. Acknowledgements.................................................8
8. Authors' Addresses...............................................9
1. Problem Statement
Some 3G wireless physical layers are extremely lightweight to the
point of being fragile. For example, cdma2000 has a mechanism called
"short data burst" that provides a low latency IP over PPP access for
mobile stations, albeit it does so with severe message length
limitations. In the case of cdma2000, "low latency" means on the
order tens of milliseconds, and "severe" means less than a hundred
bytes including PPP. The length limitation arises on the basis of
radio engineering considerations. In addition to the length
limitations, the absolute amount of bandwidth over such physical
channels is highly limited. Constraints such as these represent non-
trivial problems for the transport of SIP requests such as the
INVITE. Despite these physical layer mechanisms being so
lightweight, various service providers would like to use them if at
all possible to transport SIP requests.
IP header compression and SIGCOMP compression provide help reducing
the number of bytes in a SIP request that need to be transported.
The EXPLODE method [EXPLODE] provides help reducing the number of SIP
requests that need to be transported. However, even with all of this
help, there is still yet another problem to overcome: The EXLPODE
method's SIP URI List [URI-LIST] is, in fact, an arbitrary length
list of arbitrary URI elements, and therefore, may be too lengthy for
highly constrained physical layers, such as the cdma2000 short data
burst.
Based on the foregoing, it would be helpful to have a highly compact
means to convey a URI List in SIP request bodies.
2. General Solution
2.1. Summary
This draft adds an attribute called "membercode" to elements of the
resource list schema of [RF] and defines two MIME [MIME-1] types to
convey (represent) a URI List [URI-LIST] 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
Hiller Standards Track - Expires June 2004 2
URI List Index February 2004
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.
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
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
Hiller Standards Track - Expires June 2004 3
URI List Index February 2004
As explained above, this draft adds an attribute called "membercode"
to elements of the resource list schema of [RF]. , The resulting
schema is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns>
<xs:complexType>
<xs:sequence>
<xs:element name="list" type="listType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<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:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<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"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="uri" type="xs:anyURI" use="optional"/>
<xs: attribute name="membercode"
type="unique positiveInteger" use="optional" />
</xs:complexType>
<xs:simpleType name="display-nameType">
Hiller Standards Track - Expires June 2004 4
URI List Index February 2004
<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))
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
Hiller Standards Track - Expires June 2004 5
URI List Index February 2004
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
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]
Hiller Standards Track - Expires June 2004 6
URI List Index February 2004
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.
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
Hiller Standards Track - Expires June 2004 7
URI List Index February 2004
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
[EXPLODE] Camarillo, Session Initiation Protocol (SIP)
Exploder Invocation, draft-camarillo-sipping-
exploders-solution-00.txt, November 22, 2003
[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
Extensions (MIME) Part Four: Registration
Procedures", RFC2048, November 1996
[RL] Rosenberg, "draft-ietf-simple-xcap-list-usage-01",
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,
November 22, 2003
7. Acknowledgements
Hiller Standards Track - Expires June 2004 8
URI List Index February 2004
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
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.
Hiller Standards Track - Expires June 2004 9
URI List Index February 2004
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
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 10