[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: protocol-22 comments
Kurt D. Zeilenga writes:
>At 06:20 AM 3/9/2004, you wrote:
>>> Additionally, unless order-dependent semantics are given in a
>>> specification, the order of a combination of controls in the SEQUENCE
>>> is ignored.
>>
>> This implies that controls (A, B) MUST behave identically with controls
>> (B, A).
>
> unless order-dependent semantics are provided.
Oops, sorry. I meant to address the part after the comma in the
original sentence. The same below:
>> I think it should be, "the effect of the ordering of a
>> combination of controls in the SEQUENCE is unspecified"?
> The problem we current face is that effect of ordering is
> generally unspecified.
Hm? I thought you just agreed that it _is_ specified.
> I think the sentence likely could be better worded:
> Additionally, the order of controls in a combination
> only matters if the specification describing that
> combination details order-specific semantics.
As far as I can tell, that says the same as the original text.
But I think the original was clearer.
>>> 4.7. Add Operation
>>> If the entry to be added would not fall within a naming context
>>> [Section 5 of Models] held by the server, and the server has
>>> knowledge of where that entry is to be located, a referral to the
>>> server(s) holding the parent entry should be returned.
>>
>> Unless the server chains the operation to another server (i.e. it sends
>> the request to the server which masters that naming context, and returns
>> the response from that server to the client).
>
> We should avoid discussing chaining (and many other aspects of
> distributed directories). I suggest the quoted paragraph be worded
> in more general terms, like:
> Where a server has knowledge that the operation should be
> referred to another server (or server(s), a referral may be
> returned to the client.
>
> Of course, this applies in general so maybe it should be said once.
Yes, move it to 4.1.10 (Referral), which currently doesn't say when
referrals may be returned, just what they mean. No other protocol
operations in section 4 mention referrals (except the subsection about
continuation references under Search).
I just noticed an error in 4.1.10 (Referral):
> The referral result code indicates that the contacted server does not
> hold the target entry of the request.
So does noSuchObject. I suggest:
A referral indicates that the contacted server cannot perform the
operation, but one or more other servers can.
I tried at first to formulate it in terms of naming contexts, but that
got too clumsy. Some operations cannot be performed if the server
doesn't hold the naming context for the entry which the operation
applies to, while others cannot be performed if it doesn't _master_ that
naming context.
>>> 4.12. Extended Operation
>>
>>> Extended operations may be specified in other documents. The
>>> specification of an extended operation consists of:
> - the OBJECT IDENTIFIER assigned to the requestName,
> - the OBJECT IDENTIFIER, if any, assigned to the responseName
> (note the same OBJECT IDENTIFIER may be used for both)
Fine.
>>Editorial comments:
>>> 4.2. Bind Operation
>> Here is a suggestion, though it's a bit long. Maybe the last sentence
>> should be dropped.
>>
>> Authorization is the decision of which access an operation has to
>> the directory. It may be affected by many factors, often including
>> the association's authorization identity, which again was derived
>> from or authorized via the authentication information.
>> Authorization may be affected by factors outside of the LDAP Bind
>> Request, such as those provided by lower layer security services.
Note that 'authorization identity' is not defined or used elsewhere in
[Protocol]. The paragraph is fairly self-contained anyway, so I hope
that's all right. Could add an [Authmeth] reference.
>>> 4.10. Compare Operation
>>
>>> The resultCode field is set to compareTrue, compareFalse, or an
>>> appropriate error. compareTrue indicates that the assertion value in
>>> the ava field is equivalent to a value of the attribute or subtype
>>> (according to the attribute's EQUALITY matching rule).
>>
>> Maybe remove the "()"'s?
>
> s/equivalent/equal/ here and elsewhere where we are specifically
> talking about matching using the equality matching rule.
I prefer s/is equivalent to/matches/, and s/non-equivalent/FALSE/
further down, as I suggested in the thread about no EQUALITY matching
rule. I don't know of any other "equivalent" things that need fixing.
>>> 4.14.3.2. Abrupt Closure
>>>
>>> Either the client or server MAY abruptly close the TLS connection by
>>> dropping the underlying transfer protocol connection. In this
>>
>> s/transfer protocol connection/LDAP connection/; that's the phrase
>> which is used elsewhere (e.g. in 4.14.3.1).
>
> No. The underlying transfer protocol connection is not an LDAP
> connection
Yes, it is. That's what "LDAP connection" is defined as in Section 2.
--> New thread '"connections" (Was: protocol-22 comments)'.
I suppose it might be an idea to spell out "transfer protocol
connection" in this case; if so the phrase "LDAP connection" in nearby
sections should be replaced with the same.
>>> 5.2. Transfer Protocols
>> I suggest at least a paragraph break here. In fact, I think the rest of
>> the paragraph belongs in a separate section '5.2.2 Connection Closure
>> Effects'.
Um... on second thought, it fits better as section 4.2 or 4.15. This
text is about which directory operations to perform in a particular
situation. The rest of section 5 is about transfer protocols and has
nothing to do with directory operations.
>>> Protocol operations are tied to a connection, thus if the
>>> connection is closed or dropped, the operation is aborted. When this
>>> happens, any outstanding operations on the server are, when possible,
>>> abandoned, and when not possible, completed without transmission of
>>> the response.
--
Hallvard