Subject: [Simple] XCAP List Issue 4: List URI uniqueness

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Jun 2004 07:48:26 -0400

The main purpose of the resource list XML schema is to define the 
resource lists that you can subscribe to using the SIP event extension 
for resource lists 
(http://www.watersprings.org/pub/id/draft-ietf-simple-event-list-04.txt).

This means that the SIP URI identifying each resource list needs to be 
unique on the server. Unfortunately, those URI exist buried within each 
resource list document. This makes it hard to, at the time a resource 
list is added or changed, check to see that the list URI is unique.

Similarly, when a resource list server (the SIP server handling 
SUBSCRIBE requests for the list) receives a SUBSCRIBE to a list, there 
isn't a clear document to go to that indicates the contents of that list.

In other words, the SIP URI for the resource lists is meaningful as an 
index, but it doesnt appear anywhere in the schemas as an index.

There are two solutions to this problem:

Approach I: Leave it alone. Let the XCAP servers maintain this index on 
their own. It does mean that that there isn't an easy way for the 
resource list server to fetch the contents of the list from the XCAP 
server in a standard way.

Approach II: We can define a new application usage, which is the actual 
set of resource list URIs you can subscribe to. There would be a single 
instance of this document for each user. That would contain the list of 
URIs defined by that user as subscribeable resource lists. For each URI, 
there would be a reference into their actual hierarchy of <list> and 
<entry>s as defined by the current schema in the existing doc. For example:

<sip-uris>
   <list uri=“sip:[email-masked]”>
  http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/
  resource-lists/list[@name=“co-workers”]
   </list>
</sip-uris>

We would, as a result of this, remove the "subscribeable" flag from the 
current schema, along with the URI attribute for the <list> element.

In addition to there being a single instance of a document for each 
user, there would also be a single instance of a document for the entire 
server. This document would be in the global tree, readable only by 
resource lists servers. It basically contains the union of all of the 
documents for the individual users. This would allow a resource list 
server to do a single query to obtain the HTTP URI that defines the 
membership of the list. For example, if an RLS got a SUBSCRIBE request 
for sip:[email-masked], it would do the following XCAP query to get 
the XCAP URI pointing to the membership:

GET 
http://xcap.server.com/xcap-root/list-of-lists/global/thelist/~~/sip-uris/
list[@uri="sip:[email-masked]"]

and the 200 OK:

200 OK
Content-Type: application/xml

<list uri=“sip:[email-masked]”>
  http://www.example.com/xcap/resource-lists/users/a/obuddies/ 
resource-lists/list[@name=“co-workers”]
</list>

Now it can do this:

GET http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/
resource-lists/list[@name=“co-workers”]

and get back:
200 OK
Content-Type: application/xml

   <list name="co-workers">
     <entry name="Bill" uri="sip:[email-masked]">
       <display-name>Bill Doe</display-name>
     </entry>
     <list name="close-friends">
       <entry name="Joe" uri="sip:[email-masked]">
         <display-name>Joe Smith</display-name>
       </entry>
       <entry name="Nancy" uri="sip:[email-masked]">
         <display-name>Nancy Gross</display-name>
       </entry>
       <external>http://www.example.org/xcap/resource-lists/users/a/foo
          </external>
     </list>
   </list>

and the result is the list of URIs the RLS needs to subscribe to.

I really like approach 2. It clearly separates the SIP activities 
associated with a list, from the set of users that make up the list. It 
provides a concrete place where the index of buddy lists will live, both 
for each user and for all users. It seems to work better for ad-hoc 
lists two. The thing carried in the body of the SUBSCRIBE or INVITE or 
MESSAGE or whatever, which identifies the ad-hoc list, is only the 
structure set of users. The "subscribeable" flag would make no sense in 
that context, for example, and with this proposal, it would be removed.

Note that a change to the list for a single user would need to be 
automatically reflected in the global list by the server.

I'd propose making this change. I think we need to define both 
application usages up front, since we can't satisfy our driving 
requirement (define a way to create buddy lists for SIP resource list 
subscriptions) without both. I would do them both in the same document 
however.

Comments?

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

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jun 2004 06:19:26 -0400

Folks,

This proposal here represents a pretty important change that we could 
make to the list handling; one that I think we should make. Please take 
a look and comment.

Thanks,
Jonathan R.