[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [protocol] and LDAP control criticality






I asked my original question because someone asked me, and I couldn't find
an answer.  I think I have my answer -- these terms (always critical, etc.)
are recommendations to the user of the control, but do not have any meaning
with respect to processing of the control by the server.

The last paragraph of 4.1 looks like it is largely guidelines to control
developers.  It seems improper to put these terms out there without any
definition or reference to other documents defining them.  I couldn't find
anything elsewhere - standards or otherwise - that said more about this
than the original sentence from RFC 2251.

X.511 has a brief discussion of "recommended criticality", but most of the
"shalls" I see in reference to critical extensions appear to be guidance.
For example, the newSuperior extension for modifyDN has a recommended
criticality of critical, but if a DUA choses not to mark it as critical, I
believe the modifyDN request will succeed with a 1988-edition DSA, but
clearly not with the desired results.

The guidance that criticality should be discussed in the specification of a
control is useful, but I don't see any reason to list these three "values"
for control criticality.

Maybe we could replace:

   The specification of a control consists of:
   [text omitted]
   - whether the control is always non critical, always critical, or
        optionally critical,

with

   The specification of a control consists of:
   [text omitted]
   - recommended criticality for the control,


John  McMeeking



                                                                                                                    
                      "Kurt D.                                                                                      
                      Zeilenga"                To:       John McMeeking/Rochester/IBM@IBMUS                         
                      <Kurt@OpenLDAP.or        cc:       ietf-ldapbis@OpenLDAP.org                                  
                      g>                       Subject:  Re: [protocol] and LDAP control criticality                
                                                                                                                    
                      12/11/2003 01:09                                                                              
                      PM                                                                                            
                                                                                                                    
                                                                                                                    




At 08:29 AM 12/11/2003, John McMeeking wrote:
>What do "always critical" and "always non critical" imply about processing
>of controls?

I view this as a requirement placed upon the generator of the
control and does not imply any requirement upon the receiver
of the control to enforce the criticality flag.

It requires about criticality semantics only apply to a server
which is not processing the control due to control type being
unrecognized or inappropriate for the operation.  Or to put
it another way, the criticality flag is moot to a server is
making use of the control in processing the operation.  It
would be inappropriate for a control specification to state
requirements that a server should depend its use (and/or
control semantics) of the criticality flag.

>If a control is defined as always critical or always non
>critical, does that mean the server should ignore the client specified
>criticality?  Should a server reject a control (with which error) that
that
>has the wrong criticiality?  Is this just guidance to the application?

I would argue that the control specification should be
clarified that "always (non)critical" imparts only a
requirement upon the control generator.  It may be
appropriate to state this in a separate guidelines for
extension developers document(s).

Kurt