Subject: DC/UID

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 12 Dec 2002 09:13:00 -0800

RFC 2253 included DC (domainComponent) and UID (userid) in the
list of attribute types which are be recognized in DNs, but
did not provide a reference to where these attributes are defined.
The most obvious reference would be RFC 1274.

To avoid adding a reference to RFC 1274 and possible other RFCs,
I suggest the specifications for DC and UID be directly incorporated
into draft-ietf-ldapbis-user-schema.

 X.Y. dc

   The DC (domainComponent) attribute type specifies one
   component of a domain name.  For example, "example" or "com".
   (Source: RFC 1274)
   
    ( 0.9.2342.19200300.100.1.25 NAME 'dc'
     EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )         

 X.Z. uid

   The uid (userid) attribute type specifies a computer system
   login name.  (Source: RFC 1274)
                 
    ( 0.9.2342.19200300.100.1.1
      NAME ( 'uid' 'userid' )
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

This will also require adding a description for the
caseIgnoreIA5SubstringsMatch rule to draft-ietf-ldapbis-syntax:

    ( 1.3.6.1.4.1.1466.109.114.3
	 NAME 'caseIgnoreIA5SubstringsMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

comments?

	Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 12 Dec 2002 20:49:34 +0100

> into draft-ietf-ldapbis-user-schema.

I like that, except that if it is done I think we should also define
object classes which use them (account and domain), and attribute host
which is used by account.  So it does explode a bit.

-- 
Hallvard

---

From: [email-masked] (Mark C Smith)
Date: Thu, 12 Dec 2002 14:49:43 -0500

These are defined in several RFCs. We might as well put them in the LDAP 
core RFCs as you suggest.

-Mark Smith
 Netscape

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 12 Dec 2002 21:01:02 +0100

> which is used by account.  So it does explode a bit.

Whoops, also domain uses attribute associatedName.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 12 Dec 2002 11:59:08 -0800

>which is used by account.  So it does explode a bit.

That, I believe, would be going too much against our
charter statement that LDAP non-"core" Schema is beyond
our scope.

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.

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.

So, it may be best to table this discussion until consensus
is reached on [models] and [dn].

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 13 Dec 2002 10:46:37 +1100

Kurt,

> specification is necessary.

I have no objection to dc or uid being in the core.

> that incorporation of the attribute types (and matching rule)

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.

> is reached on [models] and [dn].

I'll put caseIgnoreIA5SubstringsMatch in the next revision of
the syntaxes draft anyway.

Regards,
Steven

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 13 Dec 2002 22:48:57 +0100

> charter statement that LDAP non-"core" Schema is beyond

Never mind.  I do think an attribute type without an object class
which allows it is pretty useless, but there are several other
such attribute types in the draft, so two more won't hurt.  In
particular since your suggested text (with Richard Huber's
correction) refers to RFCs which define such object classes.

-- 
Hallvard

---

From: "Felix Gaehtgens" <[email-masked]>
Date: Mon, 16 Dec 2002 13:41:34 +0000

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

> the syntaxes draft anyway.

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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 16 Dec 2002 07:59:04 -0800

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