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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
