Re: [Simple] Some thoughts on XCAP's resource architecture

I am not sure I follow all of the concerns you are raising, and I could 
easily be missing some important point.

However, we have implemented an XCAP server using an off-the-shelf HTTP 
server as a starting point.  We did not have to do significant violence to 
the HTTP code to support XCAP, the XCAP granularity, or the XCAP 
dependency.  (The places we had dependency issues had nothing to do with 
XCAP, but rather were simply that sometimes setting configuration 
information has side effects.)

We probably could also handle it if the path were moved into the 
parameters.  Hawever, the earlier discussion indicated that would not be a 
good idea.  Moving the path into a different HTTP parameter would be a very 
bad idea from my perspective.  It would be tantamount to treating HTTP as a 
transport for a non-HTTP protocol.  The fact that I can currently use a 
standard browser to get XCAP information, and a browser with PUT support 
can be used to update information is a feature, and one we should try to 
preserve.

Yours,
Joel M. Halpern

At 09:58 PM 11/21/2004, Lisa Dusseault wrote:
>During the DC IETF, I expressed some reservations about XCAP to Ted and 
>Jonathan. Jonathan asked me to send a message to the SIMPLE list with my 
>comments, so here it is...
>
>Based on the mailing list on the traffic, it appears that  XCAP is 
>supposed to be an extension or profile of HTTP, rather than just a 
>protocol that mimics the HTTP interaction style, and that as such it is 
>intended to be compatible with other extensions of HTTP.  I'm concerned 
>that the current architecture of XCAP makes this difficult.  In particular 
>the XCAP resource ontology and the URL addressing style that goes with it 
>shifts the HTTP design along two major axes:
>
>1) Resource granularity
>2) Dependency between resource

Received on Monday, 22 November 2004 14:52:42 UTC