[Simple] Updated xcap-list spec, ready for wglc

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

Folks,

I've just submitted an update to the xcap-list spec. Until it appears in 
the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-simple-xcap-list-usage-03.txt

There are no known issues. I believe this document is ready for working 
group last call.

All of the previous issues I posted have been resolved. Here is the 
summary of the resolution:

ISSUE 1: Scope of the entry-ref element
  scoped to an xcap-root. This is enforced by using a relative path 
reference (i.e., a path sequence starting from the xcap root)

ISSUE 2: URI of entry as an attribute or element
  Remains an attribute to allow indexing, see issue 3

ISSUE 3: remove name as an index for entry
  Removed. URI is used as an index. Canonicalization rules are defined 
which should work well in pretty much every case. These rules are not 
the ones I had posted in my last note on the topic (which stripped all 
parameters and converted the domain to lowercase). That stripping 
removed too much necessary inforamtion. Rather, tokens and domains are 
converted to lowercase, escape coding is normalized, and uri parameters 
are lexically ordered. This means that, in the vast majority of cases, 
two canonicalized URI are lexically equal if their original URI are 
functionally equal.

ISSUE 4: do we want a separate index document?
  I created this. Its a separate application usage in the same 
document. This was a major change and impacted a LOT of text. I think it 
added a great deal of clarity.

Note that I had to change the schema for the list document after I 
submitted the core xcap spec. As a result, the examples in the core spec 
are not valid according to the schema in this doc. I will fix that in 
the next update to the core xcap spec.


Here are the list of changes overall:

* separated the document into two application usages. One, called
resource-lists, contains lists of hierarchical resources, independent
of how they are used. The other, rls-services, defines a document
which contains the data needed for an RLS to operate. This includes
the supported packages, along with either a <list> element (imported
from the resource-lists schema) or a <resource-list> element, which
contains a URI pointing to a <list> in a resource-list document. This
allows a simple case where the list is embedded in the "buddy list",
or where the list is separate, and therefore reusable by other
applications. [ISSUE 4]

* the RLS services document starts with <rls-services> and has a list
of <service>. Each <service> has a "uri" param that contains the
subscribeable URI. It then has either <list> or <resource-list>,
followed by <packages> which defines the allowed packages.

* the rls-services application usage requires an XCAP server to maintain
a global rls-services document containing the union of all of the
<service> elements for all users. The text explicitly calls out that
the server need not actually construct this document; its contents can
be created on the fly to process a request against it.

* defined a URI canonicalization procedure that is used prior to
placing a URI into a "uri" attribute of a <service> element. This
addresses the issues raised about using the URI as a unique index in
XCAP selection [ISSUE 3]

* defined detailed RLS processing procedures on how the <service>
element is fetched from the XCAP server, and how the resulting tree
defined by <list> is traversed and compacted into a flat list of
unique URI, to which virtual subscriptions can be made. THis includes
the possibility of making an authorization decision about the
subscription using the presence-rules document.

* Added examples

* Rewrote the introduction to cleanly separate the notion of a
resource list from a service which might access that resource list.

* Removed the <mandatory-ns> element, which was something required
from past versions of xcap.

* Removed the subscribeable and uri attributes from the <list>
element. List now has a single optional attribute, "name"

* Consistent way of talking about elements and attributes. Elements
are always described with angle brackets (i.e., <list> as opposed to
"list") and attributes use double quotes.

* <entry-ref> is now defined to have a "ref" attribute which contains
an relative path reference; namely,
its the part of an XCAP URI to the right of the root services URI. An
example is given. Entry-ref can also have a display-name content and
additional elements from other namespaces. THis causes the entry-ref
to be forcefully scoped to refer to entries within the same xcap root 
[ISSUE 1]

* <external> used to say that the XCAP URI had to be on another
server. It can also be on the local server. That has been
clarified. The reference is in the "anchor" attribute of
<external>. It can contain a display name and a list of elements from
other namespaces.

* <entry-ref> and <external> are only meaningful for documents
obtained from an xcap server. That has been specified. Furthermore,
the spec is very clear that it is not the responsibility of the server
to maintain referential integrity (that is, to make sure that the
entry and list elements to which the references point always exist).

* <external> did not previously say that the XCAP URI had to resolve
to a <list> element within a resource-list document. It now says that.

* removed "name" attribute of <entry> [ISSUE 3]

* the <entry> element used to require that its "uri" attribute be a
SIP or pres URI. However, thats not right. It depends on the service
which is trying to use the resource list. The resource list format
itself does not constrain this any longer. The processing logic of an 
RLS described in this document has it discarded non-sip and non-pres URI.

* added appropriate escape encoding

* added xml:lang attribute to display name

* documented how both client generated and server assigned URIs work.


Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen at dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple