Subject: RE: current control combination proposals

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 17 May 2004 11:44:35 +1000

constrainViolation is only appropriate for update operations.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Chris Ridd
Sent: Sunday, 16 May 2004 01:01
To: Kurt D. Zeilenga; Jim Sermersheim
Cc: [email-masked]
Subject: Re: current control combination proposals

On 14/5/04 11:36 pm, Kurt D. Zeilenga <[email-masked]> wrote:

> At 02:48 PM 5/14/2004, Jim Sermersheim wrote:
>> I'm having a hard time gauging consensus on this. Maybe distilling it to
>> the core changes will help:
> 
> I think it would also help if we surveyed developers of existing
> implementations to ask them how they handle various combinations
> of controls.

Not sure I want to contribute to this thread, but here goes anyway...

Since controls are sent ordered, ie in a SEQUENCE OF, surely we need to
discuss the *permutations* of controls rather than the combinations? In
other words, does a server allow operation X with controls A+B, or with
controls B+A?

If incompatible controls are sent, but one is marked critical and one isn't,
the ordering of the encoded controls may well be significant.

I'd also suggest that an error code that's perhaps appropriate for
signalling "incompatible" controls would be constraintViolation. Sending a
protocolError seems a bit harsh.

Cheers,

Chris

---

From: Chris Ridd <[email-masked]>
Date: Mon, 17 May 2004 07:08:25 +0100

> constrainViolation is only appropriate for update operations.

So far.

Cheers,

Chris

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 17 May 2004 08:11:50 -0700

>> constrainViolation is only appropriate for update operations.

Which is a good reason not to do that.

But Ron's point is quite valid.  ConstraintViolation has a well
established meaning and expanding it to include other error
conditions would cause problems.  A client would have no way
to determine if the error indicated an update problem or
indicated a control problem.  Likewise for most other existing
result codes.

>It would be much nicer of course if result codes were somehow extensible,
>but that's another problem altogether :-)

The resultCode enumeration is extensible.  However, we should
attempt to revise the specification to resolve whatever
issues exist without resorting to adding a new code.

It has been reported that existing implementations return
protocolError here.  What's broke with that?

Kurt

---

From: Chris Ridd <[email-masked]>
Date: Mon, 17 May 2004 16:34:04 +0100

> indicated a control problem.  Likewise for most other existing

Well, I'm not going to defend this to death. The discussion is interesting
enough without thinking about the error code :-)

> The resultCode enumeration is extensible.  However, we should

Not flexibly - there's only a flat number space so different implementations
could easily collide their resultCode extensions.

> issues exist without resorting to adding a new code.

Agreed.

> protocolError here.  What's broke with that?

Well, for one thing no protocol's being broken. It seems a bit severe.
 
Cheers,

Chris

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 17 May 2004 11:39:26 -0700

>Well, for one thing no protocol's being broken. It seems a bit severe.

Realizing that some implementors may have taken a narrow view
over what kinds of errors are indicated by protocolError and the
fact that some existing implementations are using protocolError
here, my question is more intended to ask what problems exist
today (or could exist in the future) due to difference.

If no real problems exist, then its simply a matter of clarifying
the specification to return of protocolError is accectable here.
(Likely be refining both the general description of the code
as well as the text regarding treatment of nonsensical control
combinations.)

If problems exist, then we need to determine how best to resolve
those problems.  Without a description of those problems, I and
others cannot begin to engineer an appropriate fix.

- Kurt