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: Hiller Standards Track - Expires June 2004 4 URI List Index February 2004 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