Subject: [Sip] Thoughts on your draft xcap-diff-event: synchronization of notifications and XCAP GET

From: "Sofie Lassborn \(TN/EAB\)" <[email-masked]>
Date: Tue, 22 May 2007 10:20:41 +0200

Hi Jari,
I have some thoughts about the synchronization in the client of the
notifications of changes and retrieval of documents over XCAP.
Scenario 1: "No xml patching"
The subscription is in the "no xml patching" mode and a notification
containing a link to a document and a new etag "aaa" is received by the
client. Immediately after the notification has been sent out a change is
made to the document by another client and the etag is updated to "bbb".

The first client makes an XCAP GET request to retrieve the document and
receives a document with etag "bbb" which is different from the one
received in the notification. 
The client knows how to use the retrieved document until the
notification with the same etag, "bbb", is received and then when
another notification with etag "ccc" is received the client makes a new
XCAP GET request for this document. If the client in the XCAP GET
receives a document with a different etag than "ccc", the client can use
this document as it is newer than the one with etag "ccc".  
-> Scenario 1 has no issues.
Scenario 2: "xml patching"
The subscription is in the "xml patching" mode and a notification
containing a link to a document and a new etag "aaa" is received by the
client. Immediately after the notification has been sent out a change is
made to the document by another client and the etag is updated to "bbb".

The first client makes an XCAP GET request to retrieve the document and
receives a document with etag "bbb" which is different from the one
received in the notification. 
The client ignores all notifications until the notification with etag
"bbb" has been received. When another notification with an etag "ccc" is
received the client uses the included patch on his document. I.e. the
client buffers all notifications that arrives while the client performs
the XCAP GET and when the new document is received it applys all patches
with newer etags than the one in the retrieved document. 
-> Scenario 2 has no issues.
Scenario 3: "Aggregation"
The subscription is in the "aggregation" mode and a notification
containing a link to a document and a new etag "aaa" is received by the
client. 
The client makes an XCAP GET request to retrieve the document and
receives a document with etag "aaa". 
Several changes are made to the document by another client and the etag
is updated to "bbb" and then "ccc". A new "aggregated" notification with
previous-etag "aaa" and new-etag "ccc" is received and the client uses
the included patches on his document.
-> Scenario 3 has no issues.
Scenario 4: "Aggregation and unlucky timing"
The subscription is in the "aggregation" mode and a notification
containing a link to a document and a new etag "aaa" is received by the
client. Immediately after the notification has been sent out a change is
made to the document by another client and the etag is updated to "bbb".

The first client makes an XCAP GET request to retrieve the document and
receives a document with etag "bbb" which is different from the one
received in the notification. Another change is made to the document by
some other client and the etag is updated to "ccc". 
When the "aggregated" notification with previous-etag "aaa" and new-etag
"ccc" is received the client does not know how to apply these patches to
his document.
-> Scenario 4 has issues.
Possible solution:
In the aggregated notification each change that has been made to the
document is represented by a patch operation. 
Each patch operation is specified together with an etag value. The
client will then be able to only apply those changes that has been made
to the document with etag "bbb" and after. 
For this to work the schemas for the patch operation elements in
draft-ietf-simple-xml-patch-ops-02 need to be updated with etag
attributes.
In conjunction to the above scenarios I also wonder what the thoughts
with aggregation are. Is the main idea that it should be possible for
the server to "aggregate" several changes on a document into one or
fewer patch elements, i.e. "hide" some of the changes to the client.
This kind of functionality would be very complex to implement and
scenario 4 above would not be solved. If instead the intention is to
"aggregate" several patches in one notification and to reduce the number
of notifications sent then each patch element could also be linked with
the etag of the changed document and solve scenario 4 above. With the
existing schemas this could be done by having several document elements
pointing to the same document but with different etags and one patch
element for each document element. My proposal, which would produce
smaller xcap-diff documents, is instead to update the schemas for the
patch operation elements in draft-ietf-simple-xml-patch-ops-02 with etag
attributes.
Best regards,
Sofie

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 22 May 2007 14:01:59 +0300

ext Sofie Lassborn (TN/EAB) wrote:
> containing a link to a document and a new etag “aaa” is received by 
> the client. Immediately after the notification has been sent out a 
> change is made to the document by another client and the etag is 
> updated to "bbb".
> The first client makes an XCAP GET request to retrieve the document 
> and receives a document with etag “bbb” which is different from the 
> one received in the notification.
> another notification with etag "ccc" is received the client makes a 
> new XCAP GET request for this document. If the client in the XCAP GET 
> receives a document with a different etag than "ccc", the client can 
> use this document as it is newer than the one with etag "ccc".
> containing a link to a document and a new etag “aaa” is received by 
> the client. Immediately after the notification has been sent out a 
> change is made to the document by another client and the etag is 
> updated to "bbb".
> The first client makes an XCAP GET request to retrieve the document 
> and receives a document with etag “bbb” which is different from the 
> one received in the notification.
> "bbb" has been received. When another notification with an etag "ccc" 
> is received the client uses the included patch on his document. I.e. 
> the client buffers all notifications that arrives while the client 
> performs the XCAP GET and when the new document is received it applys 
> all patches with newer etags than the one in the retrieved document.
> containing a link to a document and a new etag “aaa” is received by 
> the client.
> receives a document with etag “aaa”.
> Several changes are made to the document by another client and the 
> etag is updated to "bbb" and then "ccc". A new "aggregated" 
> notification with previous-etag "aaa" and new-etag "ccc" is received 
> and the client uses the included patches on his document.
> containing a link to a document and a new etag “aaa” is received by 
> the client. Immediately after the notification has been sent out a 
> change is made to the document by another client and the etag is 
> updated to "bbb".
> The first client makes an XCAP GET request to retrieve the document 
> and receives a document with etag “bbb” which is different from the 
> one received in the notification. Another change is made to the 
> document by some other client and the etag is updated to "ccc".
> When the "aggregated" notification with previous-etag "aaa" and 
> new-etag "ccc" is received the client does not know how to apply these 
> patches to his document.
> client will then be able to only apply those changes that has been 
> made to the document with etag “bbb” and after.
right, this is the culprit, but i don't want to disallow aggregation.
> scenario 4 above would not be solved.
>
Well i have implemented a really stupid, but very simple logic in 
<http://sourceforge.net/projects/xmlpatch>, i.e. there's also an xml 
diff utility which produces a diff document of two documents (let's say 
initial and updated document). So i'll disagree that it were very 
complex to implement (~lk lines of C code). And I'm certain that there 
are better ways to implement it...

And btw. even for this "very simple" xcap client i'd propose a similar 
model, i.e. you would produce xcap updates based on diffing, at least my 
personal experience showed that it was indeed very difficult to combine 
internal patching and sending proper xcap requests at the same time ;-). 
I mean all possible error cases and keeping a reasonable state machine...
>
> If instead the intention is to "aggregate" several patches in one 
> notification and to reduce the number of notifications sent then each 
> patch element could also be linked with the etag of the changed 
> document and solve scenario 4 above. With the existing schemas this 
> could be done by having several document elements pointing to the same 
> document but with different etags and one patch element for each 
> document element. My proposal, which would produce smaller xcap-diff 
> documents, is instead to update the schemas for the patch operation 
> elements in draft-ietf-simple-xml-patch-ops-02 with etag attributes.
>
> Best regards,
> Sofie
>
So we would have etag history in two places ? (and it would mean 
updating diff format) and would be somewhat shorter format (and even 
more optimizations are possible). However, I still think the proposed 
one is the best compromise which allows aggregation. This is definitely 
a rare case and thus it is fully _optional_ both for the server and the 
client (and as is xml-patching optional). So the non-aggregate mode is 
the default mode with patching, but clients may try to use the aggregate 
mode as well (which isn't as elegant as one would want, but possible). 
Someday, it may be possible to have also e.g. proper versioning in the 
xcap server, and then this protocol handshake ugliness disappears with 
aggregate mode. We might want to optimize xml-patching mode, but that's 
another thing.
thanks,
Jari