Since I have rather strong views on this, I thought I would carefully read the thread and then provide some insight as to how decisions made in LDAPbis could affect various fora and standards bodies.
I've now gone through the thread twice, and still have the same conclusion - prescribing an attribute name length bound is BAD.
I'm not going to rehash any of the other arguments, because my feeling is that the WG is at somewhat of an impasse here. However, I will present an argument with new data, which is based on **users** wishing to develop directory schemata and finding that existing implementations have severe interoperability problems.
There are numerous standards bodies and fora, ranging from the TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web Services efforts, that have as part of their standards relatively long names. For those that are using UML (or UML-like) approaches, this takes the form of very long (> 64 characters is common) class, attribute, and relationship (e.g., association, aggregation, composition, etc.) names. The basic way that many of these schemata are designed uses a standard and simple method to generate the name of relationships: <object1><verb><object2>. Note that the order may also be <verb><object1><object2>.
Thus, whether a class or an attribute name could conceivably be shortened, it is almost certain that the relationship won't be able to be shortened a sufficient amount to do any good.
More importantly, however, as a schema designer, I find it unaccceptable that my schema has to go through some bizarre machinations when being transformed from an information model to a data model just so it has a prayer of being implemented in a directory. This is a great way to encourage people NOT to use a directory.
The mapping is difficult enough as it is - coming up with some difficult alias schemes, or methodology for name shortening, is not conformant to the basic schema that was agreed to by the standard body or fora in the first place.
Furthermore, once one "buys into" any type of translation mechanism to produce different names, it is guaranteed to cause interoperability problems, simply because it is too hard to guarantee that two different implementations will apply the same rule to produce the same name.
The examples listed above cover a very large body of work in different disciplines. Restricting name length to some arbitrary limit is inherently bad, as it flies in the face of the standards bodies and fora that are trying to use directories in the first place. They also exacerbate existing interoperability problems.
This WG might not have identified issues such as these explicitly as part of its charter, but it should consider them, since its fundamental purpose is to produce a draft standard. That requires interoperability.
Please, let's not ruin LDAP as it starts to mature.