Subject: RE: [Simple] XCAP questions

From: [email-masked]
Date: Fri, 13 Feb 2004 13:37:53 +0200

Hi,

Regarding the XCAP directory application usage:

I also like approach 3, as this would make things easiest for the client. A follow-up issue to this: Would it be possible to include also the Etags (or similar version identifiers) for each resource listed in that directory file? In this way the user could only be subscribed to the changes in the directory file (via XCAP-change event), and still learn about all the changes that have occured in any of the resources that he/she owns. 

If we agree that this is the way, I think specifying this new usage would be straightforward, and I can volunteer to provide the first version for it after IETF 59.

Markus 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 12 February, 2004 23:02
> To: Urpalainen Jari (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] XCAP questions
> 
> 
> Sorry for the delay in responding. Thanks so much for your 
> comments and 
> questions. Answers inline.
> 
> Jari Urpalainen wrote:
> 
> > Hi !
> > 
> > I have been developing a reference implementation for XCAP server 
> > (standalone and an Apache module).  There are some 
> open/unclear issues 
> > (to me at least),  so here's the list of questions.
> > 
> > 1. XCAP directory list
> > In XCAP presence auth draft chapter 4.4, there's a 
> requirement to get 
> > all documents from the server. However, in the base XCAP 
> draft it is 
> > unspecified how the server should send this directory list. While 
> > http-servers can/will provide this information in many 
> ways, IMO the 
> > base XCAP draft should specify this format (xml?). 
> Furhermore, it would 
> > be nice if ETags were included in the response in order to help to 
> > synchonize documents between the client and the server.
> 
> In the model I had in my head, the presence server itself 
> didnt use xcap 
> to fetch the documents; that interface was something proprietary. 
> However, if xcap is being used there, you are right that there would 
> need to be a standardized way to obtain the list.
> 
> One way I would suggest for this is to define an application 
> usage which 
> is the "directory" of documents for a specific user. This application 
> usage would specify a single well known place where the 
> document would 
> live. The end user themselves would not need to modify it; the server 
> could set it when the user manages their own documents. This 
> would then 
> be read-only, and visible to either a user or more 
> importantly, to a PE.
> 
> I think this is more or less what Markus has proposed as well. The 
> question is, where does such a definition occur:
> 
> 1. base xcap spec
> 2. as part of each application usage
> 3. a special "directory" application usage
> 
> I prefer (3); we could define this once, and the "directory" would 
> contain information on the documents for a user across all 
> application 
> usages.
> 
> 
> 
> > 
> > 2. XCAP ETags
> > In order to ease the synchronizing within resources between 
> client and 
> > server the base XCAP draft could specify the secure hash 
> method e.g. 
> > SHA-1 or whatever that is used to calculate the ETag. This 
> is already 
> > proposed in xcap-package but IMHO could be in the base spec.
> 
> I don't follow. The etag is purely a server computed value. 
> Generally, 
> there is no need to specify how it is computed. Why does it 
> matter how 
> its computed?
> 
> > 
> > 3. XCAP attributes
> > When updating/querying attributes is it necessary to 
> include attribute 
> > name in payload as attribute name is already provided in 
> XPATH-query ?
> > 
> > e.g. you could get /resource-lists/list[@name="friends"]/@uri
> > so you already know that you receive response for attribute 
> uri. IMHO 
> > when putting/getting attributes, payload could include only 
> attribute 
> > value.
> 
> That can be true as long as the URI can only identify an attribute by 
> name. I can change this as long as we stick to that constraint.
> 
> 
> > 
> > 4. XCAP namespace declarations
> > As namespace handling resemble "standard" XML attributes is it also 
> > allowed to change namespace declarations with similar semantics ?
> 
> Great question. The answer is no. The reason is say that is that in 
> xpath, namespace declarations are treated differently. If you want to 
> get access to the namespaces of an element, you have to use 
> the explicit 
> namespace axis.
> 
> I want to make sure that our URI addressing conventions do 
> not violate 
> or contradict xpath, and so I think they need to be 
> consistent. I will 
> clarify in the draft that the selectors do not apply to namespaces, 
> comments or text content. If we want to be able to access and modify 
> those, we need to expand the scope beyond where we are now. I would 
> prefer not to do that.
> 
> -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
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Feb 2004 11:40:32 -0500

[email-masked] wrote:

> I also like approach 3, as this would make things easiest for the
> client. A follow-up issue to this: Would it be possible to include
> also the Etags (or similar version identifiers) for each resource
> listed in that directory file? In this way the user could only be
> subscribed to the changes in the directory file (via XCAP-change
> event), and still learn about all the changes that have occured in
> any of the resources that he/she owns.

I dont think having the etags in there helps. Changes in the directory 
file would not contain the changes in the actual documents. As such, the 
client would know about the change, but knowing the new etag doesnt help 
- it would still have to do a get of the document to find out what changed.

There IS value, however, in including etags in the xcap-event package, 
so that the client can apply the diff, verify it, know the new etag, and 
any PUTs it would do would be against that new etag.

> 
> If we agree that this is the way, I think specifying this new usage
> would be straightforward, and I can volunteer to provide the first
> version for it after IETF 59.

Great!

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Feb 2004 11:40:32 -0500

Great!

-Jonathan R.