[Date Prev][Date Next]
Re: Steven's protocol comments
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.
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
then the server SHOULD use one of those names in attribute descriptions
for that attribute type (in preference to using the dotted decimal
of the attribute type's object identifier). The server should not
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
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).