Subject: [Simple] Clarification on usage of xcap-diff

From: <[email-masked]>
Date: Tue, 3 Oct 2006 10:49:28 +0300

Hello,

I am currently working with the xcap-diff and I am not very sure about
one issue.

1. I have document
2. I do PUT operation replacing whole document
   PUT http://server/path/document
3. In notification there will be xcap-diff document
 A:
   <xcap-diff xcap-root="http://server">
     <document doc-selector="path/document" new-etag="2"
previous-etag="1">
       <change-log>
         <replace sel="/">
           new content of the document
         </replace>
       </change-log>
     </document>
   </xcap-diff>
 B:
   <xcap-diff xcap-root="http://server">
     <document doc-selector="path/document" new-etag="2"
previous-etag="1"/>
   </xcap-diff>

In my opinion, as xml-patch-ops-01 says - sel attribute contains
relative path to document root "/", the latter alternative is correct.
What I am not sure, whether it is correct to omit the change-log part of
the xcap-diff document and leave on the client to download the new
document by itself.

br, Martin

+-------------------------------------+
  Martin Hynar
  Software Specialist

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 035 397
  E-mail: [email-masked]

  Vystavni 292/13
  CZ-709 16 Ostrava

  www.tietoenator.com

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

---

From: "Bulent Gecer \(TN/EAB\)" <[email-masked]>
Date: Tue, 3 Oct 2006 10:15:12 +0200

Hello, 

I guess a workaround would be to send back two notifications, the first
stating that the document was deleted (no "new-etag" in the diff-doc)
and the second stating that the document was created (no "prev-etag" in
the diff-doc).

BR,

/Bulent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: den 3 oktober 2006 09:49
To: [email-masked]
Subject: [Simple] Clarification on usage of xcap-diff

Hello,

1. I have document

br, Martin

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 035 397

  Vystavni 292/13
  CZ-709 16 Ostrava

  www.tietoenator.com

---

From: <[email-masked]>
Date: Tue, 3 Oct 2006 11:38:55 +0300

Hello, and thanks for interrest

however, I think this cant work because on deletion of the document the server shall terminate the subscription with "noresource" reason meaning "there was deleted the object which status was subscribed".

br, martin

-----Original Message-----
From: Bulent Gecer (TN/EAB) [mailto:[email-masked]]
Sent: Tue 10/3/2006 10:15 AM
To: Hynar Martin; [email-masked]
Subject: RE: [Simple] Clarification on usage of xcap-diff
 
Hello, 

BR,

/Bulent

-----Original Message-----

Hello,

1. I have document

br, Martin

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 035 397

  Vystavni 292/13
  CZ-709 16 Ostrava

  www.tietoenator.com

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 03 Oct 2006 12:08:31 +0300

> and the second stating that the document was created (no "prev-etag" in
you could do that but it is not desirable
> the xcap-diff document and leave on the client to download the new
B. model is the only way currently when you can't describe the diff with 
patch-ops-02, i.e. for example you'll have xml prolog changes which 
cannot be located (and patched) with XPath semantics (ok, a corner case, 
but possible). So B. describes a replace (== PUT with 201 response) and 
the client needs to fetch the document with GET. Btw. a plain "/" 
selector is disallowed for <replace> but the document root element can 
be replaced with "*" or  "[root_elem_name]". So given these conditions 
can be met, also A is possible (which is quite typical, btw.)
br,
Jari

---

From: "Bulent Gecer \(TN/EAB\)" <[email-masked]>
Date: Tue, 3 Oct 2006 11:09:35 +0200

But do you have to explicitly delete the document?  

/Bulent

-----Original Message-----

Sent: den 3 oktober 2006 10:39
To: Bulent Gecer (TN/EAB); [email-masked]
Subject: RE: [Simple] Clarification on usage of xcap-diff

however, I think this cant work because on deletion of the document the
server shall terminate the subscription with "noresource" reason meaning
"there was deleted the object which status was subscribed".

br, martin

-----Original Message-----
From: Bulent Gecer (TN/EAB) [mailto:[email-masked]]
Sent: Tue 10/3/2006 10:15 AM
To: Hynar Martin; [email-masked]
Subject: RE: [Simple] Clarification on usage of xcap-diff
 
Hello, 

BR,

/Bulent

-----Original Message-----

Hello,

1. I have document

br, Martin

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 035 397

  Vystavni 292/13
  CZ-709 16 Ostrava

  www.tietoenator.com

---

From: <[email-masked]>
Date: Tue, 3 Oct 2006 12:12:58 +0300

No, it is not mandatory. I want to replace the document with new content. Doing this I can preserve all existing subscriptions to that document. If the document is first removed, all subscriptions will be terminated and then they need to be re-establised again. (as a consequence, this may increase client-server communication and I think, this is what xcap-diff wants to reduce)

br, Martin

-----Original Message-----
From: Bulent Gecer (TN/EAB) [mailto:[email-masked]]
Sent: Tue 10/3/2006 11:09 AM
To: Hynar Martin; [email-masked]
Subject: RE: [Simple] Clarification on usage of xcap-diff

/Bulent

-----Original Message-----

br, martin

-----Original Message-----
From: Bulent Gecer (TN/EAB) [mailto:[email-masked]]
Sent: Tue 10/3/2006 10:15 AM
To: Hynar Martin; [email-masked]
Subject: RE: [Simple] Clarification on usage of xcap-diff
 
Hello, 

BR,

/Bulent

-----Original Message-----

Hello,

1. I have document

br, Martin

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 035 397

  Vystavni 292/13
  CZ-709 16 Ostrava

  www.tietoenator.com

---

From: <[email-masked]>
Date: Tue, 3 Oct 2006 12:28:42 +0300

Hello,

so, if I understood it correctly, you think that if I replace sel="/" with sel="*" then also option A is correct?

Meaning of this is that * substitutes arbitrary element in the document and the first matching occurence will be the root element of the document.

br, Martin

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 03 Oct 2006 13:31:54 +0300

> so, if I understood it correctly, you think that if I replace sel="/" with sel="*" then also option A is correct?
exactly, given that all changes are within the document root element 
(which is the most typical case, others are really corner-cases, imo. 
But anyway the server/notifier knows ;-) how to act).
> Meaning of this is that * substitutes arbitrary element in the document and the first matching occurence will be the root element of the document.
right , wildcard "*" selects all element children (of the root node), 
i.e. a valid xml document must only have one document root element, so 
there's no ambiguity here. So you could even change to a different QName 
but it is certainly rare. But you could for example, have XML entities 
within the prologue which can't be described with XPath semantics. You 
don't generally use them, and then the client does a full re-fetch (and 
there this open issue of xcap-diff still exists, at least theoretically).
> can be met, also A is possible (which is quite typical, btw.)
btw. a typo 200 OK, not 201 Created,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Oct 2006 22:27:00 -0400

inline.

Jari Urpalainen wrote:

>> Meaning of this is that * substitutes arbitrary element in the 
>> document and the first matching occurence will be the root element of 
>> the document.
>>
>> br, Martin
>>
>>
>>   
> 
> within the prologue which can't be described with XPath semantics. 

Also I suspect the server would find it easier to report the change 
without the change-log since it never got an XCAP operation than 
transformed the document from one version to the next (i.e., element 
additions or removals).

You
> there this open issue of xcap-diff still exists, at least theoretically).

What open issue?

-Jonathan R.

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

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 04 Oct 2006 11:55:48 +0300

ext Jonathan Rosenberg wrote:
>>> document and the first matching occurence will be the root element 
>>> of the document.
>>>
>>> br, Martin
>>>
>>>
>>>   
>>
>> i.e. a valid xml document must only have one document root element, 
>> so there's no ambiguity here. So you could even change to a different 
>> QName but it is certainly rare. But you could for example, have XML 
>> entities within the prologue which can't be described with XPath 
>> semantics. 
>
right. However, I've implemented also "xmldiff" based on patch-ops and 
while it is in general much more complex (with many possible algorithms) 
than patching (be it xcap, patch-ops etc.) you can still implement one 
with "basic" simple rules without enormous amount of complex code. So 
the end result may not be the most efficient one but it is certainly 
doable and imo yes, even worth implementing e.g. for xcap clients.
>
> You
>> don't generally use them, and then the client does a full re-fetch 
>> (and there this open issue of xcap-diff still exists, at least 
>> theoretically).
>
> What open issue?
>
> -Jonathan R.
>
I was just referring to the "old" documented issue, i.e. the initial 
sync of http resources/sip notify. It may however, be that this belongs 
to config-paper, but all the proposed solutions seem to have some 
inadequacy and/or complexity, or is there a (new) reasonable resolution 
here that I'm unaware of ?

thanks,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Oct 2006 15:58:43 -0400

inline.

> here that I'm unaware of ?

I have been thinking about this lately.

Firstly I think it makes sense to put this issue in the event package 
draft 
(http://www.ietf.org/internet-drafts/draft-ietf-sipping-xcap-config-00.txt), 
so that xcap-diff is pure format and can proceed easily.

On the issue itself, I think there is a simpler solution than what is in 
the document. The idea is this. When you get a NOTIFY with an etag, you 
do a non-conditional GET. This will either produce a version with the 
same etag as you had in the NOTIFY, or not. If not, it has to be because 
the document has changed since the previous NOTIFY, and so another 
NOTIFY is coming. When that NOTIFY comes, you check its new-etag. If it 
matches the document, great. If not, discard and wait for the next 
NOTIFY. You'll eventually get a NOTIFY whose new etag matches the 
document received via HTTP. At this point you are synchronized.

This will work as long as the server is sending NOTIFYs for each 
document change.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Oct 2006 15:58:43 -0400

inline.

-Jonathan R.

---

From: <[email-masked]>
Date: Thu, 5 Oct 2006 10:00:50 +0300

Hello,

the usage with ietf-sipping-xcap-config is one of xcap-diff applications. And this one is also used in OMA specifications.

br, Martin

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wed 10/4/2006 9:58 PM
To: Jari Urpalainen
Cc: Hynar Martin; [email-masked]
Subject: Re: [Simple] Clarification on usage of xcap-diff
 
inline.

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 05 Oct 2006 10:40:02 +0300

ext Jonathan Rosenberg wrote:
>> sync of http resources/sip notify. It may however, be that this 
>> belongs to config-paper, but all the proposed solutions seem to have 
>> some inadequacy and/or complexity, or is there a (new) reasonable 
>> resolution here that I'm unaware of ?
>
>
agreed, it is a better place.
> On the issue itself, I think there is a simpler solution than what is 
> in the document. The idea is this. When you get a NOTIFY with an etag, 
> you do a non-conditional GET. This will either produce a version with 
> the same etag as you had in the NOTIFY, or not. If not, it has to be 
> because the document has changed since the previous NOTIFY, and so 
> another NOTIFY is coming. When that NOTIFY comes, you check its 
> new-etag. If it matches the document, great. If not, discard and wait 
> for the next NOTIFY. You'll eventually get a NOTIFY whose new etag 
> matches the document received via HTTP. At this point you are 
> synchronized.
>
right, this is the simplest approach which is probably good enough for 
XCAP resources. The disturbing fact is that servers could never do 
efficient aggregation of individual patches. Instead, you should provide 
several <document> elements for the same resource, which isn't that 
nice. Btw.  maxOccurs="unbounded" cardinality is missing from <document> 
schema definition. How about adding some semantics to re-SUBSCRIBE to 
tell the server "aggregation allowed" meaning sync achieved on the 
client side ?

thanks,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Oct 2006 16:55:54 -0400

inline.

> agreed, it is a better place.

Right. I will strike the section from the revision of the document.

> efficient aggregation of individual patches.

I wouldn't say never; the server can do it once it knows that the client 
has the specific version whose etag is in the NOTIFY. The ultimate fix 
for this is something I think Aki proposed in sipping way back (which we 
need to revisit), which was that a SUBSCRIBE could contain the etag of 
the resource being subscibed to that the client already has.

  Instead, you should provide
> nice.

Sorry - I don't follow this...

> Btw.  maxOccurs="unbounded" cardinality is missing from <document> 
> schema definition.

Yes, I know. This had been pointed out to me privately by others.

> How about adding some semantics to re-SUBSCRIBE to 

I think the etag-in-SUBSCRIBE approach would provide a clean way to do that.

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 06 Oct 2006 14:12:49 +0300

ext Jonathan Rosenberg wrote:
>> in the document. The idea is this. When you get a NOTIFY with an 
>> etag, you do a non-conditional GET. This will either produce a 
>> version with the same etag as you had in the NOTIFY, or not. If not, 
>> it has to be because the document has changed since the previous 
>> NOTIFY, and so another NOTIFY is coming. When that NOTIFY comes, you 
>> check its new-etag. If it matches the document, great. If not, 
>> discard and wait for the next NOTIFY. You'll eventually get a NOTIFY 
>> whose new etag matches the document received via HTTP. At this point 
>> you are synchronized.
>>>
>> right, this is the simplest approach which is probably good enough 
>> for XCAP resources. The disturbing fact is that servers could never 
>> do efficient aggregation of individual patches.
>
> I wouldn't say never; the server can do it once it knows that the 
> client has the specific version whose etag is in the NOTIFY. The 
> ultimate fix for this is something I think Aki proposed in sipping way 
> back (which we need to revisit), which was that a SUBSCRIBE could 
> contain the etag of the resource being subscibed to that the client 
> already has.
>
ok, I was  unclear what I meant,  so the server doesn't know the time to 
start aggregating, so it may have an "educated guess" so theoretically 
it could be almost infinite waiting... Imo there's a difference here 
than with Aki's i-d (in sip), which tries to suppress notifies or bodies 
(although it is definitely a very good thing and yes should be combined 
here). What I am looking for is a directive from the client (who 
definitely knows when it is ready) to the server that aggregation is 
preferred. Also, it might be reasonable to allow sending only document 
updates, i.e. no patch info at all for the clients who don't need 
transmission optimization (or don't support patching). So they want to 
sync on document basis and want to have a deterministic knowledge of 
document removals. Usually this sort of thing is easily solved by 
mime-types and Accept-header which doesn't fit here.  So this is imo 
semantically different than "Suppress-Notify-If-Match" but it is ok for 
me if this is combined with this "sync" issue (and of course 
documented). So whatever works and is fairly easily implementable is 
fine with me.
> Sorry - I don't follow this...
I just meant when you aggregate patches for a document you just give all 
individual changes within separate <document> elements (which all refer 
to the same http resource), so you can then aggregate and give also all 
ETag changes. So during sync this is ok, but not afterwards.
>> How about adding some semantics to re-SUBSCRIBE to tell the server 
>> "aggregation allowed" meaning sync achieved on the client side ?
>
Maybe so, although binding this single subscription ETag to multiple 
ETags of http documents isn't imo that "clean" or clear. But whatever, 
the discussion can continue only on xcap-config, if there's an even 
simpler and/or better way...

br,
Jari