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

From: "Brian Stucker" <[email-masked]>
Date: Mon, 17 Dec 2001 10:51:46 -0600

I agree with Ben. Although you raise good points Paul.

Can we all agree to:

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.
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 the subscription 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.
5. If a notify is received without an EXPIRES header, the URL is good for
the duration of the subscription.

Cheers,

Brian

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:30 PM
> To: Paul Kyzivat
> Cc: Sean Olson; [email-masked]
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> On Thu, 2001-12-13 at 12:19, Paul Kyzivat wrote:
> > 
> > 
> > Ben Campbell wrote:
> > > 
> > > On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote:
> > > >
> > > > Your other suggestion - to use the Expires header to 
> convey how long the
> > > > URL will remain valid is another possibility, but one 
> that is perhaps
> > > > not very useful. For instance, that duration may not be 
> known, such as
> > > > when the technique above is being used. And there is 
> nothing to prevent
> > > > returning Expires:0, which would then be accurate but 
> not useful.
> > > 
> > > How is that different from a normal presence expiration? 
> One assumes
> > > that if the presence state changes before I get around to 
> getting the
> > > data, I would get a new notify if I am still subscribed.
> > 
> > Perhaps it isn't different, but it depends on how you interpret the
> > Expires header.
> > 
> > In a NOTIFY there is a difference between Expires and
> > Subscription-Expires.
> > Expires applies to the specific notification. 
> > 
> > If you interpret Expires for something like MESSAGE, it 
> presumably says
> > something about how long the message content is meaningful. This is
> > probably independent of any other messages that you might 
> subsequently
> > receive. So if I send you a message asking if you want to 
> go to lunch
> > today, I can set the expiration to the time I intend to 
> leave for lunch.
> > I can then send you other unrelated messages with different 
> expirations,
> > but they leave my lunch invitation unaffected.
> > 
> > With the presence notification however, when sending it I in general
> > don't know how long it will be valid. Generally it will be 
> valid until I
> > send another one. I could include an Expires header with 
> the same value
> > as Subscription-Expires, and that would be correct if there are no
> > further changes until expiration. But it will be rendered 
> incorrect as
> > soon as I send out a revised notification.
> > 
> > So at the least, expires values for notifications need to 
> be taken with
> > a grain of salt. Old ones need to be discarded when new ones are
> > received, even if the old one has not yet expired.
> > 
> > 	Paul
> 
> I understand that. Expires in no way guarantees that the 
> presence state
> will not change before expiration. It does, however, give you 
> a maximum
> time for the presence state, that is, you should assume it is stale
> after expiration, unless you have received other information to the
> contrary.
> 
> That seems to map very closely to the model for the expiration of URLs
> in a NOTIFY, if you say that you have a reasonable expectation of the
> URL being good if it has not expired and you have not received a new
> NOTIFY. The error scenario is when you miss a NOTIFY, but we have that
> exact scenario when we deliver full presence docs in the NOTIFY.
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Sean Olson <[email-masked]>
Date: Mon, 17 Dec 2001 08:57:08 -0800 (PST)

This sounds like a very good proposal.
Anything more complex would start to infringe
on the implementors domain.

Cheers,
Sean

--- Brian Stucker <[email-masked]> wrote:
> Subscription-Expires (soon to be
> Subscription-State), whichever is shorter.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Dec 2001 12:42:52 -0500

This is ok with me.

	Paul

> Brian Stucker wrote:
> 1. The URL is good for the interval expressed in the EXPIRES header of
> the notification which contained the presence document URL, or the
> 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.
> 
> 5. If a notify is received without an EXPIRES header, the URL is good
> for the duration of the subscription.
> 
> Cheers,
> 
> Brian