Subject: Re: protocol-27 comments

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 29 Oct 2004 00:31:56 -0600

>>> Hallvard B Furuseth <[email-masked]> 10/28/04 5:46:16 PM >>>
>Quick review; I've mostly looked at changes since last draft:
>
>> 4.4.1. Notice of Disconnection
<snip>
>and thus loses "[will] be unavailable for an extended period of time".
>I'm happy with that change, but I don't remember any discussion about it
>- except to keep result code descriptions in the appendix in general.

It was not on the You're right, it was not on the list. I elected to not copy this to the appendix while performing the task of removing the redundant error code specifications from 4.4.1 (something that did make it to the list). I just made a call on this — it seemed pretty clear that this was not a substantial change, and that I was just removing fluffy, vague, uneeded text.

>> 4.5.1. Search Request
>
>> Filter ::= CHOICE {
>> and [0] SET OF filter Filter,
>> or [1] SET OF filter Filter,
>
>Another change I do not remember from the list: The SIZE (1..MAX) was
>removed from the ASN.1 grammar (though the textual description still
>requires at least one component). Why?

This is the way it was in RFC 2251. At some point, [protocol] added the SIZE (1..MAX) to the ASN.1 to make it consistent with the text. It was then found that this prevents Kurt's T/F filter spec from working without breaking protocol, so we removed the ASN.1 grammar.

>> 4.6. Modify Operation
>
>> ModifyRequest ::= [APPLICATION 6] SEQUENCE {
>> object LDAPDN,
>> changes SEQUENCE OF change SEQUENCE {
>> operation ENUMERATED {
>> add (0),
>> delete (1),
>> replace (2) },
>> modification PartialAttribute } }
>
>I wonder if the PartialAttribute should be OPTIONAL in the grammar and
>instead "REQUIRED unless otherwise specified" in the text, anticipating
>new ModifyRequest operation types (per [LDAPIANA]) that need a different
>data structure than PartialAttribute. Such operations can then add
>trailing sequence elements (which servers are already required to
>accept) at the end of the 'change' SEQUENCE.

PartialAttribute allows zero elements (in the ASN.1 grammar), so an empty one may be specified. If I remember correctly, we decided this was good enough for purposes of future extension.

>> 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.
 
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.

>> 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.

>> Server implementations SHOULD NOT restrict where entries can be
>> located in the Directory unless DIT structure rules are in place.
>> Some servers allow the administrator to restrict the classes of
>> entries which can be added to the Directory.
>
>Seems to me this fits better in [Models] than [Protocol]. If left in
>[Protocol], it really applies to Modify DN and Modify too (and extended
>operations like Modify Password), so it's a bit misplaced under Add.

I agree, my suggestion about 'conforming to the data model' above should be generic and should apply to all update operations.

>> 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?

>> 6. Security Considerations
>
>> The matchedDN and diagnosticMessage fields, as well as some
>> resultCode values (e.g., attributeOrValueExists and
>> entryAlreadyExists), could disclose the presence
>
>or absence
>
>(consider an attribute which is considered by clients to have some
>default value when absent.)

yes.

>> the specific data in
>
>s/the specific/of specific/.

yes.

>> the directory which is subject to access and other administrative
>> controls. Server implementations should restrict access to protected
>> information equally under both normal and error conditions.
>
>========================================================================
>
>Editorial comments:
>
>> 4.1.1.1. Message ID
>
>> The message ID of a request MUST have a non-zero value different from
>> the the messageID of any other uncompleted requests in the LDAP
>
>s/the the/the/.

I missed it even as I read it above!

>> 4.1.9. Result Message
>
>> If no aliases were
>> dereferenced while attempting to locate the entry, this will be a
>> truncated form of the name provided or if aliases were dereferenced,
>> of the resulting name, as defined in Section 12.5 of [X.511].
>
>That sentence is pretty hard to parse. Could you turn it around a bit?
>
>This will be a truncated form of the provided name if no aliases
>were dereferenced while attempting to locate the entry, or of the
>resulting name if aliases were dereferenced.
>
>Re-insert "as defined in Section 12.5 of [X.511]" where appropritate,
>I'm not sure which part of the original sentence it ties to.

Yes, need to make it readable

>> 4.14. StartTLS Operation
>> 
>> The Start Transport Layer Security (StartTLS) operation*s purpose is
>^^^
>s/*/'/. 8-bit character.

yikes

>> 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'

>> 5. Protocol Encoding, Connection, and Transfer
>> 5.2. Protocol Encoding
>> 5.3. Transmission Control Protocol (TCP)
>
>There is no section 5.1. Renumber sections 5.2-5.3.

The result of a hasty edit, I'm sure

>-- 
>Hallvard

Thanks,
 
Jim

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 29 Oct 2004 14:40:42 +0200

Jim Sermersheim writes:
> 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.

> Well, who is making the determination? The client. And the client receives

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.

> 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.

>>Prepend "Detected" as in authmeth section 3.1.1.

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

>>> so by returning the unavailable resultCode.

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

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 29 Oct 2004 15:28:11 +0200

>> How about: "Whether the modification was applied or not is

I forgot to add: Yes, I think that's the best suggestion so far, though
as you can see I'd prefer "is" over "was".

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 29 Oct 2004 11:23:39 -0700

As chair, I note that the WG did specifically discussed adding
these constraints to the revised ASN.1 module, initially during
a [Filter] WGLC and then during a early [Protocol] WGLC.  Based
on these prior discussions, and the fact that an issue was not
raised during the prior WGLC, I must assume that the consensus
of the WG is for the and/or Filter sets to explicitly include
SIZE (1..MAX) constraints in the ASN.1 module.  Hence, I feel
obligated assume consensus supports keeping these constraints.

It seems however that some have raised "new" concerns supporting
dropping the SIZE (1..MAX) constraints, however, it not quite
clear what that concern is.  Hence, I suggest that those who
support dropping these constraints based upon "new" concerns
detail those concerns to the WG and why it is necessary (or
appropriate) to drop these constraints.  We'll discuss the "new"
concerns and see if consensus now clearly supports dropping
these constraints.  In absence of a clear consensus to drop the
constraints, the chairs will direct the Editor to include
these constraints.

Kurt, as LDAPBIS co-chair

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 29 Oct 2004 13:34:20 -0700

>PartialAttribute allows zero elements (in the ASN.1 grammar), so an empty one may be specified. If I remember correctly, we decided this was good enough for purposes of future extension. 

While I couldn't find the discussion in the archives
(could have been off-list), I do recall consideration
of this issue.   IIRC, the suggestion was to replace
the components of a change with a CHOICE in a manner
which would have a BER-compatible encoding.  Anyways,
I think the conclusion of those discussions was that
Modify extensions were not overly constrained by the
current ASN.1 data type definition.

While I believe it unlikely that WG consensus would
support making the modification component OPTIONAL, I
will defer declaring consensus for a bit to allow
on list discussion.  Those who support making this
change should offer compelling reasons why it should
be made.

Kurt