Re: State, when to use GET, and accountability

Noah, 
the current definition of safety from the AWWW document talks about not
*incurring* obligations. In particular, "If an agent does not have an
obligation before a safe interaction, it does not have that obligation
afterwards." 

I assume the resources with reliable logging would be authenticated
(otherwise the log would be unreliable). By logging in, the user would
agree to the logging of their actions (that would be in the conditions
of acquiring an account) and therefore no new obligations would be
incurred with those GETs.

Please correct me if I'm wrong, but as far as I can see, this is a
useful view of safety. In particular, I can't see anybody triggering
anything they shouldn't do by using, let's say, a web accelerator that
opportunistically pre-fetches links.

Best regards,
Jacek

On Thu, 2007-03-01 at 14:53 -0500, noah_mendelsohn@us.ibm.com wrote:
> Dave:  I know you're collecting ideas for the finding on State in Web 
> application design.  One aspect of this that I understand is coming up 
> increasingly is the legal need in many contexts for certain enterprises to 
> reliably record every access that is made to certain data.  In such cases, 
> an obligation of a sort is implicit in every access, and presuming HTTP 
> GET in particular is inappropriate.  I think this is a real world issue 
> for many users of Web technology.  I'm thinking it might be the basis of 
> an interesting use case, though I'm somewhat on the fence as to whether it 
> fits better in the whenToUseGET space.  The fact that there are side 
> effects of the access seems to be whenToUseGet, but I imagine that in many 
> cases it will be important to record not just that an access has occurred, 
> but also information about the higher level interaction (session?) in 
> which the access occurs.  That might bring a tie in to the state finding.
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
>

Received on Thursday, 1 March 2007 21:27:25 UTC