Subject: Re: Protocol: control specifications.

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 08 Jan 2004 16:11:52 -0700

Looks good to me.

>>> "Kurt D. Zeilenga" <[email-masked]> 1/8/04 3:54:50 PM >>>
Though I think you might have misunderstand some of my points,
I likely some of yours, and that we're not exactly seeing eye to
eye on the "why", I think we've converging on acceptable
replacement text. Here is my latest offering:

- guidance as to what value the sender should provide for the
criticality field (note: the processing semantics of the
criticality field, which are defined above, should not be
altered in any way by the control's specification),

Comments? Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 13 Jan 2004 09:12:36 -0700

John,
 
If there were such a control specification, only servers supporting the
control would know to return protocolError when that control is marked
FALSE. All other servers will allow the operation to progress, and the
undesireable results to occur.
 
Also, a client implementation could receive either protocolError or
success (or other) in the resultCode of an operation containing such a
control by two compliant servers. It may even receive these different
results from the same server, depending on configuration state and
control architecture.
 
I'm not sure that this is worth the benefit of having servers that
'slap the hand' of clients that don't properly populate the criticality
field. It does seem more straght forward for servers to keep doing what
has historically been done. That is; examine the control type for
support and applicability, if not supported or innapropriate, check the
criticality field and act accordingly. When the contol is supported and
appropriate, I believe most servers do not even bother making any
decisions (and may not even read or store) the criticality field.
 
Jim

>>> John McMeeking <[email-masked]> 1/13/04 8:22:19 AM >>>

After further discussion here, I side with Hallvard. There are likely
to
be cases where the behavior of a control is such that it really ought
to be
marked critical because the outcome when used with a server that
doesn't
support the control is clearly undesirable. To the end user, it is
little
consolation that the application they are using is at fault because it
neglected to mark the control critical.

I haven't come up with an argument that a control must have
criticality=FALSE to prevent similar situations, so I suggest we get
rid of
the "criticality always set to FALSE" part.

To make it clear that "criticality MUST be TRUE" is a requirement to
both
the client and server and to avoid confusion (I hope) with previous
guidance that criticality always be set to TRUE, I suggest a specific
RFC
"MUST" clause that can be used in future control specifications. I
don't
believe current control specification have such language, so there
should
be no compatibility issue. Support for a new control generally
requires
some sort of server change; support for a new control could include a
mandatory criticality check.

That leaves control criticality options as:
- critical at senders choice, with a recommended criticality in the
control
specification, or
- criticality MUST be TRUE

I suggest that we update protocal 4.1.11 as follows.

1) add the following text somewhere in 4.1.11:

A control specification MAY state that "the control criticality MUST
be
TRUE."
If a control is defined in this way and the sender's control
criticality
is
FALSE, the server MUST return protocolError. If a specification does
not
state that "the control criticality MUST be TRUE" the sender's control
criticality is used.

2) update the guidance to control specification writers:

The specification of a control consists of:

...

- a recommended control criticality, or a requirement that the control
criticality MUST be TRUE.

John McMeeking

"Kurt D. Zeilenga" < [email-masked] > wrote on 01/09/2004 10:11:02
PM:

> At 12:55 PM 1/9/2004, John McMeeking wrote:
> >X.511 has a similar notion of recommended criticality.
>
> Similar or same? Given that one of planned uses of LDAP
> Controls was to provide a mechanism in which additional
> X.511 semantics could be added to LDAP in a manner which
> would facilitate implementation of LDAP<->X.511 gateways,
> I think the intent was for the criticality semantics to
> be the same.

Yes, I could have used "the same".

>
> X.511:
> The criticalExtensions component provides a mechanism
> to list a set of extensions which are critical to the
> performance of a Directory operation. If the originator
> of the extended operation wishes to indicate that the
> operation shall be performed with one or more extensions
> (i.e. that performing the operation without these
> extensions is not acceptable), it does so by setting the
> criticalExtensions bit(s) which corresponds to the
> extension(s). If the Directory, or some part of it, is
> unable to perform a critical extension it returns an
> indication of unavailableCriticalExtension (as a
> ServiceError or PartialOutcomeQualifier). If the Directory
> is unable to perform an extension which is not critical,
> it ignores the presence of the extension.
>
> Sounds the same to me.
>

---

From: John McMeeking <[email-masked]>
Date: Tue, 13 Jan 2004 10:48:22 -0600

See comments below.

John McMeeking

"Jim Sermersheim" <[email-masked]> wrote on 01/13/2004 10:12:36 AM:

> John,
>
> If there were such a control specification, only servers supporting
> the control would know to return protocolError when that control is
> marked FALSE. All other servers will allow the operation to
> progress, and the undesireable results to occur.
>

True, but assuming the application had been tested with a server that
supports such a control properly, the app would not be using
criticality=FALSE.  So the app should get unavailable critical extension.

The concern was going the other way -- an application was developed and
tested on a server that supported the extension, then used with a server
that does not support it.

> success (or other) in the resultCode of an operation containing such
> a control by two compliant servers. It may even receive these
> different results from the same server, depending on configuration
> state and control architecture.

I don't follow this part.  If the control spec says the control critcality
MUST be TRUE, and the client follows this, how would it get protocolError?
I would hope that the current control architectures allow the "control
implementation" to access criticality, as controls now certainly can be
inappropriate (must be able to return unavailable critical extension if
criticality is TRUE), and implementations should be able to return protocol
error if the control value is in error.

> 'slap the hand' of clients that don't properly populate the
> criticality field. It does seem more straght forward for servers to
> keep doing what has historically been done. That is; examine the
> control type for support and applicability, if not supported or
> innapropriate, check the criticality field and act accordingly. When
> the contol is supported and appropriate, I believe most servers do
> not even bother making any decisions (and may not even read or
> store) the criticality field.
>

Folks disagree on this ;-)  I was casting my vote.

I would suggest, then, that if we do not choose to enforce criticality,
that
"always set to TRUE, ... FALSE, or sender's choice" does not add anything
and has been the source of questions that folks have received as to what it
means
when a control is "always critical".  If the server does not enforce
criticality,
a control is, by definition, critical at sender's choice.  X.511 just has a
table
with a column labeled "recommended criticality" (critical or not critical).
Limit
the control specification guidance in 4.1.11 to:

- a recommended control criticality,

> After further discussion here, I side with Hallvard. There are likely to
> be cases where the behavior of a control is such that it really ought to
be
> marked critical because the outcome when used with a server that doesn't
> support the control is clearly undesirable. To the end user, it is little
> criticality=FALSE to prevent similar situations, so I suggest we get rid
of
> To make it clear that "criticality MUST be TRUE" is a requirement to both
> guidance that criticality always be set to TRUE, I suggest a specific RFC
> "MUST" clause that can ! be used in future control specifications. I
don't
> believe current control specification have such language, so there should
> be no compatibility issue. Support for a new control generally requires
control
> A control specification MAY state that "the control criticality MUST be
> TRUE."
> If a control is defined in this way and the sender's control criticality
> is
> FALSE, the server MUST return protocolError. If a specification does not
> 2) update the guidance to control ! specification writers:
>
> "Kurt D. Zeilenga" < [email-masked] > wrote on 01/09/2004 10:11:02 PM:
>
> > performance of a Direc! tory operation. If the originator

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 13 Jan 2004 10:33:22 -0700

>>> John McMeeking [email-masked]> 1/13/04 9:48:22 AM >>
>>

I mean in the case where there is a misbehaving client (which sets
criticality to FALSE).
 
>criticality is TRUE), 
 
Yes.
 
>and implementations should be able to return protocol

Current implementations likely only do this iff the criticality field
is malformed.
 
>- a recommended control criticality,

Yes. I think this is the direction we are likely headed.

Jim