Subject: [Simple] Comments on xcap-01

From: [email-masked]
Date: Tue, 4 Nov 2003 16:21:41 +0200

Overall, I think the document is ready. Some minor comments:

- Resource Interdependency: After a server has populated a element or attribute, like the URI for a list, how does this information get communicated to the client (how does the client learn of such information)? Does the server fill it in before the 200 Ok is returned and body of the response contains the xml document (I don't think this is a good solution)?

- Creating a new document: must the document have file type of .xml? In the example in section 6.1, should mybuddies be mybuddies.xml?

- Content-type: I think defining a content-type for xcap is needed for creating/replacing elements and attributes. It is better than using text/plain as currently shown in the examples.

- Replacing an element/attribute: It might be useful to indicate that modifying an element value of an element is not possible, especially if that element has attributes. The whole element, including its attributes must be replaced.

- E-tags: If an element or attribute has been replaced or deleted, how does a client learn of such change? A client can never learn of a change unless is performs a GET and examines the etag. BTW, whatever happened to the event package for xcap?

Regards,
Hisham

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

---

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

inline.

[email-masked] wrote:

> - Resource Interdependency: After a server has populated a element
> or attribute, like the URI for a list, how does this information
> get communicated to the client (how does the client learn of such
> information)? Does the server fill it in before the 200 Ok is
> returned and body of the response contains the xml document (I
> don't think this is a good solution)?

No. The client would do a separate GET afterwards. This is not clear. 
I tried to add some text on it, but I think its not there yet.

> 
> - Creating a new document: must the document have file type of
> .xml? In the example in section 6.1, should mybuddies be
> mybuddies.xml?

I dont think it matters that much, as long as we are clear whether the 
extension should be there or not. My leaning is towards yes.

> 
> - Content-type: I think defining a content-type for xcap is needed
> for creating/replacing elements and attributes. It is better than
> using text/plain as currently shown in the examples.

I would be inclined to use application+xml whenever the body is a 
valid XML document, which is all cases except where you are fetching 
or putting attributes. In those cases, text/plain seems reasonable. I 
dont see what value we gain in registering a new MIME type.

> 
> - Replacing an element/attribute: It might be useful to indicate
> that modifying an element value of an element is not possible,
> especially if that element has attributes. The whole element,
> including its attributes must be replaced.

OK, will do.

> 
> - E-tags: If an element or attribute has been replaced or deleted,
> how does a client learn of such change? A client can never learn of
> a change unless is performs a GET and examines the etag. 

This is a good question. Jari had a similar one, and I'll discuss in a 
reply to that mail.

> BTW,
> whatever happened to the event package for xcap?

I didnt rev it. I think its much more controversial. There are big, 
hard questions, like whether or not this is the same or different as 
the config framework package. Indeed, I would propose that we should 
move forward with the main xcap spec and the list and auth packages 
first, and work on the event package separate.

-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:15:11 -0500

inline.

OK, will do.

-Jonathan R.