RE: Protocol: control specifications.

Jim

>>> John McMeeking <jmcmeek@us.ibm.com> 3/1/04 7:23:46 AM >>>

I think Hallvard is arguing that 1B -- a control incorrectly marked with
criticality = FALSE -- should result in a failure. My reading of X.511says
that 1A is not an error (at least not to X.511).

Here's what I can find in X5.11 (1993 & 2001) on critical extensions:

7.3.1

...

These Directory Specifications defines a number of extensions. The
extensions take such forms as additional numbered
bits in a BIT STRING, or additional components of a SET or SEQUENCE, and
are ignored by 1988 edition systems.
Each such extension is assigned an integer identifier, which is the
number of the bit that may be set in
criticalExtensions. If the criticality of an extension is defined to be
critical, the DUA shall set the corresponding bit in
criticalExtensions. If the defined criticality is non-critical, the DUA
may or may not set the corresponding bit in
criticalExtensions.

The extensions, their identifiers, the operations in which they are
permitted, the recommended criticality, and the clauses
in which they are defined are shown in Table 1.

The "shalls" cover what the DUA is supposed to do. I don't know what the
DSA is supposed to do in response to a request that uses a critical
extension but does not have the criticality bit set. In some cases that
bit is the only protocol element associated with the extension, and it
other cases, X.511 uses similar language: if the abc field is present, the
xyz criticality bit shall be set.

X.511 uses a recommended criticality of "critical" in cases where it is
highly unlikely (at least) that a DUA would be content with the extension
be ignored. For example, the X.511 equivalent of modify DN with new
superior, is an extension with recommended criticality of critical. I
think the DSA could reject this request and be within bounds of a
reasonable interpretation of X.511, and I think that the application
developer / user would appreciate such behavior once they considered the
consequences of using such an application with a DSA that didn't support
the extension. I'd sure hate to find out that the extension had been
ignored.

I favor language to the effect that:

A control specification SHOULD include the recommended criticality of a
control. The control specification may specify the recommended criticality
as critical or not-critical. If the control specification defines a
control as critical, the client MUST set the control criticality to TRUE; a
server SHOULD reject requests that include this control with a criticality
of FALSE. If the control specification defines a control as not-critical,
the client can set the control criticality to TRUE or FALSE. [and include
past language about how server honors controls it supports and are
appropriate to the operation, and returns unavailableCriticalExtension for
controls marked critical that it does not support or are not appropriate to
the operation].

I think this language should keep us out of trouble with respect to
existing implementations, beats RFC 2251's "always critical, never
critical, ..." language, keeps us in line with X.511, and provides a
mechanism to discourage unsafe applications that happen to work great on
the server they were initially tested with.

John McMeeking

"Ramsay, Ron"
< Ron.Ramsay@ca.co
m> To
Sent by: "Hallvard B Furuseth"
owner-ietf-ldapbi < h.b.furuseth@usit.uio.no >
s@OpenLDAP.org cc
< ietf-ldapbis@OpenLDAP.org >
Subject
02/29/2004 10:26 RE: Protocol: control
PM specifications.

Hi Hallvard,

I can't help feeling that you have answered your own question. Let's look
at the cases:

1A: Server implements control and criticality incorrectly marked TRUE
1B: Server implements control and criticality incorrectly marked FALSE
2A: Server does not implement control and criticality incorrectly marked
TRUE
2B: Server does not implement control and criticality incorrectly marked
FALSE.

The server response is

1A: Server must use the information in the control to perform the
operation. The result returned is the result of performing the operation;
the server cannot advise the client on the use of controls
1B: This is the same as 1A: if a server CAN perform a control, it MUST
perform it. Servers have no discretion when it comes to controls
2A: Server returns unavailable critical extension
2B: Server ignores the control.

That is, a server cannot make a comment about whether the criticality of
the control is correct. This is because a server MUST take the control into
account if it understands (implenments) it. If the server implements the
control, it doesn't matter if the criticality is TRUE or FALSE.

Therefore, advice on the criticality of the control can only apply to
clients. And servers cannot educate clients in this regard. As the
discretion is with the clients, control designers should direct there
remarks concerning criticality to the client writers.

Of course, there is the issue of response controls, but it seems that the
criticality of these controls should always be FALSE.

Ron

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Hallvard B Furuseth
Sent: Friday, 27 February 2004 19:46
To: Kurt D. Zeilenga
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Protocol: control specifications.

I should have replied to this before, but I got so frustrated that just
had to quit the discussion for a while. I'll rush off a reply now
before going on holiday, just so it comes before the next IETF. Sorry
about the bad timing, and about setting this up so I can't reply in
time.

Kurt, I think we have said to each other what there is to say about my
proposal: that servers SHOULD reject incorrect criticality on known
controls. However, you have not replied several of the my points about
your proposal. An argument against my suggested change is _not_ an
argument for the opposite change.

- You say the intent of the original text was to encourage extension
authors to discuss the circumstances of when particular criticality
values are appropriate. I wonder how you know that, since it is
very different from what rfc2251 says.

- X.500 does mostly mandate criticality TRUE when criticality is
mentioned, not merely recommend it. Though there is one place
where it only recommends. I don't know if a wrong criticality in
X.500 is an error which MUST be reported, or MAY be reported, or what.

- I can't see that the current text allows the control spec to mandate a
particular criticality, it only says the spec can give 'direction' for
the value. You said somewhere that 'direction' might be a mandate.
If so, the text in [Protocol] should mention that explicitly.
Also, it should make clear if it is talking about mandating the
criticality protocol field, or the criticality value as used by
the server (maybe ignoring the protocol field), or either.

- The original text could be read as allowing the server to return an
error if the wrong criticality is supplied. I can't see the new text
saying that. I don't remember at the moment what who ended up meaning
about that, except it took some rounds of clarifications because you
misunderstood why I read the text that way.

The current draft is even worse than your proposal, though:

- Regardless of the value of the criticality field, if the server
recognizes the control type and it is appropriate for the
operation, the server is to make use of the control when
performing the operation.

Now it _really_ isn't possible to treat wrong criticality as an error.
With this wording it doesn't make sense here to claim that "when
performing the operation" only applies if the operation is performed at
all, and that one can still return an error instead.

Kurt D. Zeilenga writes:
> John, Hallvard,
>
> Are you aware of any server implementation which behaves consistently
> with the interpretation that you and Hallvard favor?

I really don't know many clients at all.

> I think the suggested new text is pretty clear that if a control
> specification really needs to alter the semantics of the server's
> general criticality processing, the control specification needs
> to state an imperative separately from the guidance it gives to
> client.

If you mean stating that the criticality is mandated, then as I've said,
I don't think your text says that at all. I'd prefer

- direction as to what value the sender should provide for the
criticality field

in the current draft to be changed to 'direction or requirements as
to...'.

--
Hallvard