Subject: [Sip] Your draft xcap-diff-event:Sending etag information in the Subscribe.

From: "Anders Lindgren C \(TN/EAB\)" <[email-masked]>
Date: Tue, 15 May 2007 15:02:34 +0200

Hello Jari,
I have a comments/question related to how your draft
http://tools.ietf.org/wg/sip/draft-urpalainen-sip-xcap-diff-event-01.txt
can be applied in a environment limited bandwidth e.g. where the
subscription is done over an air interface.

As I see it an XCAP document can be quite large. It may also happen that
the changes can be quite rare and not that big.
A user can also have quite many documents that he/she wants to subscribe
for.
My view is that the memory in a client is not  a bottleneck today and
therefore it is quite likely that it is possible that clients will keep
a copy of needed XCAP documents.
The method in the draft ( see 4.7) to limit air traffic is to use the
"niemi-sip-subnot-etags" draft. That makes it possible to supress some
Notifies.
This method has one disadvantage and that is that it is based on one
etag per subscription and therefore not that useful when we are
subscribing for lots of documents in one Sunsbribe dialogue. The method
is useful when nothing has changed, but not that useful for small
changes to large documents as the client needs to do a XCAP GET in order
to fetch the version that the server has.

My proposal is to use a different method to limit the information sent
over the air.
The proposal is that if the client includes a body with all documents
and etags it has, the Notifier shall respond with a Nofify that contains
all XML patches needed to be able to patch the client's version of the
documents to the same version as the server has. 
If it is possible to send version information for all documents that the
client has stored already in the first Subscribe, the Notifier can use
this information to start to send the XML patches to patch the client
versions to the latest server versions (instead of sending only the link
to the documents ) if the server has such patches stored. 
If it can not provide the patches, it needs to send the link as today. 
If the server has the same version as the client, the server can send
the link with the etag just to confirm that it has the same version.  

Taking an example from OMA; the existing OMA-TS-XDM-Core (see
http://www.openmobilealliance.org/release_program/docs/CopyrightClick.as
p?pck=XDM&file=V1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A.pdf
has an xml schema that it is possible to reuse for the version
information from the client, (see
http://www.openmobilealliance.org/tech/profiles/xdm_xcapDirectory-V1_0_1
.xsd) as it contains per AUID the URIs for a document plus the etag. 

This proposal will introduce a requirement that the XCAP server needs to
have a optional patch history function to support this function, if not
supported the server can do as in the existing draft.
Comments?

Regards
Anders

_______________________________________________
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: Fri, 18 May 2007 10:10:36 +0300

ext Anders Lindgren C (TN/EAB) wrote:
> _http://tools.ietf.org/wg/sip/draft-urpalainen-sip-xcap-diff-event-01.txt_ 
> As I see it an XCAP document can be quite large. It may also happen 
> that the changes can be quite rare and not that big.
>
> A user can also have quite many documents that he/she wants to 
> subscribe for.
> therefore it is quite likely that it is possible that clients will 
> keep a copy of needed XCAP documents.
>
Although there are no examples, i'm proposing Suppress-Notify-If-Match: 
* after the initial notification, if you need this re-subscription with 
aggregate mode.
> subscribing for lots of documents in one Sunsbribe dialogue. The 
> method is useful when nothing has changed, but not that useful for 
> small changes to large documents as the client needs to do a XCAP GET 
> in order to fetch the version that the server has.
>
it is useful to allow to suppress the notify, when you want to just send 
some rpc-commands to the other end. And certainly it doesn't do what you 
want, if it were to be used with content sync with several http resources.
> and etags it has, the Notifier shall respond with a Nofify that 
> contains all XML patches needed to be able to patch the client's 
> version of the documents to the same version as the server has
>
With http you can do instance manipulation (rfc3229). But it requires 
versioning support on the XCAP server, which is overkill for the problem 
at-hand, imo 
(<http://www1.ietf.org/mail-archive/web/sip/current/msg18920.html>). So 
sure you could add an even more sophisticated stuff with sip here by 
combining or listing locally already existing resources. So you could 
optimize this but you would add yet more complexity and "interesting" 
error cases... Also if you had every resource in sync you would 
practically send the same information within subscribe body what you 
will receive now within the initial notify (and of course, upstream 
speed may be much slower than downstream).

> If it is possible to send version information for all documents that 
> the client has stored already in the first Subscribe, the Notifier can 
> use this information to start to send the XML patches to patch the 
> client versions to the latest server versions (instead of sending only 
> the link to the documents ) if the server has such patches stored.
>
> _http://www.openmobilealliance.org/release_program/docs/CopyrightClick.asp?pck=XDM&file=V1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A.pdf_ 
> <http://www.openmobilealliance.org/release_program/docs/CopyrightClick.asp?pck=XDM&file=V1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A.pdf>  
> _http://www.openmobilealliance.org/tech/profiles/xdm_xcapDirectory-V1_0_1.xsd_) 
> as it contains per AUID the URIs for a document plus the etag.
>
> This proposal will introduce a requirement that the XCAP server needs 
> to have a optional patch history function to support this function, if 
> not supported the server can do as in the existing draft.
>
> Comments?
>
> Regards
> Anders
>
Still for newly created resources with rapid following changes the same 
aggregate problem will exist.
thanks,
Jari

---

From: "Anders Lindgren C (TN/EAB)" <[email-masked]>
Date: Mon, 28 May 2007 19:07:15 +0200

Hello Jari,
Thanks for your answers.
I'm try to do my best to understand how your I-D together with other
I-D's or RFC can be used to provide us with of methods to able to be use
in a number of scenarios. I do also think that we must let implementers
have a number of methods to select from in order to best solve found
issues. This is list of some scenarios I see.

1) The number of documents that a client want to monitor is huge. Number
of SIP sessions must be limited as it costs to refresh them over the
air.
 
2) The documents to monitor belong to a number of users. The number of
SIP sessions must be limited as it cost to refresh them over the air. (
e.g. a user is a member of many groups and is allowed to see the content
of each group documents)

3) Fiber is used between a client and the network. Number of SIP
sessions or number of bytes sent is not an issue

4) It exist large documents. Changes are normally small ( e.g. a
resource list with 500 contacts and display name is changed or a contact
is added once a week)

5) The client has to need to be able to present the difference between
its cached version of a document and the latest document stored on the
server to the client user.

6) The monitored XML node is large. Changes are normally done only to
child element/attributes to the node ( e.g. a list element within a
resource-list document. A diplay name of one of the contact is changed).
Number of bytes sent between a server and a client is an issue.

Some more questions:
A) 1) is handle by your I-D as you can list a number of documents and
directories related to the R-URI. 2) is not handled. Do you think your
I-D can be combined with
http://tools.ietf.org/html/draft-ietf-sip-uri-list-subscribe-01 to be
able to use a exploder function in the network to have one Subscribe
sessions for all possible documents independent upon owner? As I see it
the parameter "path" is more or less replaced with the URI list in the
body therefore "path" needs to optional and not mandatory in this case?

B) As I see it a limited patch history function in the XCAP server can
be useful to handle 4) and 5). As you did not like my idea to send the
version information upstream via SIP, I have another idea and that is to
make it possible for a XCAP client to via the XCAP send do a Conditional
GET and if the etags are different receive a diff document instead of a
full document if such patch history exists. My view is that it is better
to keep a patch history on the server than keeping a copy of every
version. I also know that in OMA it exists requirement to be able to
provide a history of who and want certain clients added to the document
and this is more or less a patch history plus an indication about who
and when the patch was done. What's your view?

C)  6) needs that it is possible also to send xml patches also when you
subscribe for a XML node. My understanding of your I-D is that that is
not supported. Is that true?

Br
Anders 

-----Original Message-----
From: Jari Urpalainen [mailto:[email-masked]] 
Sent: den 18 maj 2007 09:11
To: Anders Lindgren C (TN/EAB)
Cc: [email-masked]
Subject: Re: Your draft xcap-diff-event:Sending etag information in the
Subscribe.

ext Anders Lindgren C (TN/EAB) wrote:
> _http://tools.ietf.org/wg/sip/draft-urpalainen-sip-xcap-diff-event-01.
> txt_ can be applied in a environment limited bandwidth e.g. where the 

it is useful to allow to suppress the notify, when you want to just send
some rpc-commands to the other end. And certainly it doesn't do what you
want, if it were to be used with content sync with several http
resources.

> _http://www.openmobilealliance.org/release_program/docs/CopyrightClick
> .asp?pck=XDM&file=V1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A.
> pdf_ 
> <http://www.openmobilealliance.org/release_program/docs/CopyrightClick
> .asp?pck=XDM&file=V1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A.
> pdf> has an xml schema that it is possible to reuse for the version 
> _http://www.openmobilealliance.org/tech/profiles/xdm_xcapDirectory-V1_
> 0_1.xsd_) as it contains per AUID the URIs for a document plus the 
> etag.
>

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 30 May 2007 11:05:13 +0300

> body therefore "path" needs to optional and not mandatory in this case?
I'm somewhat lost here. So you could request similar (or all) xcap docs 
on many different servers ? The "path" parameter is used as a 
deterministic way to describe the content what the client is interested 
in, so how with exploder you would select them ? I'd assume you would 
send the same parameter forward.
> and when the patch was done. What's your view?
Yes, this is what instance manipulation is about, i.e. rfc 3229. What 
you would need is a new mime-type for xml-diff based on patch-ops. 
Secondly, you would require versioning in xcap server and lastly, 
retrieval of versioned documents to cleanly solve this initial sync 
problem. And still, ;-) we could add yet many other interesting 
features, and I'm in general in favor of improving things, but scope of 
this i-d is imo right, i.e. all of these can (and should)  be done in 
other  documents.
> not supported. Is that true?
Right, I was initially hesitant about the requirement of xcap-component 
retrievals with sip. Although patching of xcap components (i.e. 
elements) is doable with some "magic" (it's not extremely complex), I'm 
inclined to think it's not a feature that you really need. So my 
preference is to keep this as simple as possible.
thanks,
jari