RE: Attribute Name Length Bounds

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Chris Apple [mailto:capple@dsi-consulting.net]

(reposting to the list...)

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

If the server rejects overly-long names with an error message, fine, but your
message implied that it silently ignored the characters comprising the excess
length in the name. If it seems that the spec is ambiguous about the
significance of characters in a short name, perhaps it would be sufficient to
state in the the spec "all of the characters in an attribute name are
significant. If an attribute name is presented that exceeds a server's
implementation limits, the server MUST fail the request with an error code."
(Maybe NAMING_VIOLATION or CONSTRAINT_VIOLATION...) This would satisfy the
basic need without specifying arbitrary numbers for minimum acceptable
lengths.

> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com]

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