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

From: "Brian Stucker" <[email-masked]>
Date: Thu, 13 Dec 2001 01:33:43 -0600

While I can see both sides, that it's definitely an implementation detail, I
also think we should go ahead (as I mentioned in the meeting) and try to
come up with a reasonable expectation for the MINIMUM requirement for the
URI.

I could care less if someone wants to keep the document around for a day, or
go off and fetch it hours later. The information is likely to be incorrect
over periods of time that large.

It's also true, as Paul points out very clearly, that it's pretty obvious
that there need not be an actual document. The HTTP URI could point to some
process that creates a new copy of the document right then and there based
off of stored information. 

So, here's a proposal...

Can we all agree that it's a reasonable expectation that a request URI be
valid for AT LEAST:

1. Some trivial interval, say 90 seconds as a starting point, but that it is
somehow conveyed to the user how long to expect that URL to be good for.
2. The next NOTIFY for that subscription.

The reason I bring this up is so we don't have implementations running
around that assume that the client is going to instantly try to fetch that
URL all the time, and so client devices have enough information to know how
long they can reasonably postpone fetching the document if they're up to
something else when they receive the notification (like a phone call on a
narrowband link). Another reason I bring this up, is so we don't have to
worry about overlapping HTTP addresses where we wind up with two possible
outstanding URLs sitting out there. Simply put, we're limiting and
directing, in a very flexible manner what sort of behavoir to expect out of
the client and the server in order to interoperate correctly.

I am shocked at the amount of vehemence that this topic has created. I just
fail to see why it's such a big deal to simply come to an agreement as to
either how long is reasonable for a client to expect a server to keep a
document around if it doesn't tell the client explicitly, or to otherwise
tell the client so it doesn't make a bad assumption.

I wish someone that feels strongly that this shouldn't be specified, or that
a mechanism for communicating the interval of reason shouldn't be specified,
would explain their discomfort beyond simply saying "that's an
implementation detail". It's an interop detail, and to me that puts it into
the realm of what should be specified.

Cheers,

Brian Stucker

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 6:03 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> 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
> 
> --- Paul Kyzivat <[email-masked]> wrote:
> > 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
> > 
> > Sean Olson wrote:
> > > 
> > > 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 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
>

---

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

On Thu, 2001-12-13 at 01:33, Brian Stucker wrote:
> While I can see both sides, that it's definitely an implementation
> detail, I also think we should go ahead (as I mentioned in the meeting)
> and try to come up with a reasonable expectation for the MINIMUM
> requirement for the URI.
> 
> I could care less if someone wants to keep the document around for a
> day, or go off and fetch it hours later. The information is likely to be
> incorrect over periods of time that large.
> 
> It's also true, as Paul points out very clearly, that it's pretty
> obvious that there need not be an actual document. The HTTP URI could
> point to some process that creates a new copy of the document right then
> and there based off of stored information. 
> 
> So, here's a proposal... 
> 
> Can we all agree that it's a reasonable expectation that a request URI
> be valid for AT LEAST: 
> 
> 1. Some trivial interval, say 90 seconds as a starting point, but that
> it is somehow conveyed to the user how long to expect that URL to be
> good for.

I am not sure that specifying X seconds is really any different than
expecting an instant get, for any value of X. I do think using the
Expires header makes sense, though, which is sort of a variation.

> 2. The next NOTIFY for that subscription. 

I have no problem with that, when combined with the Expires header.

I would also propose subscription termination as another limit for URL
freshness.

> around that assume that the client is going to instantly try to fetch
> that URL all the time, and so client devices have enough information to
> know how long they can reasonably postpone fetching the document if
> they're up to something else when they receive the notification (like a
> phone call on a narrowband link). Another reason I bring this up, is so
> we don't have to worry about overlapping HTTP addresses where we wind up
> with two possible outstanding URLs sitting out there. Simply put, we're
> limiting and directing, in a very flexible manner what sort of behavoir
> to expect out of the client and the server in order to interoperate
> correctly.
> 
> I am shocked at the amount of vehemence that this topic has created. I
> just fail to see why it's such a big deal to simply come to an agreement
> as to either how long is reasonable for a client to expect a server to
> keep a document around if it doesn't tell the client explicitly, or to
> otherwise tell the client so it doesn't make a bad assumption.
> 
> I wish someone that feels strongly that this shouldn't be specified, or
> that a mechanism for communicating the interval of reason shouldn't be
> specified, would explain their discomfort beyond simply saying "that's
> an implementation detail". It's an interop detail, and to me that puts
> it into the realm of what should be specified.
> 
> Cheers, 
> 
> Brian Stucker 
> 
> > From: Sean Olson [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> <http://shopping.yahoo.com>  
> > or bid at http://auctions.yahoo.com <http://auctions.yahoo.com>  
> <http://mailman.dynamicsoft.com/mailman/listinfo/simple>  
> > 
>