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

From: Brazier Lachlan <[email-masked]>
Date: Thu, 13 Dec 2001 09:24:40 +0100

Hello

I think it needs to be specified what it means, when the URI isn't valid
anymore (Reasons like broken webserver,
no document, ...).

When something like this happens, does the last valid presence document
count? Is the subscription expired or not? 

It just occurs to me, I don't know what it means, when the presence document
doesn't fit the format it is supposed to be.
Does this touch the subscription state?

Any ideas?

Lachlan

-----Ursprüngliche Nachricht-----
Von: Brian Stucker [mailto:[email-masked]]
Gesendet am: Donnerstag, 13. Dezember 2001 08:34
An: 'Sean Olson'; Paul Kyzivat
Cc: [email-masked]
Betreff: RE: [Simple] Duration of URIs in application/uri-list for Presenc e

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 

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

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 13 Dec 2001 02:34:02 -0600

Good questions. I would argue that if the presence document cannot be
retrieved via the URL, that it does not affect the subscription. It would be
analogous to being sent a malformed CPIM-PIDF document in the NOTIFY itself
in my mind.

As far as the SIP Events portion of things are concerned, the duty of the
sip event draft was completed when the URI was given to the client, and what
happens with that URI afterwards has no bearing on the subscription itself.

Regards,

Brian

> -----Original Message-----
> From: Brazier Lachlan [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 2:25 AM
> To: Stucker, Brian [NGB:B635:EXCH]; 'Sean Olson'; Paul Kyzivat
> Subject: AW: [Simple] Duration of URIs in application/uri-list for
> Presenc e
> 
> 
> Hello
>

---

From: Brazier Lachlan <[email-masked]>
Date: Tue, 18 Dec 2001 10:00:16 +0100

Sounds good.
 
Lachlan

-----Ursprüngliche Nachricht-----
Von: Brian Stucker [mailto:[email-masked]]
Gesendet am: Montag, 17. Dezember 2001 17:52
An: Ben Campbell; Paul Kyzivat
Cc: Sean Olson; [email-masked]
Betreff: RE: [Simple] Duration of URIs in application/uri-list for Presenc e

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

---

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

> From: Jonathan Rosenberg [mailto:[email-masked]]
> 
> [email-masked] wrote:
> 
> > Hi All,
> > 
> > 
> >>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.
> 
> 
> Good point.
> 
> Why don't we simplify this, then, and state that the URL is valid for 
> duration in the Expires, if present, otherwise, the duration of the 
> subscription, and that the next NOTIFY overrides the previous 
> URL. This 
> way, if you want the URL validity to be less than the subscription 
> duration, you can do that (Expires < Subscription-Expires), 
> equal to it 
> (no Expires) or greater than it (Expires > Subscription-Expires). We 
> also say that in absense of reasons to do so otherwise, the 
> URL SHOULD 
> be valid for the duration of the subscription, and for 
> fetches, for some 
> reasonable interval, say 2 min.
> 
> That is, we specify semantics that enable any policy, and state a 
> recommended baseline policy.
> 
> -Jonathan R.
> 
> 

Johnathan, that's precisely what was proposed. I don't understand the logic
about the
session making it impossible to fetch a URL. Just because you no longer have
any state in SIP
doesn't mean you can't have state somewhere else. I'd prefer we steer away
from arbitrary timers.

Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 18 Dec 2001 18:58:59 -0600

I didn't understand it at first either, but yes, I am talking about the
expires of zero to do a one-time retrieval of the presence document.

You have a good point about the non-URL case. Jonathan, what's the current
behavior set
for that case? Wouldn't it follow the same pattern?

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 6:48 PM
> To: Stucker, Brian [NGB:B635:EXCH]
> Cc: Jonathan Rosenberg; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> 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: "Brian Stucker" <[email-masked]>
Date: Wed, 19 Dec 2001 13:26:41 -0600

Sorry, meant to say don't put a ZERO expires in there. =)

> From: Stucker, Brian [NGB:B635:EXCH] 
> Sent: Wednesday, December 19, 2001 1:31 PM
> To: 'Sean Olson'; Paul Kyzivat
> Subject: RE: [Simple] Duration of URIs in application/uri-list for
> Presenc e
> 
> 
> Except that Adam's draft doesn't mandate the 
> Subscription-State in the -01 revision (at least to my 
> reading). So you may not have a Subscription-State header, 
> and therefore would need the Expires to be zero if it's a fetch.
> 
> Yes, otherwise the whole issue is moot. Don't put a non-zero 
> expires in there, that makes no sense.
> 
> Brian
> 
> > From: Sean Olson [mailto:[email-masked]]
> > Sent: Wednesday, December 19, 2001 8:48 AM
> > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat
> > Subject: RE: [Simple] Duration of URIs in application/uri-list for
> > Presenc e
> > 
> > 
> > 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
> > 
> > --- Brian Stucker <[email-masked]> 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

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 19 Dec 2001 13:25:54 -0600

Except that Adam's draft doesn't mandate the Subscription-State in the -01
revision (at least to my reading). So you may not have a Subscription-State
header, and therefore would need the Expires to be zero if it's a fetch.

Yes, otherwise the whole issue is moot. Don't put a non-zero expires in
there, that makes no sense.

Brian

> > > Sent: Tuesday, December 18, 2001 3:52 PM
> > > Comments below.
> > > > 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:
> > > > 
> > > 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
> =====
> --
> 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: [email-masked]
Date: Thu, 20 Dec 2001 13:59:28 +0200

Hi,

> and therefore would need the Expires to be zero if it's a fetch. 

The client knows it's a fetch because:
	
	- It sets the Expires to zero in its SUBSCRIBE
	- the 2xx for the SUBSCRIBE carries an Expires: 0

The Expires in NOTIFY should be scoped to only set the expiry for that
particular message content. Subscription-* is there to communicate the
expiry for the whole session.

I don't see why there needs to be anything else specified for the URI-list
case, other than "If you give a link instead of the document, you SHOULD use
Expires to say how long the link is valid for."

An arriving NOTIFY might override some or all of the information given in a
previous URL, and the content of the URL might be invalid, it doesn't really
matter. If notifications carry documents instead, this is anyway
self-evident; older documents are not necessarily valid, especially after
the subscription has been terminated.

I may be missing a point here, but I don't feel there is need to say
anything more about using Expires in a NOTIFY, than what is already said for
the default usage of Expires.

Regards,
Aki

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 20 Dec 2001 09:20:08 -0600

In the draft (as I read it) if you do not include a subscription-expires
(soon to be
subscription-state) in the NOTIFY of a fetch, it should include instead an
EXPIRES of zero.

That would mean the URL should be immediately treated as stale.

That's the problem. If there's always a subscription-expires header there,
then you can put
whatever you want in the EXPIRES header.

It's the normative language on the subscription-expires that makes the
problem possible.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, December 20, 2001 5:59 AM
> To: Stucker, Brian [NGB:B635:EXCH]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked];