RE: Attribute Name Length Bounds

["Chris Apple" <capple@dsi-consulting.net>]

The server wouldn't truncate it. It might say that it
doesn't support the attribute if it is longer than
the value it recognizes as significant for it. Or it might
reply back with some error message. Even though the
sending entity did have a resonable expectation that
it would be recognized...

And since there are not requirements in the specs
about a minimally supported attribute type name length,
replying to attribute types longer than a natively
constrained minimum with a message indicating an unsupported
attribute type is possible and could even be argued as
being compliant with the specs.

The point is that the possibility of interpreting
the specs in this way already set us up for deployment
issues related to several published schema with attribute
names on the longer side of what might have been considered
typical a few years ago.


Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:capple@dsi-consulting.net

http://www.dsi-consulting.com

-----Original Message-----
From: Howard Chu [mailto:hyc@highlandsun.com] 
Sent: Tuesday, June 17, 2003 5:21 AM
To: capple@dsi-consulting.net
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: Attribute Name Length Bounds


> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Chris Apple

> That's an accurate example of what I observed.
>
> The implementer is aware of the issue.
>
> I do see your point that this might be considered
> a bug.
>
> I also think that the fact that this bug can exist
> is a result of an ambiguity in the LDAPv3 proposed
> standard specs.

> Either interpretation is arguably correct given the state of
> the currently published proposed standards documents for
> LDAPv3. Thus implementers choosing either strategy are correct
> when they claim compliance with the specs.

????? If I send an ASN.1 encoded message to a server, and the server
arbitrarily  truncates the end off any of the several length-encoded fields
of the message while processing it, the server has corrupted the message. I
don't see how you can possibly interpret this as correct behavior in the
server.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support