Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

Julian Reschke wrote:
> OK, to summarize: your point is that PUT doesn't have the strict 
> semantics (that I claim it has). Let's just agree that we disagree here.

Actually I'm saying it isn't implemented with strict semantics in practice.
I hope we don't disagree about that ;)

Which means there is no point pretending it does have strict semantics
for the purpose of access control to an unknown server.

> 
> >That said, even if you do specify ADDMEMBER more tightly, I still
> >don't see how the difference would benefit you.  You say it could be
> >useful to an intermediary, but can you give a plausible example?
> 
> Did I?

Ah.  It wasn't you who mentioned intermediaries needing to know what
the method will do.

In response to:
>> Why can't you POST to the container resource?
>> That's what POST is for, after all.

You said this:
> Because in general, I will have no idea what the server will do with the 
> POST.

which I took to mean you wanted to be sure of what would happen,
perhaps with a view to a security policy or intermediary behaviour.
My mistake.

So I'll humbly rephrase my question:

Even if you do specify ADDMEMBER more tightly (than POST), I still
don't see how the difference would benefit you.  You say it is useful
to have an idea what the server will do with a POST, in general.  In
general means an arbitrary URI with unknown properties, because if
it's a URI with known properties, you know exactly what POST will do.

How does specifying ADDMEMBER to have tighter semantics than PUT and
POST benefit you when sending the request to an arbitrary URI with
unknown properties?  Can you give an example?

Thanks,
-- Jamie

Received on Thursday, 17 February 2005 22:49:54 UTC