Subject: [Simple] Duration of URIs in application/uri-list for Presence

From: Sean Olson <[email-masked]>
Date: Wed, 12 Dec 2001 13:29:08 -0800 (PST)

Just a follow up to meeting discussion. 
There seemed to be consensus that there is a 
need to clarify the duration of validity of
URIs carried in application/uri-list body
of a presence NOTIFY.

Since this type of payload in a NOTIFY is 
meant as an alert that a change has occurred
without directly carrying the change in the
body and since there is a desire to maintain
equivalent semantics with the case where the
NOTIFY *does* carry the actual presence document,
I propose the following:

At a default the URI list should contain a HTTP
URL. This HTTP URL should be valid *at least*
for one HTTP GET request. This is exactly the 
guarantee you have when you receive a NOTIFY
with a presence payload. Any duration longer
than a single HTTP fetch should be allowed
but should be completely up to the implementation.

/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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Dec 2001 18:25:37 -0500

Sean Olson wrote:

[snip]

> but should be completely up to the implementation.

What if the recipient waits a few hours (or days)
before issuing the GET? Must the URL still be valid?
I don't think that you can reasonably mandate that it
must.

Can you really require much more than that the URL
is valid for a GET at the time the message referencing
it is sent?

---

From: Sean Olson <[email-masked]>
Date: Wed, 12 Dec 2001 15:43:18 -0800 (PST)

Good point. The issue is how long do you keep
this around after the 200 OK for the NOTIFY is
received. Seconds, minutes, hours. My initial
impression is to keep the state around on the
web server for the duration of the subscription.
In any event, couldn't this duration be communicated
in the Expires: header of the NOTIFY?

/sean

=====

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Dec 2001 18:56:52 -0500

Sean,

The obvious thing to do, if the web server and the presence server are
sufficiently integrated, is to have the URL encode the identity of the
subscription. Then when a GET is received, the then-current presence
document can be returned. Nothing special need be kept that isn't
already being kept by the presence server. It doesn't matter if the
presence document has changed value serveral times between when the url
was returned and when it is fetched.

But while this is a reasonable and obvious thing to do, I don't think it
ought to be mandated.

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. 

Seems to me that this just has to be left to common sense and the
judgment of the marketplace.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Wed, 12 Dec 2001 16:02:38 -0800 (PST)

I'm perfectly happy to leave this as an implementation
detail -- that is what I argued for in the meeting.
I was just trying to come up with a solution that
would be reasonable to insert in the draft to
satisfy those that thought it should be standardized.
cheers,
sean

=====

---

From: Ben Campbell <[email-masked]>
Date: 13 Dec 2001 10:50:22 -0600

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

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Dec 2001 13:19:50 -0500

> 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

---

From: Ben Campbell <[email-masked]>
Date: 13 Dec 2001 12:29:37 -0600

> received, even if the old one has not yet expired.

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.