[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Steven's protocol comments
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.
>> 4.2.2. Bind Response
>
>> The serverSaslCreds are used as part of a SASL-defined bind mechanism
>> to allow the client to authenticate the server to which it is
>> communicating, or to perform "challenge-response" authentication. If
>> the client bound with the simple choice, or the SASL mechanism does
>> not require the server to return information to the client, then this
>> field is not to be included in the BindResponse.
> ^^^^^^^^^ SHALL NOT ?
Yes.
>> - sizeLimit: A size limit that restricts the maximum number of
>> entries to be returned as a result of the search. A value of 0 in
>> this field indicates that no client-requested size limit
>> restrictions are in effect for the search. Servers may enforce a
>> maximum number of entries to return.
>>
>> - timeLimit: A time limit that restricts the maximum time (in
>> seconds) allowed for a search. A value of 0 in this field
>> indicates that no client-requested time limit restrictions are in
>> effect for the search.
>
>Servers may limit the number of entries returned. Should they not also
>be allowed to limit the amount of time spent ?
Yes. But it could be argued that these are really administrative
limits which, when exceeded, should be indicated by the
adminLimitExceeded error. However, for historical reasons,
I have no problem continuing to allow use of these codes to
indicate such.
>> Client implementors should note that even if all user attributes
>> are requested, some attributes of the entry may not be included in
>> search results due to access controls or other restrictions.
>> Furthermore, servers will not return operational attributes, such
>> as objectClasses or attributeTypes, unless they are listed by
>> name, since there may be extremely large number of values for
>> certain operational attributes. (A list of operational attributes
>> for use in LDAP is given in [Syntaxes].)
> ^^^^^^^^^^
>The operational attributes are now listed in other documents.
[Models]. Suggest the note be reworded:
([Models] details commonly supported operational attribute types.)
>> 4.5.2. Search Result
>
>> PartialAttributeList ::= SEQUENCE OF SEQUENCE {
>> type AttributeDescription,
>> vals SET OF AttributeValue }
>
>I thought there was an agreement to consolidate all the SEQUENCEs
>of type and vals into one Attribute ASN.1 type, and for there to be only
>one "SEQUENCE OF Attribute" ASN.1 type. What happened to that ?
In my comment, I suggested an approach which doesn't consolidate
attributes and partial attribute types. However, I don't have
any particular problem with taking a consolidation approach.
>> 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".
>> 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.
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.
I suggest deleting "all" and s/recognize/support/.
(It would be inappropriate to publish a value which you
recognized but didn't support).
>> 4.13.2.2. Response other than "success"
>
>> If the server does not support TLS (whether by design or by current
>> configuration), it MUST set the resultCode field to protocolError.
>> The client's current association is unaffected if the server does not
>> support TLS. The client MAY proceed with any LDAP operation, or it
> ^^^ ^^
>> MAY close the connection.
> ^^^
>"MAY" and "or" both suggest optionality. I am left wondering what a client
>is supposed to do if it elects to do neither of the MAY actions.
>Perhaps the "MAY"s should be downcased.
Downcase them.
>> The server MUST return unavailable if it supports TLS but cannot
>> establish a TLS connection for some reason, e.g. the certificate
>> server not responding, it cannot contact its TLS implementation, or
>> if the server is in process of shutting down. The client MAY retry
> ^^^
>> the StartTLS operation, or it MAY proceed with any other LDAP
> ^^^^^^^^^
>> operation, or it MAY close the LDAP connection.
> ^^^^^^^^^
>Same again.
same: down case.
>> The other party, if it receives a TLS closure alert, MUST immediately
>> transmit a TLS closure alert. It will subsequently cease to send TLS
> ^^^^ MUST ?
Please consider the replace text I offer in my comments.