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

[Jonathan Rosenberg <[e-mail]>]

Firstly, I'm inclined to back away from my prior suggesting of using 
URIs instead of etags, primarily because I think we are just too far 
along here and "if it aint broke, don't fix it". We can probably get the 
missing piece of functionality - finding out who else is publishing - in 
ways that dont change what we have documented.

Your suggestion below is reasonable towards that end, but makes me 
nervous that it introduces a behavior that is *like* registration, but 
isnt the same (no  contacts in the publish request, for example).

Another possible idea is to create a new event package which is the 
"esc" event package. When you subscribe to a URI for that package, you 
get notified of all published documents made against that URI. The 
current state of the resource for that package is a list of the 
currently active documents for that URI. By doing this as an event 
package, we can leave PUBLISH alone, and add this functionality in the 
future, as a separate item.

-Jonathan R.

Niemi Aki (Nokia-M/Helsinki) wrote:

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

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip