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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Jan 2004 10:04:08 -0500

Comment inline.

	Paul

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.

That's a big IF. Do we really want to mandate that every compositor must 
be prepared to provide this? It certainly puts contraints on the 
implementations, and in most cases I think publishers can be constructed 
so that they don't need this capability.

I think the only time you might need this event state is when partial 
publication is in use and the publisher has forgotten the full state, or 
when a backup publisher is trying to pick up from another one. In the 
former case, there is no real advantage over simply transmitting the 
full state as a refresh - same amount of data is required.

The advisability of supporting the latter case seems questionable to me. 
There is a lot of work in providing a real failover backup, and it might 
as well include remembering the state locally. If this capability is 
provided we run the risk of abetting the construction of dualing 
endpoints competing to publish particular event state.

But, if in the end there is a good argument for this capability, then 
the proposal for how to do it seems reasonable.

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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jan 2004 11:37:54 -0500

inline.

> so that they don't need this capability.

The main constraint I think it introduces is that the compositor needs 
to keep around the presence documents from each individual source, in 
addition to the final result of composition. I am not sure if this is 
new; I don't know how it couuld do composition without keeping these 
around.

> publication is in use and the publisher has forgotten the full state, 

Yes, I agree this is one possible use case.

> or 

A fair point.

> endpoints competing to publish particular event state.

I think that is a consequence of a backup takinig over publication for 
a primary, not a consequence of reading the current presence state or not.

> the proposal for how to do it seems reasonable.

My suggestion was mostly along the lines of - this is a good way to do 
it, rather than, we should have this feature. I recall there was a 
3gpp requrement for it, and  I remember asking why it was there, and I 
dont remember the answer, in fact.

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Jan 2004 11:50:03 -0500

Jonathan Rosenberg wrote:
>>> approach that works much better, triggered by some conversations I 
>>> had with Ben C. recently.
>>
>> That's a big IF. Do we really want to mandate that every compositor 
>> must be prepared to provide this? It certainly puts contraints on the 
>> implementations, and in most cases I think publishers can be 
>> constructed so that they don't need this capability.
> 

I think there may be plausible implementations that separate the 
compositor from the PA handling subscribes and generating notifies.

In that case the compositor may have the individual presence document, 
but the PA doesn't.

I'm just concerned about layering on additional behavior that everybody 
must implement.

> it, rather than, we should have this feature. I recall there was a 3gpp 
> requrement for it, and  I remember asking why it was there, and I dont 
> remember the answer, in fact.

I'm in agreement as long as the discussion about IF has yet to happen.

	Paul