duplicate type names

["Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>]

Oops. I realized just after I hit "Send" that my lathered-up reply
to Harald's message was not on his topic at all. With this message,
I'm changing the name (Subject) of this thread, so that the syntax
and semantics of my object (a rant about reusing names of attributes
and objectclasses) do not collide with Harald's object (on the
topic of alternate names) in the global message namespace.

BTW, having more than one name (such as alternate names) for a type
increases the opportunities for collisions. 


Harald Tveit Alvestrand wrote:
> 
> After looking through the LDAP RFCs, both V2 and V3, I find myself still
> unable to answer this:
> 
> Although RFC 2256 section 5.4 unambiguously states that "cn" is associated
> with the OID 2.5.4.3 "X.500 CommonName", and the language of RFC 2252
> section 4.2:
> 
>  >   Schema developers MUST NOT create attribute definitions whose names
>  >   conflict with attributes defined for use with LDAP in existing
>  >   standards-track RFCs.
> 
> bars the use of "cn" for anything but this, I cannot find a place that
> gives an opinion on whether the use of other names, like "commonName", for
> the same attribute should be:
> 
> - freely allowed and encouraged
> - allowed, but discouraged
> - disallowed
> 
> (my personal take: ought to be disallowed, or at least fiercely sworn at,
> for all newly constructed databases. But I'm enamored of uniformity....)
> 
>                          Harald
> 
> --
> Harald Tveit Alvestrand, Maxware, Norway
> Harald.Alvestrand@maxware.no

Harald's preference for uniformity in the names of attributes is
the only sensible approach. It must apply to the names of
objectclasses, as well.

The practice of reusing names for attributes and objectclasses must
be disallowed, not only in the RFCs, but also by the behavior of 
servers.

The operational requirement for unambiguous precision in these names
makes a resource like Harald's OID Registry an indispensible 
tool for schema designers. For those who may not have taken
advantage of this service, see http://www.alvestrand.no/objectid/

Servers should reject attempts to reuse names of attributes and
objectclasses which have been previously defined for the given 
server instance, whether they're defined in standards-track RFCs or
not.

The draft-ietf-ldup-model-01.txt asserts:

  6.2 Schema Knowledge

  Schema subentries should be subordinate to the naming contexts to
  which they apply.  Given our model, a single server may hold replicas
  of several naming contexts. It is therefore essential that schema
[pagebreak snipped]
  should not be considered to be a server-wide policy, but rather to be
  scoped by the namespace to which it applies.

Does this imply that within a given server, "nameA" could refer to
more than one syntactic and semantic type?

I agree that different naming contexts may choose not to define many
attributes and objectclasses. This could be because they are of no
interest or use, or as a mechanism to restrict the types which are
stored within that context. But I disagree with any approach which
facilitates imprecision or ambiguity, such as could happen if names
are allowed to be reused anywhere.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@infostream.indy.cr.irs.gov    | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|