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

From: "Brian Stucker" <[email-masked]>
Date: Tue, 18 Dec 2001 09:38:20 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> 
> Hi All,
> 
> > 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.
> 
> Overall, I like the sound of this proposal. However, a 
> distinct linking like
> this between the Subscription-Expires and Expires assumes 
> that subscriptions
> always establish a session. This assumption makes a fetch of 
> event state
> impossible using the URL mechanism.
> 
> 
> Cheers,
> Aki
> 

Why? All the expires is telling us to do with the URL is to direct us as to
how long to cache the URL for (if it's to be cached at all). If you did a
fetch, you could get a NOTIFY back with "subscription-state: terminated 0"
and an "expires: 90" (or whatever). The contents of the NOTIFY would be good
for 90 seconds, the subscription has terminated immediately, here's your
URL.

Am I missing something?

Brian Stucker

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Dec 2001 11:39:52 -0500

Jonathan Rosenberg wrote:
> 
> The original proposal was that the URL was valid until either the
> Expires duration ends, or the subscription terminates, whichever happens
> first. Since fetches are nothing more than subscriptions with zero
> duration, this would mean that the URL would be invalidated immediately.

How did you reach the conclusion stated in the last sentence above?

I think one valid implementation might be that a fetch of the URL
returns the same thing that a new subscription with a zero duration
would return. But if so, I don't think that should affect the status of
the original subscription that returned the URL, or the validity of the
URL itself.

Another valid (though perhaps suboptimal) implementation might be for
the notification that returns a URL to actually format the notification,
store it as a file, and return a URL for that file. The file might
remain indefinitely, regardless of what subsequently happens to the
subscription or the state of the presentity subscribed to.

The rules ought to permit both sorts of implementations, and behave in a
comparable way for both.

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