Subject: RE: [Simple] Partial Notifies?

From: "Sean Olson (EUS)" <[email-masked]>
Date: Mon, 24 Sep 2001 14:54:18 -0500

I realize this has been pushed off to future work,
but I thought I would throw my two cents in now.
I think we could have a reasonable first draft
of a partial NOTIFY mechanism completed in a 
couple of weeks.

>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.

I agree. This is much simpler. Can we make a baseline 
requirement for either vcdiff or gdiff? Both support 
binary data. gdiff seems simpler, but vcdiff supports
compression. If I had to choose, I would mandate support
for vcdiff.

>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
>        ...

Can we use the A-IM: header as an implicit indicator
of support for delta encoding?

>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.

I assume we can do something like:
SUBSCRIBE sip:[email-masked]?Etag="ghi" SIP/2.0
to at least indicate what version the client has at the
time of subscription. The first NOTIFY could then include
either the full state or the appropriate delta encoding to
bring the client in sync with the server. Or use a 
"If-None-Match:" header as in HTTP/1.1. 

I don't see a reason to return an error response to the server.
Do a one-time SUBSCRIBE with no "A-IM" header instead. It costs
two extra messages, but simplifies the life of the presence server.

>
>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.

Sounds good.

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

Sounds reasonable. Some things that need to be fleshed out include:

1) How would the server indicate in the initial NOTIFY that the
   client state is already up-to-date? (HTTP 1.1 uses a 
   "304 Not Modified" response code. Do we want to do something
   similar?) This would be particularly useful for a fetch operation.

2) Do we want to allow compression manipulations in addition to the
   delta encoding? Or can we just apply Content-Encodings on top
   of the delta encoding? I assume the later is fine.

/sean

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 02 Oct 2001 20:24:10 -0400

> of a partial NOTIFY mechanism completed in a

Yup.

> compression. If I had to choose, I would mandate support

I'd prefer a recommendation over a hard requirement for a particular
format/algorithm. I agree that vcdiff seems like the better choice.

> of support for delta encoding?

Sounds reasonable.

> "If-None-Match:" header as in HTTP/1.1.

I like the idea of the client telling the server which version it has in
the SUBSCRIBE but I think it's preferable to put the version number in
an ETag header as in HTTP.

>    similar?) This would be particularly useful for a fetch operation.

It may be enough to send a NOTIFY with identical values in the ETag and
Delta-Base headers and an empty body (or whatever ).

>    of the delta encoding? I assume the later is fine.

I'm not sure why HTTP includes both but I see no reason for excluding
compressions. There's no requirement to support any, of course.

> /sean

Anders