Subject: Re: [Simple] XCAP questions

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Feb 2004 16:02:11 -0500

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Feb 2004 16:02:11 -0500

1. base xcap spec

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 13 Feb 2004 10:49:30 +0200

Thanks for your answers, comments inline.

> contain information on the documents for a user across all application 
Option 3 sounds reasonable although it's a bit more complex to implement
than a simple directory list.
> there is no need to specify how it is computed. Why does it matter how 
Sorry for not being too clear on this. Actually the problem i see is
that e.g. with xcap resource-lists the server should add empty list
uris. So what's the most reasonable way for the client to detect that
the server has added them ? 

The first option might be that the client "knows" this resource-list
behaviour and it queries after some put operation all the empty uris.
This may lead to quite many round-trips and what's more, this is very au
related i.e. not very generic. 

The second option could be that the client subscribes (xcap-package) to
this document and gets those add-ons made by server from the
notifications. IMHO, this sounds a bit too heavy for this sort of simple
operation... 

The third option could be that when doing put transaction the server
would reply within the reply payload all the stuff it has added. The
response should have it's own mime-type. I am perfectly aware that it is
all but "standard" http put behaviour but it would be efficient.

> name. I can change this as long as we stick to that constraint.
fine.
> those, we need to expand the scope beyond where we are now. I would 
I fully agree that the attribute selectors should exclude namespaces.
However, adding comments would be sometimes nice but it can certainly be
left for future improvements.

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 13 Feb 2004 10:49:30 +0200

fine.

BR,
Jari

---

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

inline.

> than a simple directory list.

You mean, to have a specific document that lists the documents in each 
directory? You'd still need to do a full tree traversal though in such a 
case. With one signle document, you would do one xcap fetch for the 
whole thing.

> behaviour and it queries after some put operation all the empty uris.

This is what I had in mind.

> This may lead to quite many round-trips

I admit its a weakness, yes. But I dont expect people to be defining new 
lists all that often, as opposed to members of specific lists.

The xcap-package could also be used to notify the client of the change.

> and what's more, this is very au

Well, the client may already be doing that anyway.

> all but "standard" http put behaviour but it would be efficient.

Right. The non-standard part is a serious, serious concern. One of the 
major reasons that keeping this a pure http usage has been so important, 
is to reuse http client code on existing handsets. If we do something 
like this which would change that, then you've defeated much of the 
purpose in xcap's design.

I welcome other ideas...

> left for future improvements.

You can have them, you just won't be able to directly address them to 
change them by themselves. You'd have to modify them by sending the full 
element that surrounds them.

-Jonathan R.

---

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

inline.

I welcome other ideas...

-Jonathan R.