Subject: RE: [Simple] Partial Notifies?

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 18 Sep 2001 11:06:36 -0500

>I believe the requirements for the partial notifications are 
>the following:
>
>1. the subscribe request have a way for the subscriber to indicate what
>version they have, so that the notify only contain a delta 
>from that version
>(indeed, perhaps the notify isn't even sent if the version the 
>subscriber
>has is up to date)

It would also be nice to support packages that do not
keep multiple versions around on the server. The delta
would always be against the most recent version and
if you are out of sync you would retrieve the complete
state in a fetch first, then apply the latest delta.

>
>2. the notify have a way to indicate what version of the document the
>subscriber will have once the patch is applied
>
>3. the notify have a way to indicate what version the of the 
>document the
>subscriber has to apply the patch against (i.e, the old version)
>
>4. the "patch" be in a format that is independent of the format of the
>presence document.

Would a Content-Encoding or Content-Transfer-Encoding
be appropriate here? What is the goal of partial notifies?
Is it simply to reduce message size? If so, gzip or deflate
compression of the body may be sufficient. 
 
>Anders Kristensen had pointed out to me that webdav has looked 
>at a very
>similar problem, and that there are specs for deltas within 
>http. I haven't
>looked at those in detail, but they might provide a solution 
>for us that
>would allow us to reuse existing work elsewhere in IETF.

see 
http://search.ietf.org/internet-drafts/draft-ietf-deltav-versioning-18.txt

WebDAV deals with a more sophisticated concept of version
control that is appropriate for document or source code
control. For example, it allows forking and merging of
versions. Do we need this level of complexity for 
partial notifies? I think (hope) not.

One very interesting concept we can borrow from WebDAV
is the notion of versioning information embedded in a 
URL. This could obviously be included in the Request-URI
of a SUBSCRIBE to indicate the current version that the
client has. It could also be included in the Request-URI
of the NOTIFY.

>
>So, the quesitons to be discussed, in order, are:
>
>1. is there consensus that we should have a solution for 
>partial notifies in
>simple?

Yes, but ... I think it is also useful to allow
a client to use the current "every NOTIFY contains
complete state" model. What I would propose is a
".delta" sub-package that an event package could
support if a client wishes to receive partial notifies.
Doing a one-time fetch of the base package gives complete
state. From that point on, the client can SUBSCRIBE to the
.delta sub-package if it wishes to receive partial notifies.

This leaves the possibility for both modes of operation.

>
>2. is there consensus that this should be done in a general 
>fashion as part
>of the sip events specification?

Yes, but should it go into the base SUB/NOT draft or should
there be another draft describing versioning as an optional
extension to SUB/NOT? I would prefer to close the base SUB/NOT
draft as quickly as possible. Partial notifies may be a useful
extension, but they don't seem valuable enough to warrant 
slowing down the standardization of SUB/NOT (upon which a 
bunch of other work is dependent)

>3. how should it be done?

I'm assuming that version information will be opaque
strings/tokens.

A "Label:" header as proposed in the WebDAV work might
be useful for satisfying requirements 1 and 2 above.

>Comments?
>-Jonathan R.

Regards,
Sean Olson
Ericsson Inc.

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 18 Sep 2001 22:01:06 -0400

"Sean Olson (EUS)" wrote:
> Is it simply to reduce message size?

Yes, that would be the only goal. Simplicity on the client side would
likely be a requirement also.

 If so, gzip or deflate
> compression of the body may be sufficient.

Yes, might be. As a side note, gzip might still be applied to a diff
itself to further lessen size.

> partial notifies? I think (hope) not.

That sure sounds like way too much. The draft I had in mind was
http://www.ietf.org/internet-drafts/draft-mogul-http-delta-08.txt

This details how various diff algorithms (textual or binary - the
mechanism works with either) can be used to reduce the message size when
the client has an old version of some resource. It seems like it should
be fairly straightforward to apply the same ideas to SIP.

> >of the sip events specification?

If we go with a generic diff model it may be that it is more widely
applicable than sip events. Or at least independent.

> be useful for satisfying requirements 1 and 2 above.

So here's a sketch of how this might work in SIP.

Clients would indicate support for one or more delta encoding mechanisms
in SUBSCRIBEs by listing extension token 'delta' in a Supported header
and the actual "instance manipulations" supported in an A-IM header
(A-IM stands for Accept-Instance-Manipulations and is defined in the
http draft as is the IM header used in NOTIFYes):

        SUBSCRIBE sip:[email-masked] SIP/2.0
        Supported: delta
        A-IM: diffe, vcdiff
        Event: presence
        ...

the server would make a note of supported alg's in the subscription
"record".

The server then has to know what version of a particular subscription
doc a watcher has received, and when it sends a NOTIFY for a watcher it
may send only a delta if that guy has indicated support for it, e.g.:

        NOTIFY sip:[email-masked] SIP/2.0
        Require: delta
        IM: diffe
        Delta-Base: "abc"
        Etag: "ghi"
        Event: presence
        Content-Type: application/cpim-pidf+xml

        ...

Unlike the http case there's no request in which a version number/tag
can be carried so presumably the server has to just know what version of
the presence doc (or whatever) the client knows about, or else assume
that it knows about the previous version.  If for some reason the client
doesn't, it would return some error response which would tell the server
to send the whole resource/document. The error response would also list
the A-IM and Supported header as appropriate.

The Delta-Base header gives the version of the resource that the delta
should be applied to (and which the client is assumed to possess). The
ETag gives an identifier for the new resource.

A presence server that doesn't know about the delta extension just
ignores the A-IM header and sends the full update every time.

Anders