Extensible Markup Language (XML) Formats for Representing Resource Lists
Extracted elements (32)
SIP URI canonicalization (Section 5) normalizes domain to lowercase, removes unnecessary percent-encoding, reorders URI parameters lexically, and discards header parameters. This ensures that functionally equivalent SIP URIs produce the same string under case-sensitive comparison, enabling reliable XCAP element selection.
The <resource-list> element (reference to an external list) and inline <list> element are both supported in <service> to allow trade-offs: an inline list enables single-operation creation but is hidden from other usages, while <resource-list> enables list reuse across multiple application usages at the cost of a separate XCAP document.
The XCAP server does not verify referential integrity for <entry-ref> and <external> references (i.e., it does not check that the referenced <entry> or <list> actually exists), because cross-server references make guaranteed referential integrity impractical without substantial added complexity.
URI uniqueness in <entry>, <entry-ref>, and <external> elements is enforced by case-sensitive string comparison, which may differ from functional URI equality for a given scheme (e.g., SIP). Two URIs functionally equal may be treated as distinct by XCAP, causing unexpected PUT insertions or DELETE failures.
A client operating on behalf of a user SHOULD define its RLS services within the document named 'index' so that entries appear in the global index maintained by the XCAP server.
Clients SHOULD use TLS when contacting servers to fetch rls-services and resource-lists documents, because this information is particularly sensitive.
Extensions to resource-lists and RLS services documents MUST have a distinct XML namespace, MUST NOT change the syntax or semantics of existing schemas, and MUST specify where extension elements can be placed.
If an XCAP client cannot determine whether user intent is to create or replace a URI-keyed element, the client SHOULD canonicalize the URI before performing the operation using the SIP URI canonicalization procedure in Section 5.
If the <packages> element is present in a <service> element and the event package in the SUBSCRIBE request is not listed, the RLS MUST reject the request with a 489 (Bad Event) response.
Requests against the global rls-services document MUST generate responses reflecting the most recent state of all relevant user documents; the server need not actually store the global document.
Resource lists documents MUST be well-formed XML, MUST be valid according to applicable schemas, MUST be based on XML 1.0, and MUST be encoded using UTF-8.
The global index document's access MUST be restricted to trusted elements within the domain of the server, as it contains the union of all service definitions for all users.
The 'name' attribute in a <list> element MUST be unique amongst all other 'name' attributes of <list> elements within the same parent element, with uniqueness determined by case-sensitive string comparison.
The 'ref' attribute of <entry-ref> MUST be a relative path reference (never beginning with '/'), and the 'anchor' attribute of <external> MUST be an absolute HTTP URI identifying an XCAP <list> element within a resource-lists document.
The 'uri' attribute in an <entry> element MUST be unique amongst all other 'uri' attributes of <entry> elements within the same parent element, with uniqueness determined by case-sensitive string comparison.
The URI in a <resource-list> element MUST be an absolute URI, and the server MUST verify the URI path contains 'resource-lists' in the AUID path segment. If the RLS services document is in the user tree, the server MUST verify the XUI matches.
The URI in the 'uri' attribute of the <service> element MUST be unique across all <service> elements in any document on a particular server, spanning all XCAP roots. If the URI already exists, the server MUST reject the request with a 409.
When traversing an <external> element, if the URI is already on the traversed list (indicating a circular reference), the server MUST cease traversal and SHOULD reject the SUBSCRIBE with a 502 (Bad Gateway).
The <entry> element describes a single resource with a mandatory 'uri' attribute (any URI scheme; SIP and pres URIs required for RLS services) and an optional <display-name> child element with an optional xml:lang attribute.
The <entry-ref> element includes a resource list entry by reference using a mandatory 'ref' attribute that MUST be a relative path reference resolved against the XCAP root URI, pointing to an <entry> element within the same XCAP root.
The <external> element references an entire <list> stored on this or another server via a mandatory 'anchor' attribute containing an absolute HTTP URI. It enables cross-server list references but may introduce circular reference risks.
The <packages> element in a <service> definition contains zero or more <package> elements naming supported SIP event packages. When absent, the RLS service accepts subscriptions for any event package.
The resource-lists document has a <resource-lists> root element containing zero or more <list> elements. Each <list> can contain <entry>, <entry-ref>, <external>, and nested <list> elements, enabling hierarchical resource lists.
The RLS services document has an <rls-services> root element containing <service> elements, each with a mandatory 'uri' attribute and child elements: either <resource-list> or <list> (for the resource list), plus optional <packages> listing supported SIP event packages.
The XCAP server maintains a global rls-services index document at '<xcap-root>/rls-services/global/index' representing the union of all <service> elements from all user 'index' documents within the same XCAP root.
Registers two XCAP Application Unique IDs (AUIDs) in the IETF tree: 'resource-lists' (for resource list management) and 'rls-services' (for RLS service definition), per XCAP IANA procedures.
Registers two XML namespace URNs: 'urn:ietf:params:xml:ns:resource-lists' and 'urn:ietf:params:xml:ns:rls-services', and two XML schema URNs: 'urn:ietf:params:xml:schema:resource-lists' and 'urn:ietf:params:xml:schema:rls-services'.
Resource-lists and rls-services documents are particularly sensitive as they represent the set of people a user communicates with. Clients SHOULD use TLS when fetching this information from servers.
The global rls-services index document contains the union of all users' service definitions and is therefore sensitive; access MUST be restricted to trusted elements (typically only the RLS servers) within the server's domain.
RLS flat-list traversal: initializes an empty 'flat list' and empty 'traversed list'; for each tree node processes <entry> (add URI to flat list if unique), <entry-ref> (resolve and dereference), or <external> (check traversed list for cycles, then dereference and replace in tree). Cycle detection triggers rejection with 502.
Resource-lists documents use MIME type 'application/resource-lists+xml' with UTF-8 encoding, namespace 'urn:ietf:params:xml:ns:resource-lists', and file extension '.rl'.
RLS services documents use MIME type 'application/rls-services+xml' with UTF-8 encoding, namespace 'urn:ietf:params:xml:ns:rls-services', and file extension '.rs'.