Re: [rest-discuss] Expiration
- Lucas Gonze wrote:
>I don't see the benefit of bidding and counter-bidding. It isn't
> Much of your response I need to digest for a few days. The following are only
> those responses that seem solid:
> > Okay, of course expiration counts should go both ways. The client should
> > request one and the server should say what it decided upon.
> Short of having a bid/counterbid/countercounterbid process, which is too hard to
> implement, my suggestion was that we just have
haggling. The subscriber should say what it wants. The publisher is
boss. It should say what it offers. That's it. The question in my mind
is whether the publisher should throw an error when the client asks for
too much or whether it should just say: "The best I could do is X. If
you want to delete the subscription, go ahead."
> > "The message MAY contain a header called "Requested-Expiration"."There are two different relevant parts:
> Sorry, no. I have reloaded the page several times and it still says MUST.
> The message MAY contain a header called "Requested-Expiration".The spec is still working on the "you tell me what I want I'll tell you
> The response to the Subscription MUST include a header called "Subscription-Expiration".
what I decided" model.
>...Standards are not the end-goal but clients and servers (subscribers and
> Standards are not a goal in themselves, and I am not convinced that
> canonicalization is constructive at this early stage.
publishers) that work together without negotiation is a goal and it
takes standards. Even if only six people ever make software that works
together and we are all on this list, the point is that we can only make
software that works together with standards.
>...You're going meta on me. I left a lot of freedom to the implementation:
> Specification is always destructive in that it reduces the available range of
> expression. Overspecifying is not a service.
> > "The client MAY renewAll that is standardized is that the server is "within its rights" to
> > the subscription before this time. If it does not, the server MAY stop
> > sending notifications after that time. The server MAY also remove the
> > Subscription URI." This behavior should be left to the implementation.
stop delivering notifications to the client and forget about it after
the expiry time. The point is the server shouldn't just decide to stop
delivering notifications whenever it feels like. It made a commitment.
>...I understand, but you wedged the door a little bit by going beyond my
> hmm.... a relative date? a compound expression? need to mull this over. I
> would prefer to avoid this kind of negotiation, which leads inevitably to yet
> another programming language.
purely temporal expirations. The nice thing about temporal expirations
is that you know how long you have to renew.
>...How will you even know that's happened? I think that the server should
> For the most part it's not important. Servers currently return 404 whenever it
> pleases them. For the same reasons watches should be assumed to go until they
make a commitment.
----- Original Message -----
From: "Lucas Gonze" <lucas@...>
> * The prefix "Requested-" is redundant. Better wording would be
> "Expiration-Date" and "Expiration-Count".
Would 'max-age' (as applied to the messages) be relevant?
Also, how would you ask for messages from the past (if you had a system with
an 'audit trail'/history)?
The KnowNow stuff has a max-age parameter when creating a subscription, but
I haven't followed this 'expiration' discussion, so it might not be
- I like max-age. Suggest adding an expiration type of Date-relative.
> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Friday, February 01, 2002 12:28 PM
> To: Rest-Discuss; Lucas Gonze
> Subject: Re: [rest-discuss] Expiration
> ----- Original Message -----
> From: "Lucas Gonze" <lucas@...>
> > * The prefix "Requested-" is redundant. Better wording would be
> > "Expiration-Date" and "Expiration-Count".
> Would 'max-age' (as applied to the messages) be relevant?
> Also, how would you ask for messages from the past (if you had a system with
> an 'audit trail'/history)?
> The KnowNow stuff has a max-age parameter when creating a subscription, but
> I haven't followed this 'expiration' discussion, so it might not be
- Per Jeff's suggestion that notifications be one-shot firings that get renewed
when the requester phones in to pick up the resource, much of the expiration
language can go away. However there may still be a need to state the period of
time in which a requester wants to receive that one notification. For example,
an expiration date in the request and/or response.
Since this is a minor issue I don't want to get bogged down in it. Here are the
1) no expiration date
2) expiration specified by requester and either accepted or denied by the
3) hoped-for expiration sent in request and actual expiration sent in response.
I lean towards #1 but don't have strong feelings. #3 is really not bad either.
There is a secondary issue, even more trivial than the first, which is what the
status code should be in the case of #2 above when the responder denies a
request based on expiration field value in the request. I propose a new status
code, 418 "Requested expiration unacceptable." I can't think of any damage this
would cause, and extension codes are acceptable within the RFC. The reason to
have a new status code is to allow clients to diagnose and repair the error.
The best reason to support #1 is that expiration is irrelevant nit picking at
this early stage, and just introduces complication.
In the interest of finishing with this not very interesting feature, up or down
votes for any of the above would be appreciated.
- You don't need expiration if you use GET.
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax