Re: DC/UID

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

In a previous post to this thread, I said:
  However, if we go the registry route, one could argue that
  'dc' and 'uid' could safely be removed from the table and
  that incorporation of the attribute types (and matching rule)
  is unnecessary.

If we go the "any short name" route (which I believe we've already
eliminated as not viable... see archives for details), then it could
be argued that the table could be removed (or made non-normative)
and that the incorporation of the attribute types (and matching
rule) is unnecessary.

Its my personal opinion, that DC and UID should be added regardless
of "published table" issues as we use them in numerous examples.
While use in examples doesn't demand their specifications
be incorporated normatively, I think its best to only use normatively
defined elements in examples.  And while we could change the
examples to use other elements, I prefer to continue to use DNs
which follow the Internet naming plan (RFC 2377) in our examples.

With regards to changing the "published table" text in our
DN draft, I note that the WG is considering "registry" approaches
here.  As I noted on the list a few months ago, the short name
issue is really not DN-specific.  We need to address it in
draft-ietf-ldapbis-models [Models] first and then, if possible
and agreeable, adapt the [Models] approach to DN.

An alternative DN I-D which uses the current [Models] approach
should be announced to the list shortly.  Interesting enough,
this I-D requires a normative reference to a DC/UID specification.

Kurt


At 05:41 AM 12/16/2002, Felix Gaehtgens wrote:
>Hi!
>
>Reading RFC2253 and Kurt's question, I can't help wondering whether the
>wording in 2.3 is really helpful, or whether we could adapt the wording
>slightly to reflect common practise in LDAP Directory deployment.
>
>Section 2.3 of RFC2253 also says:
>
>"If the AttributeType is in a published table of attribute types
>associated with LDAP [4], then the type name string from that table is
>used, otherwise [...]"
>
>[4] Resolves to RFC2252, which in turn references many other documents,
>which in turn reference others, and so forth :-)
>
>I don't think it is that helpful (from my perspective) to insist that
>type name string can ONLY be used when the AttributeType is part of a
>"published table of attribute types". I have seen quite many
>implementations that allow custom AttributeTypes' name string to be part
>of the DN. Why not reflect this in the future standard?
>
>Regards,
>
>- Felix
>
>
>Steven Legg wrote:
>
>> Kurt,
>>
>> Kurt D. Zeilenga wrote:
>> > I'm willing to consider both 'dc' and 'uid' as "core" as they
>> > are specifically mentioned in RFC 2253.  In the current
>> > DN draft, they are clearly MUSTs and hence an appropriate
>> > specification is necessary.
>>
>> I have no objection to dc or uid being in the core.
>>
>> > However, if we go the registry route, one could argue that
>> > 'dc' and 'uid' could safely be removed from the table and
>> > that incorporation of the attribute types (and matching rule)
>> > is unnecessary.
>>
>> The matching rule at least, should be added to the core specification
>> since matching rules are not readily configurable like new attributes
>> and object classes.
>>
>> > So, it may be best to table this discussion until consensus
>> > is reached on [models] and [dn].
>>
>> I'll put caseIgnoreIA5SubstringsMatch in the next revision of
>> the syntaxes draft anyway.
>>
>> Regards,
>> Steven
>
>
>
>Visit our website at http://www.britannia.co.uk
>
>This Email and any attachments contains confidential information and is intended
>solely for the individual to whom it is addressed. If this Email has been 
>misdirected, please notify the author as soon as possible. If you are not
>the intended recipient you must not disclose, distribute, copy, print or 
>rely on any of the information contained, and all copies must be deleted 
>immediately.
>Whilst we take reasonable steps to try to identify any software viruses, 
>any attachments to this e-mail may nevertheless contain viruses which our 
>anti-virus software has failed to identify. You should therefore carry out 
>your own anti-virus checks before opening any documents. Britannia Building
>Society will not accept any liability for damage caused by computer viruses 
>emanating from any attachment or other document supplied with this e-mail.
>Britannia Building Society reserves the right to monitor and archive all 
>e-mail communications through its network. No representative or employee 
>of Britannia Building Society has the authority to enter into any contract 
>on behalf of Britannia Building Society by email.
>Britannia Building Society is a member of the General Insurance Standards Council.
>Britannia Building Society is regulated by the Financial Services Authority
>and advises on and sells the life assurance, pension and unit trust products 
>provided  only by the Britannic marketing group.
>Britannia Building Society, Britannia House, Leek, Staffs, ST13 5RG.