Subject: RE: Protocol: control specifications.

From: John McMeeking <[email-masked]>
Date: Mon, 1 Mar 2004 08:23:46 -0600

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: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Mar 2004 19:44:15 +0100

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:

> I think Hallvard is arguing that 1B -- a control incorrectly marked
> 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.

> (...)
> 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: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 Mar 2004 12:02:53 -0800

Hallvard, John,

In discussing this issue at IETF#59, one of the questions
that came up was whether there were any non-diagnostic
use case for criticality behavior (where control specifications
mandate client send a particular value that servers are to
verify the value and return error if not).  Do you have
any?

It seems that this is not really a protocol interoperability
issue (though requiring verification might actually lead to
some protocol interoperability problems), but a client
development/diagnostic issue.

(Hallvard, you are likely correct that I have not responded to
each of your points.  This is mostly likely due to my attempt
to narrow discussion to key aspects of this issue.  We, of
course, likely differ on what are key aspects of this
discussion.)

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Mar 2004 22:11:46 +0100

Kurt D. Zeilenga writes:

> In discussing this issue at IETF#59, one of the questions that came up
> was whether there were any non-diagnostic use case for criticality
> behavior (where control specifications mandate client send a
> particular value that servers are to verify the value and return error
> if not).  Do you have any?

I'm not sure what is the question and what is not, but I hope you find
the answer here:

- While I think control specs should be able to mandate the
  criticality protocol field, they should not mandate that servers check
  it.  That is a [Protocol] issue.  It would just add to the mess if one
  could trust a server to catch wrong criticality for some controls, but
  not for others.

- I'm aware of no RFC which requires a request control to be
  critical or non-critical.  So of course I'm aware of no RFC which
  requires anything to check the criticality of any control.

- rfc2649 (Signed Results) and rfc2891 (Server Side Sorting) require
  the response control to have criticality FALSE, but does not say that
  the client must check it.  Seems like an uninteresting case to me, in
  particular now that response criticality will be ignored.

- I thought (and still suspect) rfc2251 said wrong criticality was an
  error, and thus a quality server should catch it, but I did not think
  this was a mandate.

- draft-zeilenga-ldap-noop-*.txt requires criticality to be TRUE, but I
  note you have reworded the -04 version to explicitly make it a
  client-side mandate.  Too bad:-)

- rfc 2649 and rfc 2891 alters the semantics to the criticality
  field.  See the last part of this message:

  URL: http://www.OpenLDAP.org/lists/ietf-ldapbis/200401/msg00083.html
  Message-Id: <[email-masked]>
  Date: Mon, 12 Jan 2004 01:34:43 +0100
  Subject: Re: Protocol: control specifications.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 Mar 2004 14:19:42 -0800

Well, I think the question was more about what use scenarios server-side
enforcement of a particular criticality value would be useful.  In the
past, the use scenario discussed was so that client developers would,
if they tested against a server which implemented such checks, receive
a diagnostic (a protocolError) that would tell them that they didn't
provide the particular criticality value called for.  The question was
whether this wether or not there were other (non-diagnostic) use cases.

>  could trust a server to catch wrong criticality for some controls, but

Problem here is that any mandated value is control-specific.  The [protocol]
discusses criticality handling which is not control-specific.  While a control
specification can certainly say "servers implementing this control are to
verify its critical field is TRUE", just as that control specification could
mandate that a search scope be baseObject, or a target DN be empty, etc.),
this is a control specific semantic and not part of the control-neutral
criticality processing discussed in [Protocol].  Whether or not such
statements are or aren't appropriate can be left to discussions regarding
particular control specifications which attempt to make them (as any
such verification is part of the control-specific processing).

Instead of saying the control specifications may require such a verification
(or verification of any number of other things), it would like be better
to clarify that the scope of any LDAP extension is only limited by what
can be supported in a truly optional manner. 

>  error,

I do not believe your view is supported by the consensus of the WG
nor by existing implementations (many of which implement controls
whose specifications mandate clients provide particular criticality
values).

At present, I am inclined to either treat your request as a new feature
(and hence out-of-scope) or as a clarification to an un-implemented
interpretation (which we should avoid), or simply as a change which
is not supported by WG consensus.  However, to ensure the WG fully
considers all issues, it seemed appropriate to see if there were
other use scenarios.

Kurt

---

From: John McMeeking <[email-masked]>
Date: Tue, 9 Mar 2004 07:44:51 -0600

I have already noted the X.511 statement that a DUA shall set the
corresponding bit of the critical extensions field when using extensions
that X.511 defines as critical.  Beyond that, no I am aware of no
"non-diagnostic" use.

Clearly, if a server recognizes the control and it is appropriate to use,
the RFC 2251 and ldapbis language both require the server to honor the
control independent of criticality.

I consider the existing language an improvement over RFC 2251.  The RFC
2251 language of "always critical" and "never critical" implies behavior
that does not exist; "critical at senders request" is the only thing that
is consistent with the servers' required behavior.  Its possible the
language was intended to mean more but lost something during editing, but
that is pure conjecture on my part.

I guess I'll accept any language that clearly states what the server is
supposed to do with control criticality, and uses consistent language for
guidance/requirements of control definitions.

John  McMeeking

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Mar 2004 21:30:29 +0100

Kurt D. Zeilenga writes:
> Well, I think the question was more about what use scenarios
> server-side enforcement of a particular criticality value would be
> useful.  In the past, the use scenario discussed was so that client
> developers would, if they tested against a server which implemented
> such checks, receive a diagnostic (a protocolError) that would tell
> them that they didn't provide the particular criticality value called
> for.  The question was whether this wether or not there were other
> (non-diagnostic) use cases.

I cannot think of any.

> Problem here is that any mandated value is control-specific.  The
> [protocol] discusses criticality handling which is not
> control-specific.

So if a server wishes to verify the criticality of controls in general,
it must do it in the implementation of each control.  I don't see a
problem with that, as long as the server does it consistently.  Which is
a quality of implementation issue, not a [protocol] or control spec
issue.

> While a control specification can certainly say
> "servers implementing this control are to verify its critical field is
> TRUE", (...), this is a control
> specific semantic and not part of the control-neutral criticality
> processing discussed in [Protocol].

Yes.  Which is why I don't want control specs to say that.
Because...

> Whether or not such statements
> are or aren't appropriate can be left to discussions regarding

No.  If the control spec says that, it is altering the semantics of the
criticality field.  Which [Protocol] says should not be done.

> Instead of saying the control specifications may require such a
> verification (or verification of any number of other things), it would
> like be better to clarify that the scope of any LDAP extension is only
> limited by what can be supported in a truly optional manner.

It's not clear to me what this suggestion means in practice.
I _think_ it at least means to remove the text
     (note: the semantics of the criticality field 
     are defined above should not be altered by the control's 
     specification)

> I do not believe your view is supported by the consensus of the WG

It's been a while since the discussion, but at the moment I don't
remember anyone but you and me saying what we think rfc2251 was meant to
say.  Though I assume Jim agrees with you, since he adopted your changes
so easily.

> whose specifications mandate clients provide particular criticality

Well, the question would be what most servers do; enough that a change
will not be a problem, not what many servers do.  I don't think we
disagree about what clients may or should do.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 14:43:07 -0800

>> (non-diagnostic) use cases.

noted.

>it must do it in the implementation of each control.

Well, I rather not get into implementation detail.  It is possible
that a server could implement their general control processing
in a manner which allowed them to verify criticality values
mandated by the control specification.  My point is that there
is a logic separation of control-neutral and control-specific
processing and any criticality verification is logically part of
the control-specific processing (as its specification is
control specific).

>I don't see a
>problem with that, as long as the server does it consistently.

Consistent with the control's specification!  The behavior
is control-specific...  one specification could say "incorrect
criticality is to be treated as a protocolError" while another
specification could say "incorrect criticality should be viewed
as constraintViolation" while another could say "if a incorrect
criticality is detected, it should be logged but otherwise
ignored".

I would hope most specifications would opt for the last (with
ability to disable logging) as a) it provides a useful diagnostic
and b) encourages servers to be liberal in what they accept.

I, for one, would likely ignore mandates to return errors where
I could instead process the operation unambigiously.

>Which is

While [Protocol] says future specifications should not overload
criticality field, [Protocol] does not restrict the scope of
extension which a control might express.

>It's not clear to me what this suggestion means in practice.

Well, I would agree that some extension authors don't understand
that extensions should be truly optional.

>     are defined above should not be altered by the control's 

This text is intended to highlight an important change in practice,
a change that resulted from significant discussion (namely in LDAPEXT)
of technical issues with existing extension specifications (some
"in progress", some published).  As the consensus was, and appears to
still be, that the overloading criticality is generally not appropriate,
it is appropriative for us to say so in this revision.  Otherwise
it is likely the practice would continue (especially given that not
all control specifications are subject to IETF review).

I note as well that this practice, aside from causing issues with
each overloading specification, also caused and continues to cause
confusion as to precise what are the criticality semantics.  Hence,
aside from clarifying what future specifications should avoid doing,
the note also reenforces that criticality semantics are just those
which were specified in RFC 2251.

>say.  Though I assume Jim agrees with you, since he adopted your changes

Consensus, especially when limited to just list posts, can be a
hard thing to judge.  I've tried to take all inputs (from list,
from personal conversations, from face-to-face meetings, etc..)
and weight them to come up with a belief of what the consensus
(or lack thereof) is.  I then generally try to state this belief
(as I have done here) as well as what actions I am considering
taking based upon this belief.  This is intended to allow
additional input (regarding either my view of consensus or the
proposed actions).

>Well, the question would be what most servers do;

Actually, the question is whether there are multiple independently
developed implementations.  2 servers would be enough... but I
not aware of any.