Re: protocol-27 comments

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 10/28/04 5:46:16 PM >>>
>>Quick review; I've mostly looked at changes since last draft:
>>
>>> 4.6. Modify Operation
>>
>>> The result of the modification is indeterminate if the
>>> Modify Response is not received (e.g. the LDA exchange is terminated
>>> or the Modify Operation is abandoned).
>>
>>I prefer the old text "whether the modification completed successfully
>>or not is indeterminate" over "the result of the modification is
>>indeterminate". The new text seems to allow completely random effects
>>on the server side, even more so that Kurt's (withdrawn) suggestion
>>"whether the modification completed successfully" in the 'Misuse of the
>>term "association" in [Protocol]' thread.
> 
> That sounds like the same complaint Kurt had about the "whether the
> modification completed successfully or not is indeterminate". He said
> (something to the effect of) that makes it sound like it may have
> partially completed.

No, that was what I said about Kurt's suggested replacement text.

> How about: "Whether the modification was applied or not is indeterminate..."?
> 
>>Also, I think s/received/sent/. This sentence is about what the server
>>does, not about what the client knows.
> 
> Well, who is making the determination? The client. And the client receives
> the response.

Or rather it doesn't in this case.  But that's implicit from the fact
that it receives no response.

My point is, we need something which says that the _server_ may either
perform the modification or not.

>>> 4.7. Add Operation
>>
>>> - attributes: the list of attributes that, along with those from the
>>> RDN, make up the content of the entry being added. Clients MAY or
>>> MAY NOT include the RDN attribute in this list. Clients MUST
>>> include the 'objectClass' attribute, and values of any mandatory
>>> attributes of the listed object classes.
>>
>>If the RDN is an objectClass, does that object class need to be
>>supplied? (Not that I care if it is addressed or not, it's just a weird
>>example which occurred to me:-)
> 
> Hmm, well as long as we're being pedantic, do all entries which can be
> added by a cleint require the objectClass attribute? I've seen hints that
> some implementations allow DSE's of certain DSE types to exist without an
> objectClass attribute (I think this was a justification for the T/F filter
> specification). It would probably be better to say that the entry being
> added must conform to the data model.

Sounds good.

>>> 4.14.1. StartTLS Request
>>
>>> Sequencing problems (particularly those detailed in Section 3.1.1 of
>>> [AuthMeth] result in an operationsError being returned in the
>>> resultCode.
>>
>>Prepend "Detected" as in authmeth section 3.1.1.
> 
> just for readability?

No, because it the server doesn't detect the sequencing problem it can't
know that it must return operationsError.

>>> 4.14.2. StartTLS Response
>>
>>> For example, if the TLS
>>> subsystem is not presently available, the server may return indicate
>>> so by returning the unavailable resultCode.
>>
>>Garbled sentence.
> 
> yup, remove 'return'

I suggest s/unavailable resultCode/resultCode unavailable/ too.
All the result codes are available:-)

-- 
Hallvard