[Date Prev][Date Next]
RE: Protocol: control specifications.
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.
>At 01:11 PM 3/8/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>- 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.
> Problem here is that any mandated value is control-specific. The
> [protocol] discusses criticality handling which is not
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
> 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.
> 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).
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
>>- I thought (and still suspect) rfc2251 said wrong criticality was an
> 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
> nor by existing implementations (many of which implement controls
> 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.
> 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.