Re: Comments on draft-v10-03a.

Daniel LaLiberte:
>No, side-effects are not the issue at all.  

I guess it is time for me to clarify what the `idempotent' issue was
when I started this thread.  I wrote:

|The word `idempotent' is used in a very confusing way in the spec,
|its use is very different from its use in mathematics.

An `idempotent method', as described (defined implicitly) in Section
10.2 of the draft spec should have no bad/unwanted/unintended effects
*whenever* issued.

Thus, `draft-http-spec-idempotent' differs in two ways from
`math-idempotent':

 1) in the mathematical meaning of idempotence, (bad) side effects are
    allowed to be present the first time
 2) in the mathematical meaning, *all* side effects, not just `bad'
    side effects, must be absent the second time.

In my original comment on the spec, I basically requested that any
terminology normally associated with discussions about caching
(terminology like `idempotent' and `side effect') be eliminated from
the security discussion of the spec.

This thread has developed into a discussion about caching, side
effects, and requests that are idempotent in the _mathematical_ sense.
This is topic drift is fine with me, I like discussing caching, but I
do want to point out that this topic drift is exactly the kind of
thing that makes `idempotent' so confusing.

You wrote, about idempotent in the mathematical sense:

>Any particular method may or may not be idempotent, in my opinion,
>whether GET, POST, SEARCH or whatever.  There is no reason to define
>in the spec that a particular method is always (or never) idempotent.
>The server simply tells the client whether a particular use of a
>method is idempotent with the no-cache header, or whatever it is
>called now.

I agree completely.

>Daniel LaLiberte (liberte@ncsa.uiuc.edu)

Koen.

Received on Wednesday, 30 August 1995 15:15:22 UTC