Subject: [Simple] XCAP as general configuration protocol.

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Aug 2004 14:36:05 +0100

Hi folks,

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?

It may help to know that I'm looking at it from the perspective of 
someone who's operationally deployed ACAP in production environments, 
but given the lack of support, if XCAP takes off, then I might have 
to switch. I appreciate this is an unusual perspective. :-)

It may also help to know I know next to nothing about XML Schemas, 
which is unfortunate, but I note this draft is heading quickly 
towards last call, so I wanted to find out exactly what it's doing as 
quickly as possible.

Things I'm particularly confused about:

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?

2) Given the degree of validation effort possible to request from the 
server, is it within the specification to have an AUID that doesn't 
do any validation? (Obviously it'd have to do XML-well-formedness.) 
I'm quite concerned that XCAP appears to be a substantial 
resource-hog - performing referential integrity checks on XML can't 
be the fastest thing in the world (I could be wrong, but it's 
certainly going to be slower than a purely syntactic validation). 
Does anyone have any information on how fast (or slow) an XCAP server 
is?

3) As I understand it, the only method of searching is via the 
reduced XPath used in the URI. Is there any reason why a redefinition 
of a reduced XPath has been used rather than simply using XPath in 
the URI? (I can't see anyone choosing to handle these URIs in any way 
other than using an XPath library).

4) Given that, in general, applications will wish to use a 
substanital block of configuration data, and maintain it as current 
as reasonably possible, how does an application obtain a list of 
changes since a certain time (or ETag)? The only method I can see is 
by polling the entire block, which, if changed, will produce a 
substantial amount of output.

Alternately, an application could try an If-None-Match HTTP request 
against every node - the problem then being that, naturally, the 
entire document will not match the stored ETag, hence reducing to a 
full poll.

This strikes me as quite a serious problem, so I'd like to be assured 
that I'm missing something obvious. (Ideally, XCAP would have push 
notifications like ACAP has, but given the HTTP basis, that is of 
course impossible.)

Of course, I don't care about any of the above if XCAP isn't really 
intended for the same general target as ACAP is - in which case I'll 
keep my eye out for some other, more suitable, replacement. (A shame, 
since ACAP is perfectly suited to my needs.)

And I apologise in advance if this has already been done to death on 
the mailing list - Google can't find much about it all.

Whichever, I would thoroughly appreciate a mail if anyone has a test 
implementation of an XCAP server and/or client I could try.

Dave.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Aug 2004 08:46:51 -0400

Dave,

Apologies for the long delay in responding. Answers inline.

Dave Cridland wrote:

>  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.

>  do any validation?

Yes. Indeed, extensions to existing application usages, which are not
understood by the server, will have no validation beyond XML well
formedness.

 > (Obviously it'd have to do XML-well-formedness.) I'm
> quite concerned that XCAP appears to be a substantial resource-hog -
>  performing referential integrity checks on XML can't be the fastest
>  thing in the world

XCAP servers don't do referential integrity checks. This is explicitly
called out somewhere.

 >(I could be wrong, but it's certainly going to be
> slower than a purely syntactic validation). Does anyone have any 
> information on how fast (or slow) an XCAP server is?

I don't have performance figures. I suspect they depend on the app usage.

>  other than using an XPath library).

There was a LOOONG debate on this. XPath does a lot of stuff we really
don't need or want, as it would introduce a lot of complexity into the
server and client for no net benefit. Thus, our approach was to use a
strict subset.

> substantial amount of output.

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

> notifications like ACAP has, but given the HTTP basis, that is of 

Right, thats why we use a SIP event package for pushing diffs.

>  keep my eye out for some other, more suitable, replacement. (A
> shame, since ACAP is perfectly suited to my needs.)

TO be clear, it is NOT the objective of XCAP to be a feature for feature
equivalent replacement to ACAP. The group looked at acap as the basis of
its work:
http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.txt

but decided not to use acap.

As such, XCAP is "inspired" by ACAP, but not designed to be a
replacement. I suspect it meets many of the needs of any existing ACAP
users (though I admit I didnt know there were any!), but I am sure it
doesnt meet them all. In particular, we purposefully rejected features
like inheritance and built in ACL support, which are present in ACAP,
but were not needed for our applications.

Answering some of your follow up questions from Joel's response:

>> With regard to your specific questions: 1) Extensibility depends 
>> upon the schema of the application.  If the application schema does
>>  not allow for extensions, then there are no vendor extensions.  If
>>  every element of the scheme has an any tag permitted, then you can
>>  do anything you want.
>> 
>> 
> Presumably that applies to standardized extensions, too - a new 
> version of a particular AU would require an entirely new AUID?

No. The AUID remains unchanged. Standardized extensions all have
built-in extensibility.

> (Since, if there's no extensibility space available, replacement 
> would be the only solution.)
> 
> That suggests that clients and servers will become increasingly more
>  complex, or else will lose interoperability.

Unknown information in the XML document (so long as it is in a place
where extensibility is allowed) is just ignored.

>> 3) XCAP is not designed for searching in a real sense.  It is 
>> designed for selecting elements based on known identifiers.  It is 
>> not intended as a general XML Database access methodology.
>> 
>> 
> I see - that's quite a limitation for a generalized configuration 
> access protocol, isn't it? (Certainly IMSP appeared to suggest that 
> personal configuration data can become very large, so retrieving the 
> whole lot in order to search is going to be expensive, hence, as I 
> understand it, many of the features of ACAP.)

XCAP provides a form of searching, where you know specific fields from
the data you want. If I have a list of config parameters, each with a
specific name, I can find the one with that name.

It does not provide a fully flexible, regexp style search - no. Again,
the objective was NOT to be a general purpose config protocol for any
app, but to meet the needs of our existing usages and some likely future
ones. Future extensions to xcap would likely increase its capabilities
for selection operations. Indeed, this is one such proposed extension,
still under discussion:

http://www.ietf.org/internet-drafts/draft-rosenberg-simple-xcap-multiple-00.txt

this would allow you to ask for all entries with attribute "color" equal
to "blue" within a parent and get back the list of all such entries.

> It does seem worrying that reconnection, resync, etc - all operations
> performed quite frequently by potential clients such as MUAs, and I
> assume the kinds of clients SIMPLE deals with - has no solution
> inherent in the standard, nor, as far as I'm able to tell, an
> alternative method mentioned in the specification.

Resync after reconnect is handled by the above SIP event package and 
diff format. You would subscribe, indicate your current version (etag) 
and the diff would come with the changes since then. Its possible that 
the server doesnt remember the version you had, in which case you'd get 
the full dump.

> 
> 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?

-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

---

From: Dave Cridland <[email-masked]>
Date: Tue, 31 Aug 2004 17:45:58 +0100

> would come from a different namespace.
Predefined points? How does the designer know where extension might 
be required?

> understood by the server, will have no validation beyond XML well
Understood, I missed this in my original reading.

> XCAP servers don't do referential integrity checks. This is 
*nods* Found that now. I partly missed it because it's ruled out in a 
sentence running over a page break.

>>  of a reduced XPath has been used rather than simply using XPath 
>> in the URI? (I can't see anyone choosing to handle these URIs in 
>> any way
There does seem to be relatively high complexity already, yes.

>> substanital block of configuration data, and maintain it as 
>> current as reasonably possible, how does an application obtain a 
>> list of changes since a certain time (or ETag)? The only method I 
>> can see is
Ah... So XCAP requires SIP to be of any real use?

> but were not needed for our applications.
In that case I misread the last paragraph of the introduction.

And yes, there are some production deployed ACAP servers out there. 
Not many, but some. For my purposes, which include both email client 
support and datastore for some web applications, it's proven 
extremely effective - much, much faster than the traditional 
solutions of SQL databases, etc.

> 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.

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.)
2) Possibly using this information, acquire SIP.
3) Write any changes using XCAP PUT and DELETE. Since PUT invalidates 
the cache, ignore any result other than success or failure for PUT.
4) Listen constantly for updates via SIP.
5) On reconnect, use acquire SIP using cached data, and then use SIP 
to resynchronize.

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?

What am I missing here?

Dave.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Aug 2004 13:59:42 -0400

If you consider getting change notifications mandatory, I suppose you could 
take that view.
There are other cases where SIP is not being used, and change notification 
is not necessary, that can make use of XCAP.

Yours,
Joel

At 05:45 PM 8/31/2004 +0100, Dave Cridland wrote:
>>>4) Given that, in general, applications will wish to use a substanital 
>>>block of configuration data, and maintain it as current as reasonably 
>>>possible, how does an application obtain a list of changes since a 
>>>certain time (or ETag)? The only method I can see is