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

Self-describing data

Expand Messages
  • Mark Baker
    The relevant test here is, I believe, whether the state of the resource is relevant to the meaning of the message/data, or whether its identity is all that is
    Message 1 of 55 , Jul 3 6:44 PM
    • 0 Attachment
      The relevant test here is, I believe, whether the state of the resource
      is relevant to the meaning of the message/data, or whether its identity
      is all that is relevant. This is a key part of the "self-describing"
      umbrella. As an example, if you were a party to the court action, then
      your identity (via your name) on some document is likely relevant. But
      the colour of your hair probably wouldn't be (as an example of what
      might be returned from GET on my URI).

      In Paul's example there, if the state of the resource was important,
      even if it was believed static, it should have been included in the
      court documents by value rather than by reference.

      MB

      On Thu, Jul 03, 2003 at 06:17:46PM -0700, Paul Prescod wrote:
      > Walden Mathews wrote:
      > > Paul,
      > >
      > > I buy all that, and yet I still have an issue with Tyler's example
      > > of the bank account URI that identifies anyone's account at that
      > > bank, depending on who's fired up their user agent. To me, the
      > > account (identified by the bank sure enough with its own number)
      > > has identity that transcends the clever "my account" resource,
      > > and the legal system is going to be more interested in the former
      > > than the latter, if issues arise. Identity is tricky business.
      > > ...
      > > If the person sitting to my left pilfers from my bank account, I want
      > > the identity of both to be irrefutable, so I guess I won't be dragging
      > > any URI into court.
      >
      > Yes, it seems clear to me that one needs to drag _digitally signed
      > messages_ into courts. Let's say you have a very precise (specific) and
      > URI for a single transaction with a single invariant representation.
      > Then you go to court and you notice that the transaction has changed.
      > The interface said it was invariant but the scoundrels have changed it
      > in the database. You'll be out of luck unless you saved a digitally
      > signed message with the old value.
      >
      > Paul Prescod
      >
      >
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > rest-discuss-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

      --
      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
    • Alex Jacobson
      The only thing that a proxy decides based on the content of the auth headers is caching and if you do cookie-auth you just do more explicit cache-control. And
      Message 55 of 55 , Jul 25 8:07 AM
      • 0 Attachment
        The only thing that a proxy decides based on the content of the auth
        headers is caching and if you do cookie-auth you just do more explicit
        cache-control. And if you are doing auth-related stuff, you should be
        doing more explicit cache control anyway so I don't see the value that
        special purpose auth headers provide.

        -Alex-


        ___________________________________________________________________
        S. Alexander Jacobson i2x Media
        1-212-787-1914 voice 1-603-288-1280 fax

        --On Thursday, July 24, 2003 11:17 PM -0400 Chuck Hinson
        <cmhinson@...> wrote:

        >
        >
        > S. Alexander Jacobson wrote:
        >
        >> cookie-based and HTTP auth are identical when the
        >> client is software. The only difference is the
        >> name of the HTTP header in which the
        >> authentication token is passed. But really the
        >> whole premise of HTTP auth is unreasonable for
        >> automated clients. Clients just send a secret
        >> token. They don't need a mnemonic separating
        >> usernames from passwords.
        >>
        >> For human users, the login form that comes in the
        >> 401 response is as visible as you want. In
        >> practice Mozilla appears to auto-fill most login
        >> forms I reach correctly and without issue which
        >> makes me think that visibility is a non-issue.
        >>
        >> -Alex-
        >>
        >>
        >>
        > Hmmm. I thought visibility was about the ability of
        > components/intermediaries to understand the meaning of the message.
        > I.e., a proxy can't tell whether or not a cookie contains auth info
        > since it doesnt know the syntax of what's been packed in the cookie.
        > However, it does know what the HTTP auth header means, and thus knows
        > what it can or cant do with the message (and its response). (This all
        > may be moot as far as auth headers and cookies go since I think many
        > proxies wont cache things with cookies in them).
        >
        > --Chuck
        >
        >> On Thu, 24 Jul 2003, Chuck Hinson wrote:
        >>
        >>
        >>
        >>> Alex Jacobson wrote:
        >>>
        >>>
        >>>
        >>>> --On Wednesday, July 23, 2003 2:53 PM -0700 "Roy T. Fielding"
        >>>> <fielding@...> wrote:
        >>>>
        >>>>
        >>>>
        >>>>
        >>>>> You should note that there is no design reason why Authorization
        >>>>> and WWW-Authenticate are limited to Basic and Digest. That is why
        >>>>> those fields are extensible. Why would you want to duplicate that
        >>>>> functionality in another field?
        >>>>>
        >>>>>
        >>>>>
        >>>>>
        >>>> With all due respect, given that HTTP authentication is fundamentally
        >>>> broken*, that cookies are a defacto standard, and that HTTP-auth is
        >>>> poorly supported by actual UAs. The bigger question is why duplicate
        >>>> cookie functionality with auth-specific headers?
        >>>>
        >>>>
        >>>>
        >>>>
        >>> I would think that while cookies may be a defacto standard, cookie-based
        >>> authentication is not (i.e., there is no standard implementation of
        >>> authentication using cookies). Thus, it would seem to me that
        >>> visibility still suffers.
        >>>
        >>> --Chuck
        >>>
        >>>
        >>>
        >>>
        >>
        >>
        >>
        >>
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > rest-discuss-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.