Subject: RE: [Simple] Update to xcap package

From: [email-masked]
Date: Mon, 23 Feb 2004 12:59:22 +0200

You can probably indicate the position of the insertion using the xpath like expression. Something like:

PUT http://document/foo/bar[@id="3 and 3"]

<bar id="3"/>

or

PUT http://document/foo/bar[@id="3 and position()=3"]

<bar id="3"/>

Valid xpath expressions, but not sure if they are valid http URIs.

/Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 22.February.2004 10:23
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Update to xcap package
> 
> 
> 
> inline.
> 
> [email-masked] wrote:
> 
> > 
> >> -----Original Message----- From: ext Jonathan Rosenberg
> >> [mailto:[email-masked]] Sent: 19.February.2004 06:48 To:
> >> Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: [email-masked];
> >> [email-masked] Subject: Re: [Simple] Update to xcap package
> >> 
> >> 
> >> 
> >> 
> >> 
> >> [email-masked] wrote:
> >> 
> >> 
> >>> I had the use case in my mind that if we have a list that is
> >>> shared amongst 100 or even 10000 employees and one modifies it,
> >>> then this will result in 100 NOTIFYs. Each then might generate a
> >>> GET.
> >> 
> >> OK.
> >> 
> >> 
> >>> Also for a conference using XCAP, it might be true that there is
> >>> one creator, but there could be many privileged users who have
> >>> read rights and can subscribe to the changes in the conference
> >>> policy.
> >>> 
> >>> I'm not sure if the cost of sending the changes in a NOTIFY as 
> >>> opposed to just sending the etag is so great.
> >> 
> >> One thing we need to figure out is the format for the NOTIFY. WHats
> >> in the event package at the moment won't work, because there are 
> >> many valid results that can be obtained from applying the xcap
> >> operations to a document.
> > 
> > 
> > I'm sorry, I don't understand what you mean by saying that 
> many valid
> > results can be obtained. Can you elaborate?
> 
> Sorry for being unclear on it.
> 
> Lets say I have a document like this:
> 
> <foo>
>    <bar id="1"/>
>    <bar id="2"/>
> </foo>
> 
> and I do an xcap addition operation:
> 
> PUT http://document/foo/bar[@id="3"]
> 
> <bar id="3"/>
> 
> 
> XCAP requires that the server create this element such that a 
> GET to the 
> same URI returns the same body. However, there are three ways 
> that the 
> server could do such an insertion and still meet that definition:
> 
> <foo>
>    <bar id="3"/>
>    <bar id="1"/>
>    <bar id="2"/>
> </foo>
> 
> OR
> 
> <foo>
>    <bar id="1"/>
>    <bar id="3"/>
>    <bar id="2"/>
> </foo>
> 
> OR
> 
> <foo>
>    <bar id="1"/>
>    <bar id="2"/>
>    <bar id="3"/>
> </foo>
> 
> 
> The current xcap-package includes a hash in the notify, to allow the 
> client to match what they did against what the server has. I believe 
> that, in this hash, ordering of elements and attributes is 
> signficiant. 
> As a result, the hash computed by the server might not match the one 
> computed by the client, since both client and server did the insert 
> separately.
> 
> A different "diff" format can be defined which is more precise about 
> where the server did the insertion. For any element, specifying its 
> parent and previous sibling is sufficient. If we want the 
> hash to remain 
> in the notifications, we'd need to define a format like that.
> 
> Hope this clarifies.
> 
> -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: Ted Hardie <[email-masked]>
Date: Mon, 23 Feb 2004 14:42:30 -0800

>Valid xpath expressions, but not sure if they are valid http URIs.

As stated, it does not look to me if they are valid URIs.  The text
on delimiters was recently updated in the RFC2396bis draft (available
at http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-04.txt);
here's the current text:

>2.2 Reserved Characters
>
>    URIs include components and sub-components that are delimited by
>    characters in the "reserved" set.  These characters are called
>    "reserved" because they may (or may not) be defined as delimiters by
>    the generic syntax, by each scheme-specific syntax, or by the
>    implementation-specific syntax of a URI's dereferencing algorithm.
>    If data for a URI component would conflict with a reserved
>    character's purpose as a delimiter, then the conflicting data must be
>    percent-encoded before forming the URI.
>
>       reserved    = gen-delims / sub-delims
>
>       gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
>
>       sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
>                   / "*" / "+" / "," / ";" / "="
>  A subset of the reserved characters (gen-delims) are used as
>    delimiters of the generic URI components described in Section 3. A
>    component's ABNF syntax rule will not use the reserved or gen-delims
>    rule names directly; instead, each syntax rule lists those reserved
>    characters that are allowed within that component (i.e., not
>    delimiting it).  The allowed reserved characters, including those in
>    the sub-delims set and any of the gen-delims that are not a delimiter
>    of that component, are reserved for use as sub-component delimiters
>    within the component.  Only the most common sub-components are
>    defined by this specification; other sub-components may be defined by
>    a URI scheme's specification, or by the implementation-specific
>    syntax of a URI's dereferencing algorithm, provided that such
>    sub-components are delimited by characters in that component's
>    reserved set.  If no such delimiting role has been assigned, then a
>    reserved character appearing in a component represents the data octet
>    corresponding to its encoding in US-ASCII.

Minimally, it looks to me like you would have to percent encode a
number of the characters in the URIs referenced.  Note that if you
do that it becomes clearer that base HTTP engines will see the string after
foo as if it referred to an atomic resource,  rather than as
structured data.

Note also that in the example above "document" looks like
a non-fully qualified domain name.  You might want to look at
section 3 of the fielding draft for a description of the "greedy"
disambiguation of the authority from path in a URI parser.

			regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Feb 2004 14:42:30 -0800

regards,
				Ted Hardie

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Feb 2004 23:36:43 -0500

Yes, something like this would work. No doubt fuller xpath would enable
us to more concretely specify insertion points. Its not clear whether
these are needed in xpath per se, but rather in the "diff" sent in the
notifications for the package.

A few more comments inline:

> PUT http://document/foo/bar[@id="3 and 3"]

This is not legal, I don't think.

> PUT http://document/foo/bar[@id="3 and position()=3"]

I believe its http://example.com/document/foo/bar[@id="3" and 
position()="3"]

> Valid xpath expressions, but not sure if they are valid http URIs.

As Ted points out, they would need to be escaped.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Feb 2004 23:36:43 -0500

-Jonathan R.