RE: Interop issue: how can clients force authentication?

I believe the problem statement is:

The problem: A client wants to check if the current user is
authenticated to do an operation before it has that user provide the
input for that operation, and before it performs expensive 
computations to set up the input for that request.

The proposal: Document in the 2518bis that the authentication check
SHOULD be performed before the If header check (so that a simple
contradictory If header can be used to check the authentication for
"dummy version" of the operation, i.e. one with dummy values that did
not require user input or expensive calculations on the client).

As a general design note wrt some of the alternatives proposed:
Adding new protocol semantics (e.g. a new header) for each interesting
use case would rapidly produce a protocol so complex as to be
unusable.  I believe adding explicit marshalling for semantics that
are already supported adds complexity, not clarity, and that increased
complexity will increase the implementation errors, not decrease them.

Cheers,
Geoff


-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]


On Thursday, 09/19/2002 at 02:27 MST, Ilya Kirnos wrote:
> the fact that this may already work with some implementations is a plus.
on
> the other hand it would pretty much be a hack.  when i see something like
> If: ("a" Not "a"), client authentication is not exactly the first thing
that
> comes to mind.  a new header would make this idea very explicit and
probably
> less prone to implementation errors.  however, i'd like to see this
feature
> implemented in some shape or form, so if there's consensus on the If
header,
> it'd be fine with me.

I'd like to see two things...

1) A clear problem statement with scenarios
2) A clear statement of the/this proposal

Thanks guys

J.

Received on Friday, 20 September 2002 08:40:05 UTC