Re: Steven's protocol comments

[Steven Legg <steven.legg@adacel.com.au>]

Kurt,

Kurt D. Zeilenga wrote:
> At 10:50 PM 10/5/2003, Steven Legg wrote:
>
> > Here are some comments on draft-ietf-ldapbis-protocol-17.txt .
> > They are mostly of an editorial nature.
>
>
> I'm mostly fine with Steven's suggestions...  but have a few
> comments here and there to add. - Kurt
>
>
> > >    If the client wishes to progress the operation, it MUST follow the 
> > >    referral by contacting one of the servers.
> >
> >
> > "If" and "MUST" make this an effective "MAY", e.g.
> >
> >     "The Client MAY progress the operation by following the referral and
> >     contacting one of the servers."
>
>
> I think this MAY could be downcased.

No objection.


> > >    If the server's schema defines a textual name for an attribute 
> > > type,    it SHOULD use a textual name for attributes of that 
> > > attribute type by    specifying one of the textual names as the value 
> > > of the attribute    type. Otherwise, the server uses the object 
> > > identifier for the    attribute type by specifying the object 
> > > identifier, in ldapOID form,    as the value of attribute type. If 
> > > the server determines that    returning a textual name will cause 
> > > interoperability problems, it    SHOULD return the ldapOID form of 
> > > the attribute type. 
> >
> >
> > This paragraph is a bit shaky. Consider this instead:
> >
> >  "If the server's schema defines short names [Models] for an attribute 
> > type
> >   then the server SHOULD use one of those names in attribute descriptions
> >   for that attribute type (in preference to using the dotted decimal 
> > format
> >   of the attribute type's object identifier). The server should not 
> > use the
> >   short name if that name is known by the server to be ambiguous, or
> >   otherwise likely to cause interoperability problems."
>
>
> I think the "should not" should be a "SHOULD NOT".

I thought of that but decided against it because the second sentence
is discussing a circumstance in which the preceding SHOULD would be
disregarded by an implementor. It seems inappropriate to me to have two
opposing implementation imperatives addressing the same point.

> > > 4.12. Extended Operation 
> >
> >
> > >    Servers list the requestName of all ExtendedRequests they recognize 
> >
> >            ^ SHALL ?
>
>
> No.  First, "all" is too strong.  Servers should be allowed
> to restrict the set of values by access or other
> administrative controls and/or by current available and/or
> other factors.

Agreed.

> And since no great harm is caused by not providing a value
> (especially given they are rarely used by clients), a
> SHALL is way too strong.

A "MAY" then ?

> I suggest deleting "all" and s/recognize/support/.
>
> (It would be inappropriate to publish a value which you
> recognized but didn't support).


Regards,
Steven