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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 24 Jan 2004 16:44:33 -0500

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.

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.

So, as an example, if I want to publish for sip:[email-masked]:

PUBLISH sip:[email-masked]
Event: presence

<body contains cpim-pidf>

the server responds:

SIP 200 oK
SIP-Etag: sip:9adjsss=[email-masked]

now, I have a handle for the specific event state. To update it:

PUBLISH sip:9adjsss=[email-masked]
Event: presence

<body contains cpimd-pidf>

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.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: "Niemi Aki (Nokia-M/Helsinki)" <[email-masked]>
Date: Wed, 28 Jan 2004 16:24:34 +0200

Hi,

Inline.

ext Jonathan Rosenberg wrote:
> specific published event state. It recommends subscribing to the AOR to 
> learn it. However, it gives this caveat:
> 
> 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.

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

> 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:[email-masked] SIP/2.0
       To: <sip:[email-masked]>
       From: <sip:[email-masked]>;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:[email-masked]>;tag=effe22aa
       From: <sip:[email-masked]>;tag=54321mm
       SIP-ETag: qwi982ks
       Expires: 3600
       Contact: sip:[email-masked];etag=qwi982ks;expires=3600
       Contact: sip:[email-masked];etag=hh3j4kll;expires=3229
       Contact: sip:[email-masked];etag=3ihy4hhk;expires=1200