Subject: RE: Protocol: control specifications.

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 01 Mar 2004 17:40:48 -0700

I'd rather leave the language as it is. It's much more simple to think
of criticality in the way it is currently described. 
 
Regarding what I think you're saying below: 
 
- If the client wants the operation to fail when not supported, it
should set the criticality to true.
- If there are cases where clients have a need to set the criticality
to false, and also be notified whether the control was applied, then the
control specification ought to provide some return control for purposes
of acknowledgment.
 
Jim

>>> John McMeeking <[email-masked]> 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" 
< [email-masked] 
m> To 
Sent by: "Hallvard B Furuseth" 
owner-ietf-ldapbi < [email-masked] > 
[email-masked] cc 
< [email-masked] > 
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: [email-masked] 
[mailto:[email-masked]]On Behalf Of Hallvard B
Furuseth
Sent: Friday, 27 February 2004 19:46
To: Kurt D. Zeilenga
Cc: [email-masked] 
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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 01 Mar 2004 17:48:31 -0700

Hallvard,
 
>>> Hallvard B Furuseth <[email-masked]> 2/27/04 1:45:49 AM
>>>

I think that's the point (we are trying to remove ambiguity). This
language is simple to understand and implement. Any recommendations
given in control specifications are to the client implementer.
 
at
>all, and that one can still return an error instead.

I agree. Hopefully no one will twist the language in that way.
 
Jim

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Mar 2004 19:51:13 +0100

Jim Sermersheim writes:
> to false, and also be notified whether the control was applied, then
> the control specification ought to provide some return control for
> purposes of acknowledgment.

...if the control was applied.  True, but that's another issue.
I think it's covered by this text in the draft:

     (note: the semantics of the criticality field 
     are defined above should not be altered by the control's 
     specification)

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Mar 2004 14:22:26 -0700

Hallvard,
 
I'm guessing that you mis-read my statement because I can't see how the
semantics statement affect the problem I mention.
 
Jim

>>> Hallvard B Furuseth <[email-masked]> 3/8/04 11:51:13 AM
>>>

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Mar 2004 15:00:11 -0700

So you summary tells me that:
 
a) The issue regarding whether the server should check the validity of
the criticality is a dead horse.
b) More discussion regarding the current wording needs to take place.
 
I suggest (unless there are other reasons I'm not seeing) that we drop
the (a) discussion.
 
Jim

>>> Hallvard B Furuseth <[email-masked]> 3/8/04 11:44:15 AM
>>>
Ramsay, Ron writes:
> I can't help feeling that you have answered your own question.

I'm not sure which question you are referring to. You are just
describing some of the semantics of the current draft. I'm asking for
responses to my arguments against the change from rfc2251 to that
semantics. The original change I suggested in the other direction has
been discussed to death, but the change which was actually made has
not.

> The server response is (...)

Yes, that's what the current text says. It's not what rfc2251 said.

John McMeeking writes:

> with criticality = FALSE -- should result in a failure.

Well, that's what I want (with s/should/SHOULD/), but I've given up
that
as a lost cause. What I'm asking for now is response to my arguments
against even removing the MAY and the change to demote _required_
criticality to mere advice, and for clarification to some of the text
about the latter.

> (...)
the
> extension but does not have the criticality bit set.

Yes, I'd like to know what X.500 servers actually do in that case.

BTW, I'm sorry about the sour note I restarted this thread with. I
guess it's because I wrote it at "33:45 o'clock" and was rather tired
after a long night.

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Mar 2004 15:13:56 -0700

Regarding the current text:
 
direction as to what value the sender should provide for the
criticality field (note: the semantics of the criticality field are
defined above should not be altered by the control's specification)
 
versus the old text:

whether the control is always noncritical, always critical, or critical
at the client's option

These can either be read to have the same or very similar meanings, or
they can be read to have at least two different meanings:

1) the old text can be read to imply that the control spec can mandate
the criticality, and the server should validate the criticality
2) the old text can be read to imply that the control spec can mandate
the criticality, but it's the clien't responsibility to validate it.

(1) has been argued abck and forth, and it seems consensus is to not do
that.
(2) in my mind is still allowed by the new text.

Let me know if there is something I'm not considering.

Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Mar 2004 14:54:32 -0700

I see where you're going now.
 
No, my problem and solution don't attempt to change the semantics of
the criticality. 
 
I saw a statement made by John McMeeking which said "... I'd sure hate
to find out that the extension had been ignored."
 
From that, I assumed that there are use cases where the client wishes
to send a control marked non-critical, yet also wishes to know if the
control was applied.
 
So,  I was suggesting that good control specifications can be written
such that there is either: a) always a response control, or b) a field
in the request control that causes a response control to be returned.
This allows the client to know whether the control was applied (the
absence of a response control indicates that the control was ignored).
This does not alter the semantics of the criticality field.
 
You're right, this is not germane to the current discussion. I just
wanted to note it because I didn't want that aspect of John's statement
to be seen as another requirement for causing the server to enforce
correct criticality.
 
Jim

>>> Hallvard B Furuseth <[email-masked]> 3/8/04 2:37:09 PM
>>>
> semantics statement affect the problem I mention.

The criticality field is just supposed to say whether or not to
perform
the operation. If the criticality field causes the addition of a
return
control, then that violates the semantics statement.

If you meant that a return control should be added independently of
the
criticality field, you are right, that has nothing to do with
additional
semantics to the criticality field. But I don't see what that has to
do
with the discussion. Unless you you referred to my message
http://www.OpenLDAP.org/lists/ietf-ldapbis/200401/msg00083.html 
which reported that rfc2649 and rfc2891 do say that criticality TRUE
causes the addition of a return control. If so, yes I quite agree they
should not have done that.

>>>> Hallvard B Furuseth < [email-masked] > 3/8/04 11:51:13
AM

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Mar 2004 15:48:18 -0700

I agree, and suggest that once we have a stable control guidelines
document, that we revise the existing control specifications to bring
them inline (though I'm not implicitly volunteering to do the work).
 
JIm

>>> "Kurt D. Zeilenga" <[email-masked]> 3/8/04 3:29:50 PM >>>
I note that we had a number of discussions in LDAPEXT regarding
flaws in RFC 2649 and RFC 2891 (and a number of other control
specifications) criticality handling, mostly dealing with
overloading of criticality semantics but also dealing with
criticality of response controls.

In general, I believe the consensus (at that time) was:
a) control specifications should not make server
processing of an operation extended by a control
dependent on the criticality of that control, and
b) criticality of a response control is not generally
relevant to client processing of an operation extended
by a control.

I think consensus today is much the same. [Protocol] appears
to reflect this.

Kurt

perform
return
the
additional
do
AM

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Mar 2004 02:44:57 +0100

Jim Sermersheim writes:
> >>> Hallvard B Furuseth <[email-masked]> 3/9/04 1:03:48 PM
> >Jim Sermersheim writes:
> >> 
> >Not quite. I thought - and still think - this meant a wrong criticality
> >is an error, so server MAY validate it, and thus a good quality server
> >would do so. I asked for a SHOULD, but have lost that argument.
> 
> (...)
> 
> >(1) as in "MAY" - the arguments against the "SHOULD" seem to have become
> >the reason for even removing the "MAY". I've argued against that, but
> >the change happened without response to my arguments, except some
> >misunderstandings about why I thought it said that.
> 
> I would just add that a MAY will cause differing implementations, and
> it would seem better in this scenario to have consistent implementations
> and lose the benefit of having the server validate.

I don't see that.  The only difference is that some servers will catch
more client errors than other servers.  Which is true anyway.

> Also, adding the MAY
> will cause rewrites of other text (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.)

Well, rewriting the draft is what we are discussing in this forum.
s/when performing/if it performs/, I guess.

>> It can be read that way, but "direction" can also be seen as saying the
>> spec may recommend a criticality, but that it does not say anything
>> about allowing the spec to mandate a criticality. So I've asked
>> for a clarification.
> 
> Does it help to explicitly state that a spec can mandate criticality?

Yes.

> If so, we can add it, but I worry about getting too far into the realm
> of writing a 'specification for control specifications' (as if we're not
> already too far into that realm already). Frankly, I feel that the
> community's experience in writing control specifications is still very
> limited, so I hesitate to add anything here that's not very general in
> nature.

The current text is:

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

Would s/direction/direction or requirements/ be OK?

-- 
Hallvard

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 10 Mar 2004 13:58:38 +1100

1. Are they the *new* rules? I've been following the *new* paradigm for some time.
2. It is NOT like rejecting the bind. We are able to process the request; it is the other servers that may not be able to process it. It is like rejecting a bind because *another* server might not handle it correctly!

In short, you are asking one server to behave in a particul;ar way JUST BECAUSE another server may behave differently. The problem is not with THIS server. Therefore, THIS server should not worry about the criticality. It also should not worry about any OTHER server and whether it would do the right thing.

Ron

-----Original Message-----
From: Hallvard B Furuseth [mailto:[email-masked]]
Sent: Wednesday, 10 March 2004 13:03
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: Protocol: control specifications.

Ramsay, Ron writes:

> I can see no point in discussions of how a server should handle
> incorrect criticality.

Whether there is any point in discussing it anymore I don't know.

I do wish someone knew what some X.500 servers do about wrong
criticality.

> Presumably, if the server knows the criticality
> is wrong then it knows enough to inplement it.

Of course.

> Then, according to the rules, the criticality from the server's
> perspective is TRUE - controls that are implemented have to be
> performed.

The new rules, yes.

> So, you would be asking a server to tell the client either

s/asking/allowing/.

> 2) I didn't do it. I could have but, na-na-na, you got the criticality
> wrong. Let that teach you a lesson!

Yes.  You have a strange way of saying it, but since you do:

> I don't see either as acceptable server behaviour.

And I don't see why servers should be forbidden to catch this particular
client error.  There are plenty of client errors that servers may, but
need not, catch.  I think it's an important client error to catch, since
it can be so damaging.  As important as rejecting cleartext password
binds done without TLS.  After all, rejecting the bind doesn't protect
the password, that has already been sent in the clear.  But it
encourages the client to be fixed.

> I thought this had been settled. I thought I would see no more text on
> this.

I was arguing and arguing against the new rules when they were
suggested, but got little reply except a few misunderstandings.
OK, now I do get replies.

-- 
Hallvard