RE: Protocol: control specifications.

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

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
> 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
> 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 
     specification)

>>- I thought (and still suspect) rfc2251 said wrong criticality was an
>>  error,
> 
> 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.

> nor by existing implementations (many of which implement controls
> whose specifications mandate clients provide particular criticality
> values).

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.

-- 
Hallvard