Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e

From: "Brian Stucker" <[email-masked]>
Date: Tue, 18 Dec 2001 17:25:33 -0600

The reason I mention the fetch is because in the sip-events draft, you can
have a NOTIFY with an expires of zero,
and no subscription-expires (the subscription-expires is only a SHOULD,
presumably to keep from deprecating implementations from the -00 draft).

So, if your client KNOWS that it just did a fetch, then the problem as has
been pointed out is that the NOTIFY could come back with no
subscription-expires header, an Expires header set to zero (to denote that
the subscription is over as there never was one), and with a presence URL
(because it's a fetch). In this case the client shouldn't treat the URL as
dead-on-arrival even though the NOTIFY looks just like a "stupid"
dead-on-arrival notify. I think this is what Aki was getting at, and it's a
good point.

Either we agree to a set interval, as Jonathan has suggested (which I'm fine
with), or we agree that when a URL is to be sent back in NOTIFY that was
sent because of a fetch operation, that there MUST be a
subscription-expires, and the expires header can't be zero. Otherwise, URLs
returned as part of a fetch operation where the optional
subscription-expires header isn't present would either be immediately stale
(as Aki pointed out), or would be valid for an undetermined amount of time
(which is what we're trying to avoid).

Regards,

Brian Stucker

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 3:52 PM
> To: Stucker, Brian [NGB:B635:EXCH]
> Cc: Jonathan Rosenberg; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> Comments below.
> 
> > Brian Stucker wrote:
> > 
> > The problem is that, the wording that was given earlier meant that a
> > fetch
> > was not possible because the URL would only last until the
> > subscription expired.
> > 
> > Ahh.. Now I see it. Ok. Yes, there is a problem Aki.
> > 
> > So the logic needs to be revised, which is what Jonathan was talking
> > about. Now
> > I understand. It seems that (nearly) everyone was intent on not
> > specifying a
> > standard interval for the URL to be good for. So, with that in mind,
> > how about:
> > 
> > 1. The URL is good for the interval expressed in the EXPIRES
> > header of the notification which contained the presence
> > document URL, or the Subscription-Expires (soon to be
> > Subscription-State), whichever is shorter.
> 
> I think this is wrong. How about:
> 
>   1. If the notification which contained the presence document URL
>   also contained an Expires header, the URL is good for the interval
>   expressed in that header.
> 
> This permits the document referenced by the URL to outlast
> the subscription, if that is what the notifier desired.
> The case where there is Subscription-Expires but not Expires
> is covered by 5.
> 
> > 
> > 2. If another notification is received during the interval
> > identified in (1), then the previous URL should be considered
> > stale. The most recent notification always takes precedence.
> > 
> > 3. If a persistient subscription (not a fetch) ends, any
> > presence URLs associated with that subscription should be considered
> > stale.
> > 
> > 4. If a notify is received with an EXPIRES set to zero, the
> > URL is considered dead-on-arrival.
> 
> It would be stupid to do this. Since it is both stupid and a
> special case of 1, no need to mention.
> 
> > 
> > 5. If a notify is received without an EXPIRES header, the URL
> > is good for the duration of the subscription.
> > 
> > 6. If a notify is received due to a subscription fetch, the URL
> > is good for the interval expressed in the EXPIRES header of the
> > notification which contained the presence document URL.
> 
> I don't understand this. What do you mean by a "subscription fetch"?
> Does this say anything not covered by one of the other points?
> 
> 	Paul
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Dec 2001 19:47:45 -0500

I'm sorry, but I am still not sure I understand what you mean about a
subscription fetch. Do you perhaps mean sending a SUBSCRIBE with an
Expires of zero to do a one-time retrieval of the presence document?

If so, I think this does present an ugly case. I think the presence
server must return a non-zero Expires value, or else the client can take
its chances with no guarantees. Note that this is new behavior because
there aren't any presence servers returning URI-LIST yet.

Of course the same problem exists to an extent even if you request the
presence document. But then at least you have the document to look at
even if it has expired. It doesn't have to do anything to be used. With
the URL, the server hosting the URL has to honor it before it is useful.

	Paul

> Brian Stucker wrote:
> 
> The reason I mention the fetch is because in the sip-events draft, you
> can have a NOTIFY with an expires of zero,
> and no subscription-expires (the subscription-expires is only a
> SHOULD, presumably to keep from deprecating implementations from the
> -00 draft).
> 
> So, if your client KNOWS that it just did a fetch, then the problem as
> has been pointed out is that the NOTIFY could come back with no
> subscription-expires header, an Expires header set to zero (to denote
> that the subscription is over as there never was one), and with a
> presence URL (because it's a fetch). In this case the client shouldn't
> treat the URL as dead-on-arrival even though the NOTIFY looks just
> like a "stupid" dead-on-arrival notify. I think this is what Aki was
> getting at, and it's a good point.
> 
> Either we agree to a set interval, as Jonathan has suggested (which
> I'm fine with), or we agree that when a URL is to be sent back in
> NOTIFY that was sent because of a fetch operation, that there MUST be
> a subscription-expires, and the expires header can't be zero.
> Otherwise, URLs returned as part of a fetch operation where the
> optional subscription-expires header isn't present would either be
> immediately stale (as Aki pointed out), or would be valid for an
> undetermined amount of time (which is what we're trying to avoid).
> 
> Regards,
> 
> Brian Stucker
>

---

From: Sean Olson <[email-masked]>
Date: Wed, 19 Dec 2001 06:47:40 -0800 (PST)

I would argue that if the server wants to return
a list of URLs and if those URLs should be
valid for a duration longer than zero seconds,
then the Expire: header should be non-zero.
A zero value for the expires parameter of the
Subscription-State: header could be used to
indicate that this is a "fetch" with no 
actual subscription session. With this in mind,
there is no reason to define any arbitrary interval.

/sean

=====
--
Sean Olson <[email-masked]>
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple