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

From: Dave Cridland <[email-masked]>
Date: Fri, 13 Aug 2004 23:00:24 +0100

Brought back on list with author's permission, uncut. This was the 
only reply I received, on or off list.

On Thu Aug 12 15:17:42 2004, Joel M. Halpern wrote:
> We are using XCAP to configure a charging and service control 
> device.  Said device does not care about buddy lists, resource 
> lists, or any other SIMPLE properties.  But it does use XCAP.  It 
> uses a different AUID.
> 
> We do full validation of configuration.  In my view, accepting 
> configuration changes and not validating them is a mistake.  The 
> performance impact is tiny.
> 
> 
The performance impact appears to be potentially substantial - 
referential integrity checks aren't cheap, as far as I'm aware.

My personal view is entirely in agreement with yours, I just disagree 
about where the validation should take place. (On the client when 
receiving the data, as it surely must do anyway.)

But I can happily agree to disagree on this point.

> We did not use an XPATH library.  We used an off the shelf HTTP 
> server, and then wrote our own path parsing logic.  (That is in 
> part because our underlying data representation is not XML.)
> 
> I don't think anyone has looked very hard at whether XCAP could be 
> used for the problem ACAP was trying to address.  At the surface, 
> it does look suitable.
> 
> 
No, I get the impression by the huge difference between ACAP and XCAP 
that nobody at all before me has considered this, yet it says that 
the aims are largely similar in the introduction section, which is 
why I'm more than a little confused. I expected based on that to find 
a reasonable replacement.

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

Forgive my ignorance about XML Schemas... I'm really hoping to be 
utterly wrong on this point. Please, somebody shoot this line of 
reasoning down.

> 2) Each application can specify the validation (beyond schema 
> validation) that it chooses to perform.  Some apps will have very 
> general schemas and no additional requirements.  Some will be very 
> specific.
> 
> 
Excellent, so I can effectively turn it off.

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

> 4) It is not expected that you can get detailed change reporting as 
> part of the XCAP base.  However, an application could use the 
> xml-diff mechanism and have a tree with progressive diffs available 
> if that was desired.  You can also subscribe for notification of 
> changes as they occur, if the server supports such notifications.
> 
> 
Sorry, I'm desperately unfamiliar with any form of notifications 
across HTTP - to tell the truth, I was firmly of the belief there 
were no such mechanisms.

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.

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.

Is the quantity of personal data required for SIMPLE's use 
particularly small and static?

> Just my personal take,
> Joel
I have to admit, at the moment, this doesn't look like an XML 
Configuration Access Protocol, but more like an XML validating editor 
running over HTTP, which seems to me to be a bit different. Useful, 
possibly, for SIMPLE's needs, interesting, certainly, but very 
limited as a general configuration access protocol.

I'd be delighted to be proven wrong, as this appears to be the only 
replacement/successor to ACAP on the cards at the moment.

Dave.

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