Subject: Re: [Simple] XCAP as general configuration protocol.

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Sep 2004 14:56:30 -0400

Sorry again for the week long lag in my responses - finally found some 
time today to unbury myself from email backlog.

Responses inline.

Dave Cridland wrote:

> On Fri Aug 27 13:46:51 2004, Jonathan Rosenberg wrote:
> 
>> Dave Cridland wrote:
>>
>>> I'm a little confused by XCAP's purpose - is it aimed at providing a
>>>  configuration protocol specifically for the needs of SIMPLE's 
>>> protocol suite, or is it aimed at providing generalized configuration
>>>  access?
> 
> 
> 
>>> 1) How do vendor-specific extensions work? (Say, if an addressbook or
>>>  bookmark collection were stored in XCAP, how would an application 
>>> add its own data to it?) Is this handled purely by namespaces, or 
>>> does that interfere with the Schemas defined?
>>
>>
>> Each of the schemas in an application usage defines points where
>> extensions can add additional information. That additional information
>> would come from a different namespace.
>>
>>
> Predefined points? How does the designer know where extension might be 
> required?

Thats part of the task of designing the schema. There are many examples 
throughout XML document designs.

>>
>> The following spec defines a format for differences in documents:
>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-02.txt
>>
>> These documents would get delivered in notifications, using a SIP event
>> package:
>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-04.txt 
>>
>>
>>
> Ah... So XCAP requires SIP to be of any real use?

As Joel pointed out, this is a matter of perspective. There are many 
envisioned uses where the change notifications are not needed.

>>> I'm thinking particularly of, for instance, storing bookmarks in
>>> XCAP, which would require some method to track which bookmarks had
>>> been visited recently - in other words, every bookmark usage would
>>> then invalidate the entire document. That's truly terrifying.
>>
>>
>> I don't follow what you intend to store in the server. The bookmark 
>> URL and some kind of indication of when it was last visited?
> 
> 
> Yes, exactly that. (And more, of course.)
> 
> It's a useful feature which allows the notion of bookmarks and history 
> to merge, somewhat.

I think that is achievable with XCAP.

> 
> 
> Having read through your comments a little more, I think I understand 
> where XCAP fits in a little better.
> 
> As I understand things, a typical XCAP client would:
> 
> 1) Bootstrap its initial configuration with a GET request for the area 
> that interested it from XCAP. (I'm unclear how it might find the XCAP 
> server, but finding your configuration server is always fun.)

THis is described for SIP elements in the above-mentioned document.

> 2) Possibly using this information, acquire SIP.

I don't know what it means to "acquire SIP". The client may or may not 
support SIP depending on what it needs to do.

> 3) Write any changes using XCAP PUT and DELETE. Since PUT invalidates 
> the cache, ignore any result other than success or failure for PUT.

In your specific example, I would expect the PUT to be made against the 
specific bookmark whose status is being updated, each of which would be 
a different URI. SO, a simple-minded XML doc might look like this:

<bookmarks>
   <site name="yahoo">
     <url>http://www.yahoo.com</url>
     <last-visited>Sep 8, 2004</last-visited>
   </site>
   <site name="ietf">
     <url>http://www.ietf.org</url>
     <last-visited>Sep 8, 2004</last-visited>
   </site>
</bookmarks>

If I visit the ietf site, the browser would do something like this:

PUT 
http://xcap.example.com/bookmarks/users/joe/index/~~/bookmarks/site[@name="ietf"]/last-visited

<last-visited>Sep 9, 2004</last-visited>

> 4) Listen constantly for updates via SIP.

Are you expecting multiple clients to be updating the same bookmark file?

> 5) On reconnect, use acquire SIP using cached data, and then use SIP to 
> resynchronize.

If you don't want SIP, the other chocie is that the client can cache the 
etag for the document, and on re-connect, use HEAD to check if it has 
changed. If not, do nothing. If so, pull the whole new bookmark file.

> 
> Is it not possible to handle the writes via SIP, which appears to be 
> required anyway? And if so, couldn't nearly all the complexity of XCAP 
> be dropped out to provide a very simple configuration bootstrap protocol?

SIP doesnt do anything near what XCAP does. As such, there would be no 
savings in complexity. Its also well outside of the scope of SIP.

-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