Subject: [Simple] A proposal for fixing the xcap schema problem and related issues

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Oct 2005 01:19:12 -0400

Folks,

There was some debate about a month back about a problem identified in 
XCAP regarding namespace handling, coming out of some experiences in 
OMA. The specific mail that reported this problem can be found here:

http://www1.ietf.org/mail-archive/web/simple/current/msg05675.html

The quick summary is that, for implementations that don't normally store 
the entire XML document locally on the client, a GET or PUT of a 
fragment of the document is problematic, since the in-scope namespace 
bindings for that fragment won't be known. This makes it impossible to 
interpret the results of a GET, or to formulate the namespace prefixes 
in the content of the PUT so the resulting document is valid.

Several options were proposed, including OMA-specific fixes, revising 
xcap, or defining some extensions. I'd like to make a concrete proposal 
on how to move forward here.

Firstly, I think this problem needs to be addressed in IETF, and needs 
to be fixed in a way that is not specific to the OMA use cases. It has 
been an objective of xcap from its start that it be possible to perform 
manipulations on a document without the full document cached. Section 
5.10 of the -07 xcap draft talks about schema design guidelines that 
allow for xcap to work without having the document cached, for example. 
The problem reported by Per Hyttfors will affect any usage for which 
non-caching operation is needed, and will make any such usage cumbersome 
if not impossible. As such, it is not OMA specific, and I consider it a 
bug in the specification.

For this reason, my proposal is to ask IESG to remove xcap from the 
rfc-editor queue, so that I can issue an update to the draft that fixes 
this problem.

My proposal to fix the problem is to follow the recommendation made by Jari:

http://www.ietf.org/mail-archive/web/simple/current/msg05710.html

I would update the grammar of the node selector to allow for 
namespace::*. Such a selector would select the namespace bindings in 
scope for the element in question. xcap would define a format for 
encoding those namespace bindings; basically, an xml fragment body with 
one element, the local name of the element in question, with xmlns and 
xmlns: attributes for each of the namespaces in scope, including the 
default.

For example, consider this document:

    <?xml version="1.0" encoding="UTF-8"?>
    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <service uri="sip:marketing at example.com">
       <a:list name="marketing">
         <a:entry uri="sip:joe at example.com"/>
         <a:entry uri="sip:sudhir at example.com"/>
       </a:list>
       <packages>
         <package>presence</package>
       </packages>
     </service>
    </rls-services>

The following query:

GET 
http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/namespaces::*

would return:

    <service xmlns="urn:ietf:params:xml:ns:rls-services"
       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>

This fixes the problem by allowing the client to get the in-scope 
bindings, and cache them, so they can be used to interpret subsequent 
GETs, and then used to create the namespace prefixes for elements in 
subsequent PUTs. Of course, the client needs to be sure that the cached 
namespace bindings havent changed prior to the PUT; the mechanisms in 
section 7.10 of XCAP apply here as normal.

I did investigate a few other solutions to the problem. In particular, I 
looked to see if the XML fragment interchange:

http://www.w3.org/TR/xml-fragment

could be used as a solution. The idea is that you could GET an element, 
and if you specify the MIME type for a "fragment with context format" in 
the Accept header, the server could return the element along with its 
context instead. Turns out, the XML format defined in the TR above only 
defines the fragment CONTEXT; there is no w3c-defined mechanism to 
convey an element along with its context. As such, we'd have to define 
it ourselves. I'd rather not do that, since its something better suited 
for w3c to do. I'd also rather stick with xpath-based approaches, rather 
than introduce yet another new piece of XML technology for this one problem.

Several other problems have been reported with the xcap specification 
since its approval, and I would propose that these also be addressed 
while I am revising the document. Specifically:

1. XCAP currently doesn't allow extensibility for the node-selector 
itself. This means that, as currently defined, we couldn't even formally 
define the above fix as an extension, even if we wanted to. Other 
possible node-selector extensions, such as:

http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-multiple-00.txt

would also not be formally possible as extensions.

This is relatively easy to fix; it requires the grammar for 
node-selector to add points of extensibility, and for some text to 
indicate that servers reject, with a 404, expressions they don't 
understand. Extensions to xcap that define a new node-selector would 
define an extension name for themselves. A client can then discover 
support for this new extension using the xcap-caps document as currently 
defined.

2. Jari has reported some areas of underspecification around insertions. 
In particular, how insertions are done relative to whitespace and 
comments. The proposal would be to add some text that specifies that in 
these cases, element insertions happen before whitespaces or comments.

3. XCAPs usage of directory structures between the username and the ~~ 
is very underspecified, and some interop problems have been reported. 
The lack of an ability to create sub-directories further complicates 
this. I'd propose to fix this by making it a responsibility of the 
application usage to define a well-known convention for constructing 
this component of the document selector, and recommend that no 
sub-directories be used at all. Rather, just documents right in the 
user's home directory. Furthermore, for application usages with just a 
single document, that this document be called "index".

4. A couple of nits have been reported, the worst of which are some 
extraneous double-quotes in the xmlns() xpointer expressions. I'd fix 
these too.

I would propose we limit the changes to xcap to these five items (the 
main problem plus the four above), and no more.

I don't know if the scope of changes here require a re-do of both WGLC 
and IETF last call, and/or re-do of approval from IESG. I would hope 
not, but this is something we need to discuss with Ted.

If the working group agrees with this direction, I will commit to a 
revision of xcap with these changes prior to the non-00 deadline for 
Vancouver. As such, please reply with comments ASAP, since time is 
running out (October 24!).

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Oct 2005 10:21:31 -0400

> single document, that this document be called "index".

Would it make sense to use the AUID as the file name? This avoids having 
to maintain and avoid collisions in yet another namespace that looks 
similar.

Example:

PUT /bill/resource-lists

In addition, the user name part is currently underspecified. There seems 
to be an implicit assumption that one XCAP server server serves exactly 
one domain, so that somehow the 'bill' above is related to whatever host 
the server runs on. (In the examples, this would be 
[email-masked], but that's probably not what's intended.)

We have enough of a configuration mess at our hands without adding more 
unspecified linkages that must be resolved through some unknown 
mechanism that may or may not be universally deployed. I think the most 
sensible mechanism is to use the same NAPTR/SRV mechanism, even though 
that's not part of the standard HTTP resolution mechanism.

Henning

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 08 Oct 2005 10:46:08 -0400

I would normally be reluctant to pull anything off of the RFC-Editor queue.
However, your comment (not reproduced below) that the current grammar makes 
extension impossible probably means we need at least some repair so that we 
can fix problems we find later.

With regard to the specific solution proposed, I have a couple of minor 
questions:

1) If the element the client is targeting is from some namespace (I believe 
definitionally true) doesn't the client need to fetch progressive namespace 
bindings in order to be able to ask the final binding question 
properly?  Or can the client make simplifying assumptions that are good 
enough to get the binding, but not good enough to write replacement elements?

2) With regard to the specific syntax, I think that if we use it we will 
need some more explanation.  Looking at the XPath spec, it becomes clear 
that namespace::* is the alternative to asking about a specific 
namespace.  In our usage that specific form is not needed.  The limited 
syntax is somewhat odd (no problem for computers, but humans will look and 
ask "why the *?)  So I would recommend that we put in some explanatory text 
as to what the meaning of the syntax is, without the reader needing to go 
look at the XPath specification.

3) If I am reading things right, we are inventing the syntax to return for 
a namespace::* reference in an XCAP specifier.  The example makes clear 
what the expected syntax is.  I think this is the right syntax.  We will 
however need to clearly describe that.  (I looked through the XPath 
specification, and the result of a namespace::* is defined only in terms of 
the logical structure.  And that structure is actually a collection of 
namespace nodes without the parent element. And the namespace nodes are 
simply the logical pair of local part for the namespace prefix and a 
string-value of the namespace URI.)

Yours,
Joel M. Halpern

At 01:19 AM 10/8/2005, Jonathan Rosenberg wrote:
>I would update the grammar of the node selector to allow for namespace::*. 
>Such a selector would select the namespace bindings in scope for the 
>element in question. xcap would define a format for encoding those 
>namespace bindings; basically, an xml fragment body with one element, the 
>local name of the element in question, with xmlns and xmlns: attributes 
>for each of the namespaces in scope, including the default.
>

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 11 Oct 2005 14:17:38 +0300

It is unfortunate that we have to fix these bugs, but it is still imo 
better than to start xcap-bis. Some comments inline.

ext Jonathan Rosenberg wrote:

> The quick summary is that, for implementations that don't normally 
> store the entire XML document locally on the client, a GET or PUT of a 
> xcap, or defining some extensions. I'd like to make a concrete 
> proposal on how to move forward here.
>
> been an objective of xcap from its start that it be possible to 
> perform manipulations on a document without the full document cached. 
> Section 5.10 of the -07 xcap draft talks about schema design 
> guidelines that allow for xcap to work without having the document 
> cached, for example. The problem reported by Per Hyttfors will affect 
> any usage for which non-caching operation is needed, and will make any 
> such usage cumbersome if not impossible. As such, it is not OMA 
> specific, and I consider it a bug in the specification.
>
> rfc-editor queue, so that I can issue an update to the draft that 
> fixes this problem.
>
> encoding those namespace bindings; basically, an xml fragment body 
> with one element, the local name of the element in question, with 
> xmlns and xmlns: attributes for each of the namespaces in scope, 
> including the default.
>
typo namespace::*

>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
out-of-scope comment, but I'd rather remove all references to 
schema-instance hints from any of the example instance documents.

> subsequent PUTs. Of course, the client needs to be sure that the 
> cached namespace bindings havent changed prior to the PUT; the 
> mechanisms in section 7.10 of XCAP apply here as normal.
>
> I did investigate a few other solutions to the problem. In particular, 
> I looked to see if the XML fragment interchange:
>
> could be used as a solution. The idea is that you could GET an 
> element, and if you specify the MIME type for a "fragment with context 
> format" in the Accept header, the server could return the element 
> along with its context instead. Turns out, the XML format defined in 
> the TR above only defines the fragment CONTEXT; there is no 
> w3c-defined mechanism to convey an element along with its context. As 
> such, we'd have to define it ourselves. I'd rather not do that, since 
> its something better suited for w3c to do. I'd also rather stick with 
> xpath-based approaches, rather than introduce yet another new piece of 
> XML technology for this one problem.
>
> itself. This means that, as currently defined, we couldn't even 
> formally define the above fix as an extension, even if we wanted to. 
> Other possible node-selector extensions, such as:
>
> support for this new extension using the xcap-caps document as 
> currently defined.
>
> 2. Jari has reported some areas of underspecification around 
> insertions. In particular, how insertions are done relative to 
> whitespace and comments. The proposal would be to add some text that 
> specifies that in these cases, element insertions happen before 
> whitespaces or comments.
>
There's actually two issues here: one with positional inserts and 
secondly whitespace text node handling in general. While I proposed that 
new element inserts should be put at the first possible position, 
there's at least one corner case that should be clearly specified, i.e.:
<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <person/>
</presence>
When you e.g. add <device> with put .../presence/device the current spec 
clearly mandates that <device> is the last child of  <presence>. 
However, if you put ../presence/device[1] the interpretation might be 
that <device> is the first child of <presence>. Whatever the model 
adopted in xcap, it should just be clearly expressed what's the meaning. 
A second example is when you'll put ../presence/tuple[3], using the 
first possible position imo seems to be the most reasonable, i.e. ending 
up with:
<presence>
  <tuple id="p1"/>
  <tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
Now I am assuming that xcap cannot put several siblings at the same time 
and there's not any magic handling of whitespace text nodes.  Then we 
might want to delete .../presence/tuple[@id="p1"]. XPath datamodel says 
that a text node cannot have another text node as a sibling node. So we 
should end up having a doc like this:
<presence>
  
  <tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
so the two whitespace text nodes have been catenated together. Then 
again we could delete the first text node child of <presence> with 
delete .../presence/text()[1] ending up with:
<presence><tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
or we could have replaced the first text node with put 
../presence/text()[1]  (pl: linefeed with two spaces):
<presence>
  <tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
This would mean adding text() function to the BNF. However, I cannot 
imagine any reasonable way to add a whitespace text node between those 
two tuples. So I am NOT proposing to add text() function to the BNF,  
just trying to clarify the issue. And what's the issue actually ?  The 
canonical format of the document must be predictable, this means that 
some whitespace text nodes are meaningful (xml:space="preserve" is the 
default btw.). So I am just proposing that xcap spec just describes this 
issue, too.

> single document, that this document be called "index".
Actually in my reference implementation I've have done this "automatic" 
sub-directory creation (in users "home" dir) and I still havn't figured 
it out whether there are any issues out there or not. Of course e.g. 
webdav has mkcol method for this.

> extraneous double-quotes in the xmlns() xpointer expressions. I'd fix 
good. Also it might be worth noting that within location steps 
apostrophes (') can be used too (like in XPath).

> not, but this is something we need to discuss with Ted.
I'll also hope that these fixes can be done with the easiest possible 
effort.

> running out (October 24!).

thanks,
Jari

---

From: Sebastian Ley <[email-masked]>
Date: Tue, 11 Oct 2005 14:25:38 +0200

* Jari Urpalainen wrote:

> it out whether there are any issues out there or not.

I think in that case the specification needs to clarify if there may be a 
document and a subdirectory with the same name in a given directory.

Since the concept of a directory is borrowed from filesystems that does not 
seem to make sense, but non-filesystem implementations might have no problem 
having a directory and a document with the same name. And since the document 
selector in XCAP always selects a document and never a directory there is no 
ambiguity there either.

In an implementation I mapped the whole document-selector to a key in an XML 
database. In that case there may be very well a directory and a document with 
the same name in a given directory. When doing a filesystem implementation, 
that gets rather difficult though...

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 12 Oct 2005 09:58:17 +0300

>that gets rather difficult though...
Yes there are filesystems that certainly disallows having the same file 
& directory names. However, I have thought that this is more like an 
implementation issue but you are right it is certainly worth mentioning 
if it were allowed.

As a side question (for curiosity reasons), how does the xml db you are 
using store xml prolog data, e.g. xml entities ?
thanks,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 01:56:59 -0400

inline.

> to maintain and avoid collisions in yet another namespace that looks 

Thats really not much different that requiring the application usage to 
specify a convention. The latter leaves some flexibility in case 
multiple documents are needed, so I prefer that.

> [email-masked], but that's probably not what's intended.)

No, its not whats intended.

The issue is there in sip too; the username portion of the digest 
credentials could be "bill", and the realm "server.example.com", but 
this doesnt mean that the URI in the From or P-Asserted-ID would be 
sip:[email-masked]. Rather, the SIP URI would be based on a 
provisioned mapping of the two (private to public ID in IMS terminology).

XCAP says more or less the same thing; there is a provisioned mapping on 
the server from authenticated identity of the http client, to the XUI. 
The client has to know it as another piece of configuration.

> that's not part of the standard HTTP resolution mechanism.

I'm not sure what NAPTR has to do with it...

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 02:10:00 -0400

inline.

Joel M. Halpern wrote:

> However, your comment (not reproduced below) that the current grammar 
> makes extension impossible probably means we need at least some repair 
> so that we can fix problems we find later.

Well, I wouldnt say impossible, so much as unclear. The HTTP URI grammar 
is itself extensible, so nothing stops me from constructing an http URI 
that adds something that isn't defined in xcap itself. The server would 
presumably send a 404, whcih is the right thing in any case. The issue 
is mostly that its not directly addressed, and this may lead to problems 
with folks not anticipating such extensions.

> 1) If the element the client is targeting is from some namespace (I 
> believe definitionally true) doesn't the client need to fetch 
> progressive namespace bindings in order to be able to ask the final 
> binding question properly?  Or can the client make simplifying 
> assumptions that are good enough to get the binding, but not good enough 
> to write replacement elements?

There are two issues here. One is, how do you construct the namespace 
prefixes in the URI itself, and the other is, when doing a PUT, how do 
you construct the namespace prefixes in the XML content in the body.

You are talking about the latter issue in your question. That is 
addressed in section 6.4 of xcap, which allows the client to specify the 
bindings used in evaluating the URI. THus, the client doesnt need to 
know what bindings the server has; it only needs to know the namesapce 
URIs themselves, which it will.

For the former issue, constructing the prefixes in the body of the XML 
document, you HAVE to use ones valid on the server, otherwise the server 
won't validate the document (unless you start asking the server to map 
the prefixes, which requires modifying the document itself - yuck). 
Thats why the client needs to know whats in use on the server here, but 
not in the former case.

> namespace. 

No, thats not what it means. It means that you select all children of a 
node along the namespace axis. In other words, you select a set of 
objects which represent all of the namesapces in scope for that object.

> In our usage that specific form is not needed.  The limited 
> syntax is somewhat odd (no problem for computers, but humans will look 
> and ask "why the *?)  So I would recommend that we put in some 
> explanatory text as to what the meaning of the syntax is, without the 
> reader needing to go look at the XPath specification.
> 
> 3) If I am reading things right, we are inventing the syntax to return 
> for a namespace::* reference in an XCAP specifier. 

Yes. I looked around for something canned already, and didnt find anything.

> The example makes 
> clear what the expected syntax is.  I think this is the right syntax.  
> We will however need to clearly describe that. 

Yes, I would need to define a schema for it and include it in the 
revised xcap spec.

> (I looked through the 
> XPath specification, and the result of a namespace::* is defined only in 
> terms of the logical structure.  And that structure is actually a 
> collection of namespace nodes without the parent element. And the 
> namespace nodes are simply the logical pair of local part for the 
> namespace prefix and a string-value of the namespace URI.)

Interestingly, xpath selections are ONLY defined in terms of the logical 
document structure. XCAP is currently saying that you can select an 
element or an attribute, and then we are defining a way to represent a 
single element or attribute with the two mime types we have. What I'm 
proposing here is to add another thing you can select - namespaces - and 
then we'll define a syntax for that too.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 03:04:12 -0400

inline.

> schema-instance hints from any of the example instance documents.

OK....

> new element inserts should be put at the first possible position, 

actually, the current text says this:

    When the client does not explicitly indicate a position in which to
    insert a new element, the server will insert that element as the last
    child of that parent.  If this is not the desired position, the
    client should perform a positional insertion.

> adopted in xcap, it should just be clearly expressed what's the meaning. 

Right. The current text is inadequate. I think that a few more words 
actually make it much more crisp. Namely, that, when the insertion is 
done, it is done such that two properties exist. Firstly, after 
insertion, the HTTP URI selects that element. Secondly, if the element 
can be inserted before a sibling (whether that sibling be another 
element, whitespace, or a comment) or after it, and still meet the first 
criteria, it MUST be inserted after it. Put more simply, the inserted 
element appears as far down the list of children of the parent as 
possible while still satisfying the idempotency property.

This is a generalization of whats in there now, but covers these other 
cases you've raised. So, in the example above, if you insert 
presence/device[1] and the content of the request is <device id="aa"> 
after insertion you'd have:

<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <person/>
<device id="aa"></presence>

Notice how it comes AFTER the whitespace that was there.

>  <tuple id="p2"/><tuple id="p3"/>

With my proposal it would be:

<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <person/>
<tuple id="3"></presence>

which is wrong. You'd have to do a put of ../presence/*[3] and then 
you'd get:

<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <tuple id="3"><person/>
</presence>

which is valid.

What you are proposing, of inserting in the first possible position, 
would allow for insertions of the form ../parent/element[pos] to have 
the effect of keeping together elements of the same name. Thats all 
fine, except its not consistent with whats in the current spec. Thus, 
changing it would break backwards compatibility. Since this would be a 
feature enhancement as opposed to a bug fix, I think we need to keep it 
consistent.

> that a text node cannot have another text node as a sibling node.

Right, only because you clump it all together into a single text node.

> So we 
> so the two whitespace text nodes have been catenated together. 

Right - deletes JUST delete the element, not any whitespace around it, 
and the xpath data model would then concatenate the whitespace together 
into a single logical text element.

Then
> delete .../presence/text()[1] ending up with:

THis is not supported.

> two tuples. So I am NOT proposing to add text() function to the BNF,  

With the change I am proposing around extensibility, one could define 
such a thing as an extension.

> default btw.). So I am just proposing that xcap spec just describes this 

Agree. I think my text above on insertion covers that case. The section 
on deletion also needs to mention that it ONLY deletes the elment, and 
not surrounding whitespace.

> webdav has mkcol method for this.

We don't allow for creating subdirectories within the xml doc either, so 
I dont think we should allow it outside of it. For example, if you have 
a doc:

<test>
   <doc/>
</test>

and do PUT ..test/doc/add/two/

this WOULD NOT result in:

<test>
   <doc>
     <add>
       <two/>
     </add>
   </doc>
</test>

rather it generates an error.

I'd prefer to simply discourage directories.

> apostrophes (') can be used too (like in XPath).

What is the meaning of it? I'm not familiar with that.

> I'll also hope that these fixes can be done with the easiest possible 

So do I....

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 03:05:46 -0400

I see no benefit in allowing the document-name and directory-name to be 
the same, but I see possible drawbaks with implementations which DO use 
the underlying filesystem. So, I would prefer to disallow.

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 21 Oct 2005 11:36:01 +0300

ext Jonathan Rosenberg wrote:

> feature enhancement as opposed to a bug fix, I think we need to keep 
> it consistent.
>
ok, so you are saying that the position for e.g. for a new element is 
the last possible one. That's fine with me as well, because it's 
unambiguous. The minor issue is that in the implementation you'll anyhow 
have to find first the first possible location, now with your proposal 
an implementation has to look for the next (and the last) possible node 
positions. For the implementation it should not be a major issue, however.

>
>> Now I am assuming that xcap cannot put several siblings at the same 
>> time and there's not any magic handling of whitespace text nodes.  
>> Then we might want to delete .../presence/tuple[@id="p1"]. XPath 
>> datamodel says that a text node cannot have another text node as a 
>> sibling node.
>
>
>> So we should end up having a doc like this:
>> <presence>
>>  
> and the xpath data model would then concatenate the whitespace 
> together into a single logical text element.
>
>
> Then
>
>> imagine any reasonable way to add a whitespace text node between 
>> those two tuples. So I am NOT proposing to add text() function to the 
>> BNF,  
>
>
>> just trying to clarify the issue. And what's the issue actually ?  
>> The canonical format of the document must be predictable, this means 
>> that some whitespace text nodes are meaningful (xml:space="preserve" 
>> is the default btw.). So I am just proposing that xcap spec just 
>> describes this issue, too.
>
>
> Agree. I think my text above on insertion covers that case. The 
> section on deletion also needs to mention that it ONLY deletes the 
> elment, and not surrounding whitespace.
>
good.

>>
>>> 3. XCAPs usage of directory structures between the username and the 
>>> ~~ is very underspecified, and some interop problems have been 
>>> reported. The lack of an ability to create sub-directories further 
>>> complicates this. I'd propose to fix this by making it a 
>>> responsibility of the application usage to define a well-known 
>>> convention for constructing this component of the document selector, 
>>> and recommend that no sub-directories be used at all. Rather, just 
>>> documents right in the user's home directory. Furthermore, for 
>>> application usages with just a single document, that this document 
>>> be called "index".
>>>
>> Actually in my reference implementation I've have done this 
>> "automatic" sub-directory creation (in users "home" dir) and I still 
>> havn't figured it out whether there are any issues out there or not. 
>> Of course e.g. webdav has mkcol method for this.
>
>
> We don't allow for creating subdirectories within the xml doc either, 
> so I dont think we should allow it outside of it. For example, if you 
> have a doc:
>
> <test>
>   <doc/>
> </test>
>

ok, too.

>>> extraneous double-quotes in the xmlns() xpointer expressions. I'd 
>>> fix these too.
>>>
>>>
from XPath spec:
"Within expressions, literal strings are delimited by single or double 
quotation marks, which are also used to delimit XML attributes. To avoid 
a quotation mark in an expression being interpreted by the XML processor 
as terminating the attribute value the quotation mark can be entered as 
a character reference (|&quot;| or |&apos;|). Alternatively, the 
expression can use single quotation marks if the XML attribute is 
delimited with double quotation marks or vice-versa."

in xcap these could appear within docs or r-uri's, so it should be imo 
described someway.
thanks,
Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Oct 2005 07:22:59 -0400

Thank you for the reply.
Given that we are already defining report syntax for a number of things, 
this makes sense to me.

Is this syntax permitted on a PUT operation?  (I don't think so.)

Yours,
Joel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 10:26:01 -0400

No, it would be disallowed in PUT. I'll have to say that.

-Jonathan R.

Joel M. Halpern wrote:

>> Interestingly, xpath selections are ONLY defined in terms of the 
>> logical document structure. XCAP is currently saying that you can 
>> select an element or an attribute, and then we are defining a way to 
>> represent a single element or attribute with the two mime types we 
>> have. What I'm proposing here is to add another thing you can select - 
>> namespaces - and then we'll define a syntax for that too.
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Oct 2005 12:01:26 -0400

> multiple documents are needed, so I prefer that.

So far, flexibility has bought us an utter configuration mess and 
significant implementation and interop complexity, so I'm less convinced 
of the trade-off.

> The client has to know it as another piece of configuration.

You will not be surprised to hear that I find "yet another piece of 
configuration" wholly unsatisfactory. Why can't we make a determination 
that does not require yet more configuration, provisioning and all the 
other "flexibility" that cause existing systems to not work out of the box?

I'd rather not restrict the use of SIP to IMS and similar 
professionally-managed systems.

> 
>>
>> We have enough of a configuration mess at our hands without adding 
>> more unspecified linkages that must be resolved through some unknown 
>> mechanism that may or may not be universally deployed. I think the 
>> most sensible mechanism is to use the same NAPTR/SRV mechanism, even 
>> though that's not part of the standard HTTP resolution mechanism.
> 
> 

Getting from a user name to the XCAP URL. I want to have a simple, 
well-defined, deterministic, non-configured means of determining the 
XCAP URL once I have a user name.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 13:38:30 -0400

inline.

Henning Schulzrinne wrote:

>>> Example:
>>>
>>> PUT /bill/resource-lists
>>
>>
>>
>> Thats really not much different that requiring the application usage 
>> to specify a convention. The latter leaves some flexibility in case 

Well, my view as you know is we are well beyond the point of being able 
to usefully have a SIP UA that requires no other configuration beyond 
its username and password. So, once you think that there will need to be 
somethng to provide configuration anyway (via config framework or just 
ftp-d at startup or whatever), adding more to it has zero cost. That 
said there is no point in needless configuration, I agree.

>> XCAP says more or less the same thing; there is a provisioned mapping 
>> on the server from authenticated identity of the http client, to the 
>> XUI. The client has to know it as another piece of configuration.
> 
> 
> configuration" wholly unsatisfactory.

Yup, I'm not surprised ;)

> Why can't we make a determination 

I welcome a proposal.

> XCAP URL once I have a user name.

So, you are proposing something like this - that each user has their sip 
AOR (sip:user@domain). THey'd do a NAPTR lookup of the domain to 
retrieve their xcap server, and then construct the xcap request by 
taking the host learned from it, and using the user part of the aor as 
the xuid? Is that right?

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Oct 2005 18:41:02 -0400

> its username and password. So, once you think that there will need to be 

I think this wouldn't have to be the case, at least for default 
operation (and no outbound proxy). What would one really *need* beyond that?

> said there is no point in needless configuration, I agree.

Each new identifier space brings with it possible confusion, 
particularly since implementors seem to be unable to use consistent 
terminology. Thus, having application IDs that are different from the 
directory will just lead to misconfiguration, with no discernible 
benefit. Those rate "applications" that need multiple documents can just 
use multiple identifiers.

>> Why can't we make a determination that does not require yet more 
>> configuration, provisioning and all the other "flexibility" that cause 
>> existing systems to not work out of the box?
> 
> 
> I welcome a proposal.
> 

I made one: directory/file name === AUID (depending on how the default 
structure.

By default, the XUI should be equal to the public ID, i.e., the AOR. 
(This is most likely the only correct behavior if we allow third parties 
to access other XUIs.)

If some configuration wants to override this, fine, but by providing a 
default, things work without configuration and for (a/the) common case.

> taking the host learned from it, and using the user part of the aor as 

Almost. I'd use the NAPTR approach in the way you describe but, but then 
use the AOR as-is as the XUI. This works if several hosts share the same 
XCAP server, for example.

We'd essentially create a "pseudo" URN, just like the "pres" and "IM" 
URNs, as in xcap:user@domain, and then use DDDS to get us to the right 
place. Thus, we'd have

AOR: [email-masked]
--> NAPTR provides xcap-provider.com, a shared web host serving lots of 
AOR domains

GET /[email-masked]/resource-list
Host: xcap-provider.com

By default, they'd use the same Digest credentials to access that 
resource. Thus, no new configuration.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Oct 2005 00:12:49 -0400

inline.

> positions. For the implementation it should not be a major issue, however.

What ended up in the text is a bit different than what I propose, and 
closer to what you hav ein mind, I think. Please take a look.

> in xcap these could appear within docs or r-uri's, so it should be imo 

We have this already in section 6:

Note that the left bracket, right bracket, and double quote
    characters, which are meaningful to XCAP, cannot be directly
    represented in the HTTP URI.  As a result, they are escape coded when
    placed within the HTTP URI.  Furthermore, since XML allows for non-
    ASCII characters, the names of elements and attributes may not be
    directly representable in a URI.  Any such characters MUST be
    represented by converting them to an octet sequence corresponding to
    their representation in UTF-8, and then escape-coding that sequence
    of octets.

is that not sufficient?

Thanks,
Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 26 Oct 2005 14:35:22 +0300

ext Jonathan Rosenberg wrote:

>>> would allow for insertions of the form ../parent/element[pos] to 
>>> have the effect of keeping together elements of the same name. Thats 
>>> all fine, except its not consistent with whats in the current spec. 
>>> Thus, changing it would break backwards compatibility. Since this 
>>> would be a feature enhancement as opposed to a bug fix, I think we 
>>> need to keep it consistent.
>>>
>> unambiguous. The minor issue is that in the implementation you'll 
>> anyhow have to find first the first possible location, now with your 
>> proposal an implementation has to look for the next (and the last) 
>> possible node positions. For the implementation it should not be a 
>> major issue, however.
>
>
I havn't yet read the whole new doc, just commenting this one issue. 
Anyway, I had to read 8.2.3 a couple of times before I probably 
understood what you have in mind ;).  That said, the skipping of 
whitespace, PI and comment nodes is problematic or actually whitespace 
nodes. That's because during the insert phase it is impossible to 
distinguish a whitespace node from the usual text node (mixed content), 
unless the schema is known. So imo the only reasonable solution is to 
use either the first or the last possible position for the newly 
inserted node (or actually element). As I said before, from the 
implementation pov the first possible position is better (i.e. when 
you'll have positional constraints).

When you don't have positional constraints (or you'll have elem[1] but 
not any other <elem>) I am inclined to prefer the former backwards 
compatibility mode, so just simply adding elements as last children. If 
you intend to keep this new proposal (without skipping) you should then 
add some text what will happen when you send 'root/*[3][@add="third"]' 
just in order to remove any ambiquity.

>> "Within expressions, literal strings are delimited by single or 
>> double quotation marks, which are also used to delimit XML 
>> attributes. To avoid a quotation mark in an expression being 
>> interpreted by the XML processor as terminating the attribute value 
>> the quotation mark can be entered as a character reference (|&quot;| 
>> or |&apos;|). Alternatively, the expression can use single quotation 
>> marks if the XML attribute is delimited with double quotation marks 
>> or vice-versa."
>>
>> in xcap these could appear within docs or r-uri's, so it should be 
>> imo described someway.
>> thanks,
>
>
Well not quite, e.g. BNF doesn't allow aposthrobe ('). Also if some 
example would contain one it would be neat.
thanks,
Jari