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

From: "Brian Stucker" <[email-masked]>
Date: Tue, 18 Dec 2001 13:57:28 -0600

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:

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

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.

This would require that the sip-events draft change the normative language
in Section 4.3.5 of the -01 draft.

Adam?

Cheers,

Brian Stucker

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 10:40 AM
> To: Jonathan Rosenberg
> Cc: Stucker, Brian [NGB:B635:EXCH]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presenc e
> 
> 
> 
> 
> 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
>

---

From: Sean Olson <[email-masked]>
Date: Tue, 18 Dec 2001 12:29:14 -0800 (PST)

> stale. The most recent notification always takes

I would like this to be a "SHOULD" strength
condition and not a "MUST". 

> should be considered stale. 

There is no need for a special case here. The
text in bullet 1 covers both a "fetch" as well
as a long running subscription.

> URL is considered dead-on-arrival. 

This is an extremely odd case. Wouldn't an 
empty body be more appropriate. Can someone
give a real world example of when this would
be used?

> in Section 4.3.5 of the -01 draft.

/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: Tue, 18 Dec 2001 16:52:05 -0500

Comments below.

> Brian Stucker wrote:
> was not possible because the URL would only last until the
> subscription expired.
> 
> So the logic needs to be revised, which is what Jonathan was talking
> about. Now
> 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.

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

> 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