Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments

From: Scott Lawrence <[email-masked]>
Date: Mon, 10 Nov 2003 10:27:42 -0500

Jonathan Rosenberg <[email-masked]> writes:

> It had also been proposed to simply continue to use the "/" hierarchy all
> the way down into the XML document, i.e.:
>
> http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/
>    resource-list[@id="assd99"]
>
> where the last two components of the path identify XML elements. I didnt
> like this, since practically speaking, implementations are likely going to
> want to use the filesystem or DB to retrieve a specific document, and then
> use some XML processing to retrieve an element or attribute. So, knowing
> where the breakpoint is in the URI is helpful, I think.

I prefer the path approach, actually, specifically because it hides
the implementation detail - that's none of the clients business, and
the server side can do the split anyway.  In your example, any of
'xcap.server.com', 'resource-lists', or 'users' would be natural path
elements to choose as the one that invokes a database lookup based on
the remaining path information (which the server makes available
anyway as the CGI variable PATH_INFO).  Why should the client be able
to tell which way I chose?  Why should I have to stick to that choice?

-- 
Scott Lawrence        
  Pingtel Corp.   

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

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 10 Nov 2003 10:27:42 -0500

-- 
Scott Lawrence        
  Pingtel Corp.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 03:39:34 -0500

inline.

Scott Lawrence wrote:

> the server side can do the split anyway.

I suppose, though it would be nice if there was a clean separator to 
help that. With the path approach, the server has to know, through 
configuration or otherwise, where the break is. That may not be a big 
deal.

However, there is another issue which may really require us to go this 
way. Its something you pointed out previously, and which Lisa talked 
to me about tonight. PRoxies and caches are very likely to be confused 
by the parameters in the GET, since they are sometimes stripped in the 
process of caching. Worse yet, you mentioned that some servers will be 
confused, or possibly not support, query parameters in PUT. If it 
doesnt work with existing servers, proxies or caches, thats a 
show-stopper to me.

So, I am inclined to go for the path approach for this reason.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 03:39:34 -0500

inline.

Thanks,
Jonathan R.