[Date Prev][Date Next]
RE: Protocol: control specifications.
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:
Date: Mon, 12 Jan 2004 01:34:43 +0100
Subject: Re: Protocol: control specifications.