Subject: RE: Attribute Name Length Bounds

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 16 Jul 2003 15:39:28 -0600

All,
 
At this point it seems clear that it would be a good thing to make a
clarification to [Protocols]. That clarification would state something
like: all octets of a ber-encoded LDAP PDU are significant. No octets
may be ignored unless they are part of extended elements that are
themselves ignored.
 
Whether or not we want the TS to enforce mandatory minimums for element
lengths (such as attribute type names) is an issue in the data model
(and/or schema) doc(s).
 
Jim

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 17 Jul 2003 11:15:53 +0200 (CEST)

> may be ignored unless they are part of extended elements that are

It seems to me that the point is to give implementors advice about what to
do when any protocol elements exceed implementation-specific length
boundaries.  I agree with Ron that the significance of "all octets are
significant" isn't necessarily clear ...

I was going to recommend that this advice be added as another bullet in
the "Implementation Guidelines" section (since it applies to both server
and client, maybe adding a "general" 6.x section would be the clearest).

But then I read again these paragraphs from section 4.1.1 of protocol-16:

   If the server receives a PDU from the client in which the LDAPMessage
   SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
   the tag of the protocolOp is not recognized as a request, or the
   encoding structures or lengths of data fields are found to be
   incorrect, then the server MAY return the Notice of Disconnection
   described in section 4.4.1, with the resultCode set to protocolError,
   and MUST immediately close the connection.

   In other cases where the client or server cannot parse a PDU, it
   SHOULD abruptly close the connection where further communication
   (including providing notice) would be pernicious. Otherwise, server
   implementations MUST return an appropriate response to the request,
   with the resultCode set to protocolError.

I would think that not being able to fit a PDU element into your
implementation's data slots would be an instance of "cannot parse".  If
so, then this case is already covered by the above text (where we should
still probably add something like: "including not being able to store a
PDU element in implementation-specific data structure" to the above).
Whether the above text is actually correct may be another question ...

If PDU-element-too-big-to-fit is not an instance of "cannot parse", then I
think adding advice in section 6 would be the right thing to do.

 - RL "Bob"