Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Expiration

Expand Messages
  • Paul Prescod
    ... I don t see the benefit of bidding and counter-bidding. It isn t haggling. The subscriber should say what it wants. The publisher is boss. It should say
    Message 1 of 8 , Jan 31, 2002
    • 0 Attachment
      Lucas Gonze wrote:
      >
      > 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
      > bid/reject/bid-1/reject/bid-N/accept.

      I don't see the benefit of bidding and counter-bidding. It isn't
      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"."
      >
      > Sorry, no. I have reloaded the page several times and it still says MUST.

      There are two different relevant parts:

      > The message MAY contain a header called "Requested-Expiration".

      > The response to the Subscription MUST include a header called "Subscription-Expiration".

      The spec is still working on the "you tell me what I want I'll tell you
      what I decided" model.

      >...
      > Standards are not a goal in themselves, and I am not convinced that
      > canonicalization is constructive at this early stage.

      Standards are not the end-goal but clients and servers (subscribers and
      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.

      >...
      > Specification is always destructive in that it reduces the available range of
      > expression. Overspecifying is not a service.

      You're going meta on me. I left a lot of freedom to the implementation:

      > > "The client MAY renew
      > > 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.

      All that is standardized is that the server is "within its rights" to
      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.

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

      I understand, but you wedged the door a little bit by going beyond my
      purely temporal expirations. The nice thing about temporal expirations
      is that you know how long you have to renew.

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

      How will you even know that's happened? I think that the server should
      make a commitment.

      Paul Prescod
    • S. Mike Dierken
      ... From: Lucas Gonze ... Would max-age (as applied to the messages) be relevant? Also, how would you ask for messages from the past (if
      Message 2 of 8 , Feb 1, 2002
      • 0 Attachment
        ----- 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
        relevant.
      • Lucas Gonze
        I like max-age. Suggest adding an expiration type of Date-relative.
        Message 3 of 8 , Feb 2, 2002
        • 0 Attachment
          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
          > relevant.
          >
          >
          >
          >
        • Lucas Gonze
          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
          Message 4 of 8 , Feb 2, 2002
          • 0 Attachment
            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
            options:
            1) no expiration date
            2) expiration specified by requester and either accepted or denied by the
            responder.
            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.
          • S. Alexander Jacobson
            You don t need expiration if you use GET. -Alex- ___________________________________________________________________ S. Alexander Jacobson
            Message 5 of 8 , Feb 2, 2002
            • 0 Attachment
              You don't need expiration if you use GET.

              -Alex-
              ___________________________________________________________________
              S. Alexander Jacobson i2x Media
              1-212-787-1914 voice 1-603-288-1280 fax
            Your message has been successfully submitted and would be delivered to recipients shortly.