RE: Protocol: control specifications.

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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: <HBF.20040112qxiq@bombur.uio.no>
  Date: Mon, 12 Jan 2004 01:34:43 +0100
  Subject: Re: Protocol: control specifications.

-- 
Hallvard