Re: [Sip] querying the current event state of a publication

["Niemi Aki (Nokia-M/Helsinki)" <[e-mail]>]

Hi,

Inline.

ext Jonathan Rosenberg wrote:
> In draft-ietf-sip-publish-02, section 5.7 proposes a way to query a 
> specific published event state. It recommends subscribing to the AOR to 
> learn it. However, it gives this caveat:
> 
>  Note that a subscription to the event package will likely deliver
>       results of the event composition process of the state agent, which
>       may be a subset or a superset of the current published event
>       state.
> 
> which is another way of saying, that subscribing to the aor doesnt 
> really allow you to query for a specific published event state.
> 
> If we want this functionality, I have an idea for an alternative 
> approach that works much better, triggered by some conversations I had 
> with Ben C. recently.
> 
> In the response to a PUBLISH request, the ESC returns a URI that 
> identifies that particular event state publication (effectively, a URI 
> that is bound to the AOR+event+etag of a publication). This URI is 
> basically a GRUU. If a user wishes to learn the state of this particular 
> event state, they merely subscribe to that URI. Indeed, a particularly 
> interestinig way to do this is to define sIP etags as URIs, rather than 
> reusing the definition from http. I think that having an etag as a URI 
> is far more elegant, as it would allow for things like this function in 
> a natural way. The alternative would be to possibly use the Contact 
> header field, as the meaning is the same as in a 2xx to INVITE - 
> identifying the specific *instance* to which you were connected when you 
> contacted the AOR. This makes sense if you think of the event state 
> publication URI as a GRUU.

But a PUA has to know the state it just published, simply because it was 
the source of that state in the first place. What it can't learn is the 
state of the other active PUAs.

And this is actually something currently missing from PUBLISH. A given 
PUA can't find out about publications other than thiose it itself has 
made. As a consequence, it can't for example, override the publications 
of a zombie PUA (a use case we have discussed in the past at length).

In order to enable a PUA to find out about the *other* publications to a 
given resource, the ESC would have to return not only a pointer to this 
PUAs publication, but to all active publications for that AoR. This is 
very similar to a registrar returning all active address bindings of an AoR.

> Indeed, one might even then PUBLISH to that URI, and it would have the 
> exact result you would expect - that particular event state is updated. 
> In such a case the server woould NOT return an etag or another URI in 
> the response.

When you add the feature I describe above, etags would still be needed 
since it would allow two PUAs to publish to the same instance of state. 
Etags would be needed for versioning in that case.

<snip />

> This would mean we wouldnt need the SIP-If-match.
> 
> Another alternative is to say that we are simply too far along in 
> PUBLISH, and the time has passed for major changes as this would be.

I do think we are quite far along in PUBLISH for adding this sort of 
functionality. However, I see some low-hanging fruit here, and to be 
honest, it has always bothered me a bit that there is no way for a PUA 
to know about the state other PUAs are publishing.

There is a requirement that calls for basically exactly this in 
draft-ietf-simple-publish-reqs-00 and it states:

    14.  PUAs must have a capability that allows them to query for the
         identifiers of all of the segments of presence information that
         have currently been published for a presentity (provided that
         the PUA is authorized to receive this information).

Using the register-like behavior for returning the set of active state 
in the 2xx response to PUBLISH + having this set be a set of GRUUs would 
fulfill the above. The PUA would be able to query the state (using 
SUBSCRIBE), but also override it (using PUBLISH). This is also a 
requireemnt in the reqs draft:

   15.  It must be possible for the publication of presence information
         for a particular segment to overwrite existing information for
         that segment, even if the existing information had been
         published by a different PUA. ...

So I would be willing to add this functionality simply because it would 
make the solution more complete. As far as adding complexity, sure, but 
an ESC whose policy doesn't allow cross PUA state could always just 
refuse to send the publication contacts in the PUBLISH response.

Does this sound reasonable?

Cheers,
Aki

P.S. I added an example message flow to illustrate the above ramblings...

---

PUA publishes its (initial) state:

       PUBLISH sip:[e-mail] SIP/2.0
       To: <sip:[e-mail]>
       From: <sip:[e-mail]>;tag=54321mm
       Expires: 3600
       Event: presence
       ...

ESC returns with an etag for that state, plus all active publications in 
the form of URIs:

       SIP/2.0 200 OK
       To: <sip:[e-mail]>;tag=effe22aa
       From: <sip:[e-mail]>;tag=54321mm
       SIP-ETag: qwi982ks
       Expires: 3600
       Contact: sip:[e-mail];etag=qwi982ks;expires=3600
       Contact: sip:[e-mail];etag=hh3j4kll;expires=3229
       Contact: sip:[e-mail];etag=3ihy4hhk;expires=1200


> Thoughts?
> 
> -Jonathan R.
> 

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