RFC 4826

Extensible Markup Language (XML) Formats for Representing Resource Lists

📅 published May 2007, from ietf

🎀 RFC 4826: Extensible Markup Language (XML) Formats for Representing Resource Lists ✨

Okay bestie, let's get into it 💖 This one is from the Network Working Group and was written by J. Rosenberg at Cisco 🦋. It's a Standards Track doc, so it's the real deal, not just vibes. It came out in May 2007 🌸.

Nothing in the title block says it obsoletes or updates anything, so this one is standing on its own 💅

Here's the lowkey mission: the doc defines two XML formats for resource lists. One is a list of users or resources you can reuse anywhere. The other ties a service URI to a list, like presence or conferencing. And yes, XCAP is involved too 🧚

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Copyright (C) The IETF Trust (2007) 🎀

Abstract 🦋

So in multimedia communications, presence, and instant messaging systems, we need URIs that stand for services tied to a group of users 😭 A resource list service is the classic example. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to that URI, the server grabs the state of everyone in the group and sends it back to the sender 💅

This spec defines two Extensible Markup Language (XML) documents 🧚 The first one holds service URIs, their service definition, and a reference to the group. The second one holds the user lists that the first one points to 🌸 Other apps and services can use that list too, which is iconic 👑 Both docs can be created and managed with the XML Configuration Access Protocol (XCAP) ✨

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Resource Lists Documents . . . . . . . . . . . . . . . . . . .  4
  3.1.  Structure  . . . . . . . . . . . . . . . . . . . . . . . .  4
  3.2.  Schema . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  3.3.  Example Document . . . . . . . . . . . . . . . . . . . . .  9
  3.4.  Usage with XCAP  . . . . . . . . . . . . . . . . . . . . . 10
    3.4.1.  Application Unique ID  . . . . . . . . . . . . . . . . 10
    3.4.2.  MIME Type  . . . . . . . . . . . . . . . . . . . . . . 10
    3.4.3.  XML Schema . . . . . . . . . . . . . . . . . . . . . . 10
    3.4.4.  Default Namespace  . . . . . . . . . . . . . . . . . . 10
    3.4.5.  Additional Constraints . . . . . . . . . . . . . . . . 11
    3.4.6.  Data Semantics . . . . . . . . . . . . . . . . . . . . 11
    3.4.7.  Naming Conventions . . . . . . . . . . . . . . . . . . 11
    3.4.8.  Resource Interdependencies . . . . . . . . . . . . . . 12
    3.4.9.  Authorization Policies . . . . . . . . . . . . . . . . 12
4.  RLS Services Documents . . . . . . . . . . . . . . . . . . . . 13
  4.1.  Structure  . . . . . . . . . . . . . . . . . . . . . . . . 13
  4.2.  Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  4.3.  Example Document . . . . . . . . . . . . . . . . . . . . . 15
  4.4.  Usage with XCAP  . . . . . . . . . . . . . . . . . . . . . 16
    4.4.1.  Application Unique ID  . . . . . . . . . . . . . . . . 16
    4.4.2.  MIME Type  . . . . . . . . . . . . . . . . . . . . . . 16
    4.4.3.  XML Schema . . . . . . . . . . . . . . . . . . . . . . 16
    4.4.4.  Default Namespace  . . . . . . . . . . . . . . . . . . 16
    4.4.5.  Additional Constraints . . . . . . . . . . . . . . . . 16
    4.4.6.  Data Semantics . . . . . . . . . . . . . . . . . . . . 17
    4.4.7.  Naming Conventions . . . . . . . . . . . . . . . . . . 17
    4.4.8.  Resource Interdependencies . . . . . . . . . . . . . . 18
    4.4.9.  Authorization Policies . . . . . . . . . . . . . . . . 20
  4.5.  Usage of an RLS Services Document by an RLS  . . . . . . . 20
5.  SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 22
6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 23
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
  8.1.  XCAP Application Unique IDs  . . . . . . . . . . . . . . . 24
    8.1.1.  resource-lists . . . . . . . . . . . . . . . . . . . . 24
    8.1.2.  rls-services . . . . . . . . . . . . . . . . . . . . . 24
  8.2.  MIME Type Registrations  . . . . . . . . . . . . . . . . . 25
    8.2.1.  application/resource-lists+xml . . . . . . . . . . . . 25
    8.2.2.  application/rls-services+xml . . . . . . . . . . . . . 26
  8.3.  URN Sub-Namespace Registrations  . . . . . . . . . . . . . 27
    8.3.1.  urn:ietf:params:xml:ns:resource-lists  . . . . . . . . 27
    8.3.2.  urn:ietf:params:xml:ns:rls-services  . . . . . . . . . 28
  8.4.  Schema Registrations . . . . . . . . . . . . . . . . . . . 28
    8.4.1.  urn:ietf:params:xml:schema:resource-lists  . . . . . . 28
    8.4.2.  urn:ietf:params:xml:schema:rls-services  . . . . . . . 29
9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
  10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
  10.2. Informative References . . . . . . . . . . . . . . . . . . 30

1. Introduction 🌷

Okay so, the Session Initiation Protocol (SIP) [4] defines a SIP URI as any resource a SIP request can be generated for, to set up some kind of communications operation 💖 These can be users, like sip:joe@example.com 🦋 A SIP URI can also be a service, like voicemail, conferencing, or a presence list ✨ The pattern is always the same: the service is defined and linked to a URI. To actually do anything, the service needs a list of users (or resources, more generally) 🧚 When a SIP request hits the service URI, the server reads that list and does some kind of operation on each resource 💅 Here's the picture 👇

                                 /---\
                                |     |
                                 \---/ Resource
                           +----|     |  List
                           |    |     |
                           |     \---/
                           |
                           |
                           |
                           |
                           V
                    +-------------+
                    |             | -------->
                    |    SIP      |
   ---------------> |  Service    | -------->
           service |             |
           URI     |             | -------->
                    +-------------+

                              Figure 1

One big example is a presence [11] list service 🌈 A client sends a SIP SUBSCRIBE request to ask for presence info on a list of users, and the presence list server gets that presence and sends it back 💜 A presence list server is a special kind of resource list server (RLS) [14], which lets a client send a SIP SUBSCRIBE to ask for notifications of SIP events for a list of resources 🫶

Another example is an instant conference service 🎀 If a client sends a SIP INVITE to that URI, the conference server makes a conference call with the client and the group 👑

Here's the big idea: it's super useful to define groups of users or resources (usually called a resource list) separately from the services that use them 😭 There are even uses for resource lists with no network service at all 💅 For example, instead of using a presence list service, a client could send individual SUBSCRIBE requests to get the presence of each user on a locally stored presence list 🧚 In that case, you need a format for saving the list on disk 🌸 And if the user wants to share it and email it to friends, that also needs a standard resource list format ✨

So this document defines two Extensible Markup Language (XML) document formats 🦋 The first represents resource lists, independent of any particular service 💖 The second defines service URIs for an RLS and links a resource list to the service URI 🌷 This doc also defines an XML Configuration Access Protocol (XCAP) [10] application usage for managing both documents 🫶

2. Terminology 🍓

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 [1] and indicate requirement levels for compliant implementations 💅 (Yes, these are the official requirement words, so they're capitalized on purpose 🔥)

3. Resource Lists Documents ✨

Part 1 of 6. The rest of Section 3 and everything after it is coming next, so stay tuned, bestie 🧚💜

3.1. Structure 💅

okay so a resource lists document is an XML [2] doc, and it MUST be well-formed 🎀 and it MUST be valid against every schema that applies to it, extension schemas included, as long as the validater can reach them. resource lists docs MUST be based on XML 1.0 and MUST be encoded in UTF-8 💖. this spec uses XML namespaces to identify resource lists docs and doc fragments. the namespace URI for elements defined here is a URN [3] built on the 'ietf' namespace identifier from RFC 2648 [6], which got extended by RFC 3688 [8]. the URN is:

urn:ietf:params:xml:ns:resource-lists

the root element is <resource-lists> 👑, and it has no attributes. its content is a sequence of zero or more <list> elements, and each one defines a single resource list 🦋.

every <list> element can have an optional "name" attribute, which is basically its handle 🏷️. when it's there, it MUST be unique among all the other <list> elements inside the same parent. a <list> can also carry attributes from other namespaces, just for extensibility.

so a <list> is made of an optional display name, then a sequence of zero or more elements (each one an <entry>, a <list>, an <entry-ref>, or an <external>), then any number of elements from other namespaces, again for extensibility. since a list can hold other lists, a resource list can be hierarchical 🌳, and <display-name> gives each level of that hierarchy a human-friendly name ✨. an <entry> is one resource, identified by a URI. an <entry-ref> pulls in an entry from a doc inside the same XCAP root by reference instead of copying it by value. an <external> is a reference to a list that lives on this server or on a different one 🌸.

the <entry> element describes one resource and has a single mandatory attribute, "uri" 🔗. that attribute equals the URI used to access the resource. the list format doesn't restrict which URI types you can use, but the service consuming the list might need specific URI schemes. for example, RLS services need URIs that represent subscribeable resources, which includes SIP and pres [15] URIs. the "uri" attribute MUST be unique among all the other "uri" attributes in <entry> elements under the same parent. uniqueness is checked with case-sensitive string comparisons 🙈. that means two "uri" values could count as the same URI under the functional equality rules for that scheme, and still count as different under case-sensitive comparison. an <entry> can also carry attributes from other namespaces, for extensibility.

an <entry> holds a sequence of elements that describe it. right now, only one is defined: <display-name> 💬. it's a UTF-8 encoded string meant for humans to read. unlike the "name" attribute on <list>, the <display-name> has no uniqueness requirement at all. it can take the "xml:lang" attribute, which says what language the display name is in. an <entry> can also contain elements from other namespaces, which is how you'd add extra info like a phone number or a postal address 📱.

the <entry-ref> element lets an entry show up in a list by reference instead of by value 🧚. this only means something when the document came through XCAP 💜. in that case, the referenced entry has to exist inside the same XCAP root. the <entry> element has a single mandatory attribute, "ref". the "ref" attribute MUST be unique among all the other "ref" attributes in <entry-ref> elements under the same parent. uniqueness is checked with case-sensitive string comparisons. the <entry-ref> element can also take attributes from other namespaces, for extensibility. its content is an optional display name, followed by any number of elements from other namespaces, for extensibility too. the display name is handy for a localized nickname that stands in for the name defined in the <entry> the <entry-ref> points to 🍓.

the content of the "ref" attribute is a relative HTTP URI [7] 🌈. specifically, it MUST be a relative path reference, where the base URI equals the XCAP root URI of the document the <entry-ref> lives in. this relative URI, once it's resolved into an absolute URI using the procedures in RFC 3986, MUST resolve to an <entry> element inside a resource-lists document. here's an example. say an <entry> element inside a specific XCAP root is identified by this HTTP URI:

http://xcap.example.com/resource-lists/users/sip:bill@example.com/
index/~~/resource-lists/list%5b@name=%22list1%22%5d/
entry%5b@uri=%22sip:petri@example.com%22%5d

if http://xcap.example.com is the XCAP root URI, then an <entry-ref> pointing at that entry would look like this:

<entry-ref ref="resource-lists/users/sip:bill@example.com/
index/~~/resource-lists/list%5b@name=%22list1%22%5d/
entry%5b@uri=%22sip:petri@example.com%22%5d"/>

quick heads-up: the line breaks in the HTTP URI and the XML attribute above are only there so they're easier to read 📖. also, as RFC 3986 explains, the relative path URI does not start with "/". since the relative URI in the "ref" attribute has to be a relative path URI, a "/" will never be the first character of a "ref" attribute's content. and because the content of "ref" is a valid HTTP URI, it has to be percent-encoded inside the XML document 🫶.

the <external> element is kind of like <entry-ref> 🦋. just like <entry-ref>, it only means something in documents pulled from an XCAP server. it's also a reference to content stored somewhere else. the difference is that it points at an entire list, and that list is allowed to live on another server 🌍. the <external> element has a single mandatory attribute, "anchor", which names the external list using an absolute HTTP URI. the "anchor" attribute MUST be unique among all the other "anchor" attributes in <external> elements under the same parent. uniqueness is checked with case-sensitive string comparisons. an <external> can also carry attributes from other namespaces, for extensibility. its content is an optional <display-name>, followed by any number of elements from another namespace, for extensibility. the value of the "anchor" attribute MUST be an absolute HTTP URI. this URI MUST identify an XCAP resource, and specifically, it MUST represent a <list> element inside a resource lists document. the URI MUST be percent-encoded 🔐.

for both <entry-ref> and <external>, the job of resolving those references belongs to whatever entity is using the document 🧠. when the doc is used with XCAP, that means the XCAP client has to do it. if the XCAP client is a PC app using the resource-lists document as a presence list, the references would probably get resolved when the user explicitly asks for it. they can also get resolved at any other time, obviously 💅. if the XCAP client is an RLS itself, the references get resolved when the RLS receives a SUBSCRIBE request for an RLS service tied to a resource list that contains one of these references (more on that below ⭐). an XCAP server defined by this spec will not try to resolve the references before handing the document back to the client. and if the references can't be resolved because of network errors or some other problem, the handling depends on how the document is being used. for resource lists used by RLS services, that's covered below 🙈.

3.2. Schema ✨

<?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:resource-lists"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
 schemaLocation="http://www.w3.org/2001/xml.xsd"/>
  <xs:complexType name="listType">
   <xs:sequence>
    <xs:element name="display-name" type="display-nameType"
     minOccurs="0"/>
    <xs:sequence minOccurs="0" maxOccurs="unbounded">
     <xs:choice>
      <xs:element name="list">
       <xs:complexType>
        <xs:complexContent>
         <xs:extension base="listType"/>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
      <xs:element name="external" type="externalType"/>
      <xs:element name="entry" type="entryType"/>
      <xs:element name="entry-ref" type="entry-refType"/>
     </xs:choice>
    </xs:sequence>
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
     maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:attribute name="name" type="xs:string" use="optional"/>
   <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:complexType name="entryType">
   <xs:sequence>
    <xs:element name="display-name" minOccurs="0">
     <xs:complexType>
      <xs:simpleContent>
       <xs:extension base="display-nameType"/>
      </xs:simpleContent>
     </xs:complexType>
    </xs:element>
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
     maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:attribute name="uri" type="xs:anyURI" use="required"/>
   <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:complexType name="entry-refType">
   <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="ref" type="xs:anyURI" use="required"/>
   <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:complexType name="externalType">
   <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="anchor" type="xs:anyURI"/>
   <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="resource-lists">
   <xs:complexType>
    <xs:sequence minOccurs="0" maxOccurs="unbounded">
     <xs:element name="list" type="listType"/>
    </xs:sequence>
   </xs:complexType>
  </xs:element>
  <xs:complexType name="display-nameType">
   <xs:simpleContent>
    <xs:extension base="xs:string">
     <xs:attribute ref="xml:lang"/>
    </xs:extension>
   </xs:simpleContent>
  </xs:complexType>
</xs:schema>

3.3. Example Document

okay so here's an example doc that's fully compliant with the schema 💅 (heads up: the line feeds inside the element content are just there so it's easier to read on screen 🎀)

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <list name="friends">
  <entry uri="sip:bill@example.com">
   <display-name>Bill Doe</display-name>
  </entry>
  <entry-ref ref="resource-lists/users/sip:bill@example.com/index/~~/
   resource-lists/list%5b@name=%22list1%22%5d/entry%5b@uri=%22sip:pet
   ri@example.com%22%5d"/>
  <list name="close-friends">
   <display-name>Close Friends</display-name>
   <entry uri="sip:joe@example.com">
    <display-name>Joe Smith</display-name>
   </entry>
   <entry uri="sip:nancy@example.com">
    <display-name>Nancy Gross</display-name>
   </entry>
   <external anchor="http://xcap.example.org/resource-lists/users/
    sip:a@example.org/index/~~/resource-lists/list%5b@name=%22mkti
    ng%22%5d">
     <display-name>Marketing</display-name>
    </external>
  </list>
 </list>
</resource-lists>

3.4. Usage with XCAP

okay the big question: can you manipulate resource lists documents with XCAP? YES, literally 🦋 this section gives you all the deets you need for that ✨

3.4.1. Application Unique ID

XCAP needs application usages to define an application unique ID (AUID) 🆔, either in the IETF tree or a vendor tree. This spec defines the "resource-lists" AUID in the IETF tree, via the IANA registration in Section 8 💜

3.4.2. MIME Type

the MIME type for this doc is application/resource-lists+xml 🎀

3.4.3. XML Schema

the XML Schema for this doc is literally the sole content of Section 3.2 🧚

3.4.4. Default Namespace

the default namespace used when expanding URIs is urn:ietf:params:xml:ns:resource-lists 🌸

3.4.5. Additional Constraints

so besides the schema, there are constraints on the values in the "name" attribute of the <list> element, the "uri" attribute of the <external> element, the "ref" attribute of the <entry-ref> element, and the "anchor" attribute of the <external> element. These are defined in Section 3.1 🔍 Some of them are enforced by the XCAP server, and those are:

  • The "name" attribute in a <list> element MUST be unique amongst all other "name" attributes of <list> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison.
  • The "uri" attribute in a <entry> element MUST be unique amongst all other "uri" attributes of <entry> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison.
  • The URI in the "ref" attribute of the <entry-ref> element MUST be unique amongst all other "ref" attributes of <entry-ref> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison. The value of the attribute MUST be a relative path reference. Note that the server is not responsible for verifying that the reference resolves to an <entry> element in a document within the same XCAP root.
  • The URI in the "anchor" attribute of the <external> element MUST be unique amongst all other "anchor" attributes of <external> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison. The value of the attribute MUST be an absolute HTTP URI. Note that the server is not responsible for verifying that the URI resolves to a <list> element in a document. Indeed, since the URI may reference a server in another domain, referential integrity cannot be guaranteed without adding substantial complexity to the system. 😭

3.4.6. Data Semantics

semantics for the document content are in Section 3.1 📖

3.4.7. Naming Conventions

resource lists documents are usually identified as references from other application usages. For example, an RLS services document contains a reference to the resource list it uses 🫶

okay so, an XCAP client will often want to insert or remove an <entry>, <entry-ref>, or <external> element without having a cached copy of the doc. In that case, the "uri" attribute of the <entry> element, the "ref" attribute of the <entry-ref> element, or the "anchor" attribute of the <external> element gets used as an index to pick the element to act on. The XCAP server determines uniqueness by case-sensitive string comparison. BUT these attributes hold URIs, and the URI equality rules for their schemes may let two URIs count as the same even when they differ by case-sensitive string comparison. So it's possible that a client tries a PUT or DELETE to modify or remove an existing element, and instead the PUT ends up inserting a new element, or the DELETE ends up returning an error response. Not it 💀

if the XCAP client can't tell whether the user wants to create or replace, the client SHOULD canonicalize the URI before doing the operation. For a SIP URI (often found in the "uri" attribute of the <entry> element), this canonicalization procedure is defined in Section 5. We expect that SIP URIs placed into resource lists documents will usually look like sip:user@domain, and possibly include a user parameter. The canonicalization rules work perfectly for these URIs 🌈

For HTTP URIs, a basic canonicalization algorithm goes like this. If the port in the URI equals the default port (80 for http URIs), the port gets removed. The hostname gets converted to all lowercase. Any percent-encoding for characters that don't need to be percent-encoded gets removed. A character needs to be percent-encoded when it isn't permitted in that part of the URI based on the grammar for that part of the URI. Simple, but it slays 💅

3.4.8. Resource Interdependencies

there are no resource interdependencies identified by this application usage 🧸

3.4.9. Authorization Policies

this application usage does NOT change the default XCAP authorization policy, which is that only a user can read, write, or modify their own documents 🔒 A server can let privileged users modify docs they don't own, but how those policies get set up and indicated is outside the scope of this doc. A future application usage is expected to define which users are allowed to modify a list resource 👑

4. RLS Services Documents ✨

4.1. Structure

okay so an RLS services document defines URIs that stand for services provided by a Resource List Server (RLS), as defined in [14] 🎀 It's an XML [2] document that MUST be well-formed and MUST be valid according to schemas (including extension schemas) that are available to the validater and applicable to the XML document. RLS services documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This spec uses XML namespaces to identify RLS services documents and document fragments. The namespace URI for elements defined here is a URN [3] that uses the namespace identifier 'ietf', which was defined by RFC 2648 [6] and extended by RFC 3688 [8]. The URN is:

urn:ietf:params:xml:ns:rls-services

the root element of an rls-services document is <rls-services>, and it holds a sequence of <service> elements, each one defining a service available at an RLS 🧚

each <service> element has one mandatory attribute, "uri". This URI defines the resource tied to the service. Basically, if a client subscribes to that URI, they'll get the service defined by the matching <service> element 💖 The <service> element can also have attributes from other namespaces, for extensibility. It contains child elements that define the service. For an RLS service, not much definition is needed: just the resource list the server will perform virtual subscriptions [14] to, and the set of event packages the service supports. The list can be conveyed in one of two ways. There can be a <resource-list> element, which points to a <list> element in a resource-lists document, OR there can be a <list> element that includes the resource list directly. The supported packages go inside the <packages> element. The <service> element can also contain elements from other namespaces, for extensibility 🦋

so, including the resource list directly means a user can create lists and add members with a single XCAP operation. The catch? The list becomes "hidden" inside the RLS service definition and can't be used by other application usages 😭 That's why the <resource-list> element exists as an alternative. It can reference a <list> element in a resource-lists document, and since the list is separate from the service definition, other application usages can reuse it easily 🫶

The <list> element is of the list type defined by the schema for resource lists. It's discussed in Section 3.1 📖

The <resource-list> element contains a URI. This element only means something when the doc was obtained through XCAP. The URI MUST be an absolute HTTP URI representing an XCAP element resource. Its XCAP root MUST be the same as the XCAP root of the RLS services document. When the RLS services document is in a user's home directory, the HTTP URI MUST exist underneath that user's home directory in the resource-lists application usage. When the RLS services document is in the global directory, the HTTP URI MUST exist underneath any user's home directory in the resource-lists application usage. In either case, the element the URI points to MUST be a <list> element within a resource-lists document. All of these constraints EXCEPT the last one (which is a referential integrity constraint) will be enforced by the XCAP server ✨

the <packages> element contains a sequence of <package> elements. The content of each <package> element is the name of a SIP event package [13]. The <packages> element may also contain elements from additional namespaces, for extensibility 🌈 The <packages> element is optional. When it's not there, it means the RLS service will accept subscriptions for ANY event package 🍓

4.2. Schema ✨

okay bestie, here's the schema 🎀 it's written in XML Schema, and it's giving very organised.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rls-services"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns="urn:ietf:params:xml:ns:rls-services"
 xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="rls-services">
  <xs:complexType>
   <xs:sequence minOccurs="0" maxOccurs="unbounded">
    <xs:element name="service" type="serviceType"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
 <xs:complexType name="serviceType">
  <xs:sequence>
   <xs:choice>
    <xs:element name="resource-list" type="xs:anyURI"/>
    <xs:element name="list" type="rl:listType"/>
   </xs:choice>
   <xs:element name="packages" type="packagesType" minOccurs="0"/>
   <xs:any namespace="##other" processContents="lax" minOccurs="0"
    maxOccurs="unbounded"/>

  </xs:sequence>
  <xs:attribute name="uri" type="xs:anyURI" use="required"/>
  <xs:anyAttribute namespace="##other" processContents="lax"/>
 </xs:complexType>
 <xs:complexType name="packagesType">
  <xs:sequence minOccurs="0" maxOccurs="unbounded">
   <xs:element name="package" type="packageType"/>
   <xs:any namespace="##other" processContents="lax" minOccurs="0"
    maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>
 <xs:simpleType name="packageType">
  <xs:restriction base="xs:string"/>
 </xs:simpleType>
</xs:schema>

4.3. Example Document 🦋

this one shows two services, okay?! 💅 the first is sip:mybuddies@example.com and the second is sip:marketing@example.com. the first one points at a resource list that lives in a resource-lists document, while the second one has its list written right there locally. both services are only for the presence event package, so no drama 🌸

<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
   xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <service uri="sip:mybuddies@example.com">
  <resource-list>http://xcap.example.com/resource-lists/user
   s/sip:joe@example.com/index/~~/resource-lists/list%5b@nam
   e=%22l1%22%5d</resource-list>
  <packages>
   <package>presence</package>
  </packages>
 </service>
 <service uri="sip:marketing@example.com">
   <list name="marketing">
     <rl:entry uri="sip:joe@example.com"/>
     <rl:entry uri="sip:sudhir@example.com"/>
   </list>
   <packages>
     <package>presence</package>
   </packages>
 </service>
</rls-services>

4.4. Usage with XCAP 💖

RLS services documents can be manipulated with XCAP, periodt 💅 this section gives you all the details you need for that vibe.

4.4.1. Application Unique ID 🧚

XCAP requires application usages to define an application unique ID (AUID) in either the IETF tree or a vendor tree. this spec defines the rls-services AUID inside the IETF tree, and that happens through the IANA registration in Section 8 ✨

4.4.2. MIME Type 🎀

the MIME type for this document is application/rls-services+xml 💜

4.4.3. XML Schema 🍓

the XML Schema for this document is the whole content of Section 4.2, so go check it out 🫶

4.4.4. Default Namespace 🌈

the default namespace used when expanding URIs is urn:ietf:params:xml:ns:rls-services ⭐

4.4.5. Additional Constraints 🔥

okay so, on top of the schema there are constraints on the URIs that show up in the <service> and <resource-list> elements. those constraints are defined in Section 3.1 ngl. some of them get enforced by the XCAP server, and those are:

  • the URI in the uri attribute of the <service> element MUST be unique amongst all other URIs in uri elements in any <service> element in any document on a particular server. this uniqueness constraint spans across XCAP roots. furthermore, the URI MUST NOT correspond to an existing resource within the domain of the URI. if a server is asked to set the URI to something that already exists, the server MUST reject the request with a 409, and use the mechanisms defined in [10] to suggest alternate URIs that have not yet been allocated. 😭
  • the URI in a <resource-list> element MUST be an absolute URI. the server MUST verify that the URI path contains "resource-lists" in the path segment corresponding to the AUID. if the RLS services document is within the XCAP user tree (as opposed to the global tree), the server MUST verify that the XUI in the path is the same as the XUI in the URI of to the RLS services document. these checks are made by examining the URI value, as opposed to dereferencing the URI. the server is not responsible for verifying that the URI actually points to a <list> element within a valid resource lists document. 🙈
  • in addition, an RLS services document can contain a <list> element, which in turn can contain <entry>, <entry-ref>, <list>, and <external> elements. the constraints defined for these elements in Section 3.4.7 MUST be enforced. 👑
  • sometimes an XCAP client wants to make a brand new RLS service and give it a "vanity URI", like sip:friends@example.com. the client doesn't know whether that URI meets the uniqueness constraints above though, so it can just attempt the creation. if the result is a 409 with a detailed conflict report that has the <uniqueness-failure> element, the client knows the URI couldn't be assigned. it can then retry with a different vanity URI, or use one of the suggestions in that detailed conflict report 💅
  • if the client wants a new RLS service and doesn't care what the URI is, the client creates a random one and attempts the creation operation. as discussed in [10], if that fails with a uniqueness conflict, the client can retry with different URIs with increasing randomness. ✨

4.4.6. Data Semantics 🌸

semantics for the document content are in Section 4.1, so go read that one too 🦋

4.4.7. Naming Conventions 💜

typically there are two distinct XCAP clients that touch RLS services documents. the first is a client acting on behalf of the end user, and it edits and writes both resource lists and RLS services documents as the end user creates or changes them. the other XCAP client is the RLS itself, which reads the RLS services documents so it can process SUBSCRIBE requests 🔥

to make life easier for an RLS finding the <service> element for a particular URI, the XCAP server keeps, inside the global tree, one single RLS services document. it represents the union of all the <service> elements across all documents created by all users within the same XCAP root. there's only one instance of this document, and its name is "index" 🎀 so if the root services URI is http://xcap.example.com, this is the URI an RLS would use to fetch that index:

http://xcap.example.com/rls-services/global/index

as we'll see below, this index gets built from all the documents in the user tree that are also named "index". the consequence is that a client working for a user SHOULD define its RLS services inside the document named "index". if the root services URI is http://xcap.example.com, the URI for user "sip:joe@example.com" would be:

http://xcap.example.com/rls-services/users/sip:joe@example.com/index
heads up bestie: if a client picks a different document to define RLS services in, that document won't get "picked up" in the global index, so it won't be used as an RLS service 🙈

4.4.8. Resource Interdependencies 🧚

like other application usages, the XML schema and the XCAP resource naming conventions cover most of the resource interdependencies for this usage 💖

this application usage adds one more interdependence: a single document in the global tree and all documents in the user tree named "index". that global document is formed as the union of all the index documents for all users within the same XCAP root. the union means each <service> element in a user document is also present as a <service> element in the global document, and the inverse is true too. every <service> element in the global document exists within a user document in the same XCAP root. it's giving symmetry 🌈

for example, take the RLS services document for user sip:joe@example.com:

<?xml version="1.0" encoding="UTF-8"?>
<rls-services>
 <service uri="sip:mybuddies@example.com">
  <resource-list>http://xcap.example.com/resource-lists/users/si
   p:joe@example.com/index/~~/resource-lists/list%5b@name=%22l1%
   22%5d</resource-list>
  <packages>
   <package>presence</package>
  </packages>
 </service>
</rls-services>

and then the RLS services document for user bob:

<?xml version="1.0" encoding="UTF-8"?>
<rls-services>
 <service uri="sip:marketing@example.com">
   <list name="marketing">
     <rl:entry uri="sip:joe@example.com"/>
     <rl:entry uri="sip:sudhir@example.com"/>
   </list>
   <packages>
     <package>presence</package>
   </packages>
 </service>
</rls-services>

the global document at http://xcap.example.com/rls-services/global/index would look like this 👑

<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
   xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <service uri="sip:mybuddies@example.com">
  <resource-list>http://xcap.example.com/resource-lists/user
   s/sip:joe@example.com/index/~~/resource-lists/list%5b@nam
   e=%22l1%22%5d</resource-list>
  <packages>
   <package>presence</package>
  </packages>
 </service>
 <service uri="sip:marketing@example.com">
   <list name="marketing">
     <rl:entry uri="sip:joe@example.com"/>
     <rl:entry uri="sip:sudhir@example.com"/>
   </list>
   <packages>
     <package>presence</package>
   </packages>
 </service>
</rls-services>

requests made against the global document MUST generate responses that reflect the most recent state of all the relevant user documents. this doesn't mean the server has to actually store this global document. it's expected that most systems will build the responses dynamically for any particular request against the document resource 🫶

the uniqueness constraint on the uri attribute of <service> makes sure no two <service> elements in the global document have the same value for that attribute 💅

4.4.9. Authorization Policies 🔒

this application usage doesn't change the default XCAP authorization policy, which says that only a user can read, write, or modify their own documents 🙈 a server can let privileged users modify documents they don't own, but how those policies get set up and shown is outside the scope of this document. it's expected that a future application usage will define which users are allowed to modify an RLS services document ✨

the index document in the global tree is sensitive, bestie 😭 it holds the union of all the information for all users on the server. so its access MUST be restricted to trusted elements within the domain of the server. typically that means only the RLSs that need access to this document get it 🌈

4.5. Usage of an RLS Services Document by an RLS

okay so this section is all about how an RLS (Resource List Server) uses XCAP and the RLS services document once a SUBSCRIBE request lands 📬✨ the RLS is the one catching the request, and it's basically using the doc as its cheat sheet 💅

When an RLS gets a SUBSCRIBE request for a URI (the one in the Request URI), it has to find the <service> element whose uri attribute matches that URI, using URI equality 🔍 this document doesn't make any normative statements about how the RLS pulls that off. The next paragraph gives one possible approach, so you've got a starting point 🧚

The RLS canonicalizes the Request URI as described in Section 5. Then it does an XCAP GET against the URI made by combining the XCAP root with the document selector of the global index, plus a node selector of the form "rls-services/service[@uri=<canonical-uri>]", where <canonical-uri> is the canonicalized version of the Request URI 🎀 if the response is a 200 OK, it'll contain the service definition for that URI, and we're cooking 🔥

Once the <service> element is in hand, it gets examined 👀 if the <packages> element is there, and the event package in the SUBSCRIBE request isn't one of the ones listed in the <package> elements inside <packages>, the request MUST be rejected with a 489 (Bad Event) response code, as described in [13]. Otherwise, it SHOULD be processed. Next up, the RLS checks that the client is allowed to subscribe to the resource. It can use the data defined in [12] for that, for example 🔐 Assuming the subscriber is authorized, the subscription gets processed according to the procedures defined in [14] 💜

Here's the tricky bit 😭 that processing needs the RLS to compute a flat list of URIs to subscribe to. If the <service> element had a <list> element, the RLS extracts it. If it had a <resource-list> element instead, the RLS dereferences its URI content. The result should be a <list> element. If it isn't, the request SHOULD be rejected with a 502 (Bad Gateway). Otherwise, that <list> element gets extracted ✨

At this point the RLS has a <list> element, and the next job is to turn it into a flat list of URIs 🌸 to do that, it walks the tree rooted at the <list> element. Before the walk starts, the RLS sets up two lists, both empty to begin with: the "flat list", which will hold the flat list of URIs after traversal, and the "traversed list", which holds the HTTP URIs in <external> elements that have already been visited 🦋 then the traversal begins. A server can use any tree-traversal ordering it likes, such as depth-first search or breadth-first search. What happens at each element depends on its name 💅

  • If the element is <entry>, the URI in its "uri" attribute gets added to the flat list, as long as it isn't already in there (based on case-sensitive string equality) and its URI scheme is one that can be used to service subscriptions, such as SIP [4] and pres [15] 📞
  • If the element is an <entry-ref>, the relative path reference in its "ref" attribute gets resolved into an absolute URI. This uses the procedures defined in Section 5.2 of RFC 3986 [7], with the XCAP root of the RLS services document as the base URI. That absolute URI is then resolved. If the result isn't a 200 OK containing an <entry> element, the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). Otherwise, the <entry> element that came back gets processed the same way as in the previous bullet 🫶
  • If the element is an <external> element, the absolute URI in its "anchor" attribute gets examined 🕵️‍♀️ if that URI is already on the traversed list, the server MUST cease traversing the tree, and SHOULD reject the SUBSCRIBE request with a 502 (Bad Gateway). If it isn't on the traversed list, the server adds it to the traversed list and dereferences it. If the result isn't a 200 OK containing a <list> element, the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). Otherwise, the RLS swaps the <external> element in its local copy of the tree for the <list> element that came back, and the traversal keeps going 🔄
Because the <external> element is used to build the tree dynamically, there's a possibility of recursive evaluation of references 😱 the traversed list is what stops that from happening. Don't skip it!

Once the tree has been traversed, the RLS can create virtual subscriptions to each URI in the flat list, as defined in [14] 🎉 now, in the steps above, when an <entry-ref> or <external> element has a reference that can't be resolved, failing the request is at SHOULD strength. But sometimes an RLS can give better service by creating virtual subscriptions only to the URIs in the flat list that could be obtained, skipping the ones that couldn't. Only in those cases should the SHOULD recommendation be ignored 🙈

5. SIP URI Canonicalization

okay this section hands you a technique for canonicalizing URIs 🧼 the result is, in most cases, equal to the original URI (where equality is based on the URI comparison rules in RFC 3261). Even better, the canonicalized URI will usually be lexically equivalent to the canonicalized version of any other URI that's equal to the original ✨

To canonicalize a URI, you follow these steps:

  1. First, the domain part of the URI gets converted to all lowercase, and any tokens (such as "user" or "transport" or "udp") get converted to all lowercase too 🔡
  2. Secondly, any percent-encoding for characters that don't need to be percent-encoded gets removed 🧹 a character needs to be percent-encoded when it isn't permitted in that part of the URI based on the grammar for that part. For example, if a SIP URI is sip:%6aoe%20smith@example.com, it changes to sip:joe%20smith@example.com. In the original, the character 'j' was percent-encoded. That's allowed but not required, since the grammar lets a 'j' show up in the user part, so after this step it appears as 'j' 💖
  3. Thirdly, any URI parameters get reordered so they appear in lexical order based on parameter name 📋 the ordering of a character is decided by its US-ASCII numerical value, with smaller numbers coming first. Parameters are ordered with the leftmost character as most significant. For parameters that only contain letters, this is the same as alphabetical ordering 🔤
  4. Finally, any header parameters get discarded 🗑️ this canonicalized URI is used instead of the original URI.

If two URIs, A and B, are functionally equal (meaning they're equal according to the URI comparison rules in RFC 3261), their canonicalized URIs are equal under case-sensitive string comparison if both of these are true:

  • Neither URI contains header parameters.
  • If one of the URIs contains a URI parameter not defined in RFC 3261, the other one does as well.

6. Extensibility

resource-lists and RLS services documents are built to be extended 🧩 and the way you extend them is by defining a new set of elements in a new namespace, governed by a new schema. Every extension MUST have an appropriate XML namespace assigned to it 🎀 the XML namespace of the extension MUST be different from the namespaces defined in this specification. The extension MUST NOT change the syntax or semantics of the schemas defined in this document. All XML tags and attributes that are part of the extension MUST be appropriately qualified so they sit inside that namespace 💅

This specification defines explicit spots where new elements or attributes from an extension can go 📍 they're marked in the schemas by the <any> and <anyAttribute> elements. Extensions to this specification MUST specify where their elements can be placed within the document 🗺️

So a document with extensions needs multiple schemas to figure out whether it's valid: one schema defined in this document, plus the ones defined by each extension present in the document 🤓 because extensions work by adding new elements and attributes governed by new schemas, the schemas defined in this document are fixed. They'd only change with a revision to this specification. Such a revision, if it ever happens, would try its best to let documents compliant with the previous schema stay compliant with the new one 🦋 that's also why the schemas here don't carry explicit schema versions. This isn't expected to be needed.

7. Security Considerations

ngl this section is serious, so listen up 😭 the information in rls-services and resource-lists documents is particularly sensitive 🔒 it represents the principal set of people a user would like to communicate with, which is basically their social map. Because of that, clients SHOULD use TLS when contacting servers to fetch this information. Note that this doesn't change the requirement strength from XCAP 🛡️

8. IANA Considerations

there are several IANA considerations tied to this specification, so let's go through them 📝

8.1. XCAP Application Unique IDs

this section registers two new XCAP Application Unique IDs (AUIDs) according to the IANA procedures defined in [10] 🌈

8.1.1. resource-lists

Name of the AUID: resource-lists

Description: a resource lists application is any application that needs access to a list of resources, identified by a URI, that operations (like subscriptions) can be applied to 📋

8.1.2. rls-services

Name of the AUID: rls-services

Description: an RLS services application is a Session Initiation Protocol (SIP) application where a server receives SIP SUBSCRIBE requests for a resource and generates subscriptions towards a resource list 📞✨

8.2. MIME Type Registrations

this specification asks for the registration of two new MIME types, following the procedures of RFC 4288 [9] and the guidelines in RFC 3023 [5] 🎀

8.2.1. application/resource-lists+xml

Here's the registration template, copied exactly so nothing gets lost 💖

MIME media type name:  application

MIME subtype name:  resource-lists+xml

Mandatory parameters:  none

Optional parameters:  Same as charset parameter application/xml as
   specified in RFC 3023 [5].

Encoding considerations:  Same as encoding considerations of
   application/xml as specified in RFC 3023 [5].

Security considerations:  See Section 10 of RFC 3023 [5] and
   Section 7 of RFC 4826.

Interoperability considerations:  none

Published specification:  RFC 4826

Applications that use this media type:  This document type has been
   used to support subscriptions to lists of users [14] for SIP-based
   presence [11].

Additional Information:

      Magic Number: none

      File Extension: .rl

      Macintosh file type code: "TEXT"

Personal and email address for further information:
   Jonathan Rosenberg, jdrosen@jdrosen.net

Intended usage:  COMMON

Author/Change controller:  The IETF.

8.2.2. application/rls-services+xml ✨

  • MIME media type name: application
  • MIME subtype name: rls-services+xml
  • Mandatory parameters: none
  • Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [5].
  • Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5].
  • Security considerations: See Section 10 of RFC 3023 [5] and Section 7 of RFC 4826. 🔐
  • Interoperability considerations: none
  • Published specification: RFC 4826
  • Applications that use this media type: This document type has been used to support subscriptions to lists of users [14] for SIP-based presence [11]. 📞
  • Additional Information:
    • Magic Number: none
    • File Extension: .rs
    • Macintosh file type code: "TEXT"
  • Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net 💌
  • Intended usage: COMMON
  • Author/Change controller: The IETF.

8.3. URN Sub-Namespace Registrations 🌸

This section registers two new XML namespaces, as per the guidelines in RFC 3688 [8]. So organised, I'm obsessed. 🗂️

8.3.1. urn:ietf:params:xml:ns:resource-lists

  • URI: The URI for this namespace is urn:ietf:params:xml:ns:resource-lists.
  • Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).

The XML for this namespace goes like this:

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>Resource Lists Namespace</title>
</head>
<body>
  <h1>Namespace for Resource Lists</h1>
  <h2>urn:ietf:params:xml:ns:resource-lists</h2>
  <p>See <a href="http://www.rfc-editor.org/rfc/rfc4826.txt">
     RFC4826</a>.</p>
</body>
</html>
END

8.3.2. urn:ietf:params:xml:ns:rls-services

  • URI: The URI for this namespace is urn:ietf:params:xml:ns:rls-services.
  • Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).

The XML for this namespace goes like this:

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>Resource List Server (RLS) Services Namespace</title>
</head>
<body>
  <h1>Namespace for Resource List Server (RLS) Services</h1>
  <h2>urn:ietf:params:xml:ns:rls-services</h2>
  <p>See <a href="http://www.rfc-editor.org/rfc/rfc4826.txt">
     RFC4826</a>.</p>
</body>
</html>
END

8.4. Schema Registrations 📜

This section registers two XML schemas per the procedures in [8]. 💅

8.4.1. urn:ietf:params:xml:schema:resource-lists

  • URI: urn:ietf:params:xml:schema:resource-lists
  • Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).

The XML for this schema can be found as the sole content of Section 3.2.

8.4.2. urn:ietf:params:xml:schema:rls-services

  • URI: urn:ietf:params:xml:schema:rls-services
  • Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).

The XML for this schema can be found as the sole content of Section 4.2.

9. Acknowledgements 🫶

The authors would like to thank Hisham Khartabil, Jari Urpalainen, and Spencer Dawkins for their comments and input. Thanks to Ted Hardie for his encouragement and support of this work. 💖

10. References 📚

10.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
  • [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
  • [4] 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.
  • [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
  • [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
  • [9] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
  • [10] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

10.2. Informative References

  • [11] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
  • [12] Rosenberg, J., "Presence Authorization Rules", Work in Progress, October 2006.
  • [13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
  • [14] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, January 2005.
  • [15] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.

Author's Address 🎀

Jonathan Rosenberg
Cisco
Edison, NJ
US

EMail: jdrosen@cisco.com
URI:   http://www.jdrosen.net

Copyright (C) The IETF Trust (2007).

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.

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, THE IETF TRUST 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.

Intellectual Property 🔏

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.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from