[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Attribute Name Length Bounds



On Wed, 16 Jul 2003, Jim Sermersheim wrote:

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

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"