Subject: schema-08 notes

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 25 Mar 2005 20:53:48 +0100

schema-08 says:

> 2.4  dc

I think section this needs '(Source: RFC 2247)', since one needs to
read that RFC to find an object class to put "dc" in.  The RFC is
mentioned elsewhere, but section 2.4 and 3.* is where readers who need
such an object class will be looking.

(Copied from message 'More schema-07 nits', 3 Jun 2004 which I don't see
a reply to.)

What's the criteria for getting a "(Source: ...)" anyway?
Every other attribute without one can get (Source:  X.520) except
userPassword which is from X.509.  Every object class, X.521.

==

> 2.36  teletexTerminalIdentifier
>
>    The withdrawal of Rec. F.200 has resulted in the withdrawal of this
>    attribute.

So, insert 'OBSOLETE' in the attribute definition below?

>    ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
>       SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )

==

> 2.41  userPassword
>    The application SHOULD prepare textual strings used as passwords by
>    transcoding them to Unicode, applying SASLprep [SASLprep], and
>    encoding as UTF-8.

Copy this from [protocol] 4.2 (Bind Operation)?
     "The determination of whether a password is textual is a local
     client matter."

==

The common text "Each <whatever> is one value of this multi-valued
attribute." is missing from 2.28 roleOccupant, 2.29 searchGuide, 2.38
title, 2.40 uniqueMember.

==

> 2.27  registeredAddress
>    (e.g., one value is
>    "Receptionist\, Widget Inc.\, 15 Main St.\, Ottawa\, Canada")

This is still wrong.  '$' separates lines in Postal Address syntax:
     "Receptionist$Widget Inc.$15 Main St.$Ottawa$Canada"

Except maybe it should be ...$Widget, Inc.$... like most other Widget,
Inc. examples.  I'm not sure if one omits commas in such cases in
Canada, for the sake of times when people translate newlines to commas
too.

==

> 1.1  Situation
>    Section 2.4 of
>    this document supercedes the technical specification for the 'dc'
>    attribute type found in RFC 2247.  The remainder of RFC 2247 remains
>    in force.
>
>    This document updates RFC 2798 by replacing the informative
>    description of the 'uid' attribute type, with the definitive
>    description provided in Section 2.39 of this document.

Maybe add refernces to these two RFCs, since they are updated instead of
obsoleted?

==

> 7.  References
> 7.1  Normative
>    [X.509]  The Directory:  Authentication Framework, ITU-T
>             Recommendation X.509, 1993

This normative reference is not used, but there are informative
references that name X.509 so maybe it should be moved to informative
references.

==

Editorial comments:

The draft has lost its formfeeds.

> 2.21  owner
>    (e.g., The list object which has DN:  "cn=All Employees,
>    ou=Mailing List,o=Widget\, Inc.", is owned by the Human Resources
>    Director.  Therefore, the DN of the director (role) would be a value

s/The/the/.
s/list/mailinglist/.  ("list object" sounds like it could be some LDAP
thing which the reader is not aware of.)

> 2.30  seeAlso

The three 'o=Widget Inc.'s ought to be 'o=Widget\, Inc.' to match the
other Widget, Inc. examples in the draft.

> 2.32  sn
>
>    The sn (surname)attribute type contains name strings for the family

Missing space after ")".

These examples are not in double quotes, unlike the other examples:

> 2.26  preferredDeliveryMethod
>    (...) the value would be:
>       mhs $ telephone

> 2.35  telephoneNumber
>    (e.g.,
>    +1 234 567 8901)

> 2.42  x121Address
>    The x121Address attribute type contains data network addresses
>    (e.g., 36111222333444555) as defined by ITU Recommendation X.121

> 3.9  organizationalRole
>
>    The organizationalRole object class is the basis of an entry which
>    represents a job or function or position in an organization.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 job,   function or position

Reference glitches:

> 1.4  Source
>       2.39                 RFC 2798 [2798]

Reference name should be           [RFC2798]

> 2.4  dc
>    holding one component, a <label> [RFC1034}, of a DNS domain name

s/}/]/.

>                     Appendix A  Changes Made Since RFC 2256
>           LDAP PKI is now discussed in [LDAP-CRL] and {LDAP-CERT].

s/{/[/.

> 5.  Security Considerations
>    Note that when used for authentication purposes [AuthMeth], the user

This reference is called [AUTHMETH].

> 7.  References
> 7.1  Normative
>    [RFC2234]  Crocker, D., Overell P., "Augmented BNF for Syntax
>               Specifications: ABNF", RFC 2234, November 1997

This reference is not used.

-- 
Hallvard

---

From: Andrew Sciberras <[email-masked]>
Date: Sat, 26 Mar 2005 11:12:30 +1100

Hi Hallvard,

Thanks for your comments.
I've added some inline comments for things that may need to be discussed 
further. For everything else, I've either noticed these myself or 
totally agree with you.

> userPassword which is from X.509.  Every object class, X.521.

I'm thinking that the table in Section 1.4 should be all that is 
required to indicate the source of definitions.
In which case I think I will remove the redundant (and in this case 
inconsistent) (Source:...) information.

> Canada, for the sake of times when people translate newlines to commas
I was going to change this to:
"Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada")

It adds consistency (including the comma after Widget) and correctness 
(removing the escaping of commas).

> references that name X.509 so maybe it should be moved to informative
I will make reference to X.509 in section "1.1 Situation".
I will replace the following text:

PKI-related schema elements are now specified in
[LDAP-CERT] and [LDAP-CRL].

with:

PKI-related schema elements from X.509 [X.509] are now specified in 
[LDAP-PKI]. Where LDAP-PKI is a reference to draft-zeilenga-ldap-x509-xx

> The draft has lost its formfeeds.

I had noticed this... They'll be back in -09

I had noticed a lot of the items mentioned below. I agree with your 
recommendations and will update them in the next revision.

>>   (...) the value would be:

Thanks,

Andrew Sciberras.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 25 Mar 2005 17:25:10 -0800

At 04:12 PM 3/25/2005, Andrew Sciberras wrote:
>I've added some inline comments for things that may need to be discussed further. For everything else, I've either noticed these myself or totally agree with you.
>
>
>I'm thinking that the table in Section 1.4 should be all that is required to indicate the source of definitions.
>In which case I think I will remove the redundant (and in this case inconsistent) (Source:...) information.

I rather remove the table and instead add source information
in the sections providing the LDAP syntax description.

>>So, insert 'OBSOLETE' in the attribute definition below?

No!  OBSOLETE means obsolete in the subtree, hence whether to
mark the element as OBSOLETE in the subschema should be left to
the administrator.  (IIRC, we've discussed this before.)

>>>1.1  Situation

This section should likely be renamed
        Relationship to other specifications

(for consistency with other LDAPBIS documents)

>>Maybe add refernces to these two RFCs, since they are updated instead of

I do not think any references should be added for these mentions
of RFC 2247 and RFC 2798 because the reader need not read these
RFCs to understand this text.

>I will make reference to X.509 in section "1.1 Situation".

I rather not.

>PKI-related schema elements from X.509 [X.509] are now specified in [LDAP-PKI]. Where LDAP-PKI is a reference to draft-zeilenga-ldap-x509-xx

The PKI schema elements are for a later revision of X.509
than which we reference for userPassword.  So, adding
this reference may confuse the reader.  I suggest you
drop 'from X.509 [X.509]' from your text.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 26 Mar 2005 03:26:22 +0100

> in the sections providing the LDAP syntax description.

The table is unfriendly now, but some text so it can be read without
checking against section numbers would fix that:

      Sections            Source              Schema elements
      ==================  ==================  =========================
      2.4                 RFC 2247 [RFC2247]  'dc' attribute type
      2.39                RFC 2798 [RFC2798]  'uid' attribute type
      2.41                X.509 [X.509]       'userPassword' attr. type
      Rest of 2.1 - 2.43  X.520 [X.520]       Other attribute types
      3.1 - 3.12          X.521 [X.521]       Object classes

I could go for either having that only, or (Source: ...) only, or both.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 26 Mar 2005 03:43:08 +0100

> the administrator.  (IIRC, we've discussed this before.)

Found it.  It was removed from the drafts after your message
<http://www.openldap.org/lists/ietf-ldapbis/200012/msg00055.html>
and discussed again in "Question on Your Comment" in Nov 2001 ending
with <http://www.openldap.org/lists/ietf-ldapbis/200111/msg00029.html>.
That thread seems to have been lost after that, for I cannot find this
information in the drafts.  It seems to belong in [Models] now, but that
just says

        [ SP "OBSOLETE" ]          ; not active
    OBSOLETE indicates this <whatever> is not active;

"not active in the subschema" would be more informative.

Still, as far as I can tell it might make sense to add both your text
and Kathy's text which you quoted in the last message in the thread.
Though your message is in response to Kathy's, I don't quite see how
it addresses her concern:

At 02:38 16 Nov 2001, Kurt D. Zeilenga wrote:
> Subject: Re: Question on Your Comment
>
> X.511(93), 14.7 says:
>   A number of subschema policy operational attributes defined
>   in the following clauses contain an obsolete component.  This
>   component is used to indicate whether the definition is active
>   or obsolete in the subschema administrative area.
>
> Hence, I suggest you paraphrase this for 2252bis:
>   The OBSOLETE term is used to indicate whether the definition
>   is active or obsolete in the subschema.  Only active
>   definitions regulate the directory [X.511].
>
> Kurt
>
> At 02:38 PM 2001-11-14, Kathy Dally wrote:
>> Hi Kurt and Steven!
>>
>> My conclusion concerning the OBSOLETE field is that a server can return
>> a value of any of the schema element attributes (e.g., attributeTypes,
>> nameForms) with the substring "OBSOLETE" included or not without regard
>> to whether or not the BNF definition of the element includes the word
>> "OBSOLETE". 
>>
>> In RFCs 2252 and 2256 (and 2251), this field is not discussed, relying
>> entirely on the X.500 semantics.  In X.501, an OBSOLETE field is defined
>> only in the syntaxes of the schema definition operational attributes and
>> is cannot appear in any "paper" attribute specifications.  LDAPv3,
>> however, put the OBSOLETE field into the directory object superclass
>> definition of attributes.  This allows an OBSOLETE field to be defined
>> in any attribute specification separately from the syntax of the
>> attribute.  This means that a user attribute type can be written as:
>>
>>        ( 1.2.3.4.5.6 NAME 'newAttr'
>>          OBSOLETE
>>          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
>>
>> In this case, what would OBSOLETE mean in the standard or documentation?
>>
>> It seems to me that RFC 2252bis should explicitly state that the
>> OBSOLETE field cannot occur in any written attribute specifications.  It
>> should also, refer to the X.501 "OBSOLETE mechanism".  Otherwise, I fear
>> an interoperability problem with LDAP implementations that make some
>> proprietary use of the OBSOLETE field.
>>
>> Thanks for your help,
>> Kathy

(snipping the rest of the thread)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 25 Mar 2005 19:03:41 -0800

>"not active in the subschema" would be more informative.

During AUTH48, I'll ask the RFC Editor to replace the section 4.1
text:
   The OBSOLETE field, if present, indicates the element is not active.
with:
   The OBSOLETE field, if present, indicates the element is not active
   in the subschema.  Only active definitions regulate the directory.

and in 4.1.X replace s/not active/not active in the subschema/.
This likely will require explicit AD approval.  Given this is
a minor clarification, that shouldn't be a problem.

More significant changes would likely be a problem as this
I-D is "IESG Approved".

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 29 Mar 2005 07:04:27 +0200

Section 2.34, street, could use an example with ", " between components,
to distinguish it from attrs with Postal Address syntax.  I've seen
these syntaxes being confused in both directions.

Section 2.39, uid, needs to mention that the X.500 name is userid.

Also I suggest to clarify the distinction between LDAP vs. X.500 names.
E.g.

> 2.34  street
>
>   The street (streetAddress) attribute type (...)
>   ( 2.5.4.9 NAME 'street'
>   (...)

What does that mean - is 'streetAddress' a name for 2.5.4.9 or not?
I expect it's too much of a change now to change it to

    ( 2.5.4.9 NAME ('street' 'streetAddress')

so I suggest:

    The street (streetAddress in X.500) attribute type (...)

and then note in Section 2 that implementations MAY recognize the
X.500 names as alternate names for these attributes.

Editorial nitpick for Section 2.39:
>   ( 0.9.2342.19200300.100.1.1
>      NAME 'uid'
all other NAMEs are on same line as the OID, including 'dc' which also
has a long OID.

And as briefly noted previously: In the table in 1.4, the source for
section 2.41 (userPassword) is X.509, not X.520.

-- 
Hallvard

---

From: Andrew Sciberras <[email-masked]>
Date: Tue, 29 Mar 2005 15:53:56 +1000

Hi Hallvard,

> these syntaxes being confused in both directions.

Not a problem.

> Section 2.39, uid, needs to mention that the X.500 name is userid.

At the moment this is mentioned in the Acknowledgments. I will make it 
explicit in section 2.39.

> X.500 names as alternate names for these attributes.

I think that the former suggestion could be the most appropriate.
Since 'streetAddress' is already registered with IANA as a name of the 
2.5.4.9 attribute, it would only make sense to include it within the 
definition.
This will also result in me updating the IANA Considerations section to 
include all of the 'alternate' names.

> all other NAMEs are on same line as the OID, including 'dc' which also

Thanks.

> section 2.41 (userPassword) is X.509, not X.520.

No problems.

Andrew Sciberras.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 28 Mar 2005 22:15:16 -0800

At 09:53 PM 3/28/2005, Andrew Sciberras wrote:
>At the moment this is mentioned in the Acknowledgments. I will make it explicit in section 2.39.
>

It's already said elsewhere that servers can recognize attribute
types by additional names.  However, I do not think we should
provide additional names, as that will just lead to their
use, use that will lead to interoperability problems.

>Since 'streetAddress' is already registered with IANA as a name of the 2.5.4.9 attribute,

Well, its registered to keep it from be used for some other
attribute type, which would be problematic.  However, 'street'
should be used in LDAP as this is the only name which
implementations which support this attribute are required to
recognized.

>it would only make sense to include it within the definition.

Please do not add the X.500 attribute type name to the NAME
parameter.   Just s/streetAddress/streetAdddress in X.500/,
please.

>This will also result in me updating the IANA Considerations section to include all of the 'alternate' names.

That's fine.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 29 Mar 2005 16:05:10 +0200

Kurt D. Zeilenga writes:
>> It seems to belong in [Models] now, but that
>> just says
>>

Hm.  Or maybe 'in this subschema', to clarify that it's not any
subschema in any server using this schema element?

-- 
Hallvard

---

From: Andrew Sciberras <[email-masked]>
Date: Wed, 30 Mar 2005 19:27:33 +1000

> Hi Hallvard,

Hi,

>> these syntaxes being confused in both directions.

I think I'd like to elaborate on this topic a little bit.

The street attribute type is intended for a different usage than the 
attribute types that use the Postal Address syntax.

Lets take this address as an example (Just something I grabbed from the 
IETF webpage):

Minneapolis Hilton and Towers
1001 Marquette Avenue
Minneapolis, MN 55403 USA

If you wanted to represent this address in its entirety, then you would 
use an attribute with a Postal Address syntax.
Using the postalAddress attribute, you can create a Postal Address value 
that separates the components in any way you like... Such as:

"Minneapolis Hilton and Towers$1001 Marquette Avenue$Minneapolis, MN 
55403$USA"

I don't see how you can draw a comparison between this representation of 
an address and what 'street' has to offer.
The intention of 'street' would be to hold the following value:
"1001 Marquette Avenue"

And, 'st' would be: "Minneapolis"
And 'postalCode' would be: "55403"

So, I guess my point is, I don't believe that there should be an example 
with ", " to separate components, when the attribute type isn't really 
designed to hold multiple components within a single value.

Andrew Sciberras.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 30 Mar 2005 16:56:28 +0200

Andrew Sciberras writes:
> If you wanted to represent this address in its entirety, then you
> would use an attribute with a Postal Address syntax.

Well, our site's directory doesn't, and we are not alone.  We'd rather
use a well-known attribute than invent our own which only our own
clients would know about.  For that matter, our data source for street
is harder for a program to parse.  It's partly free form and maintaining
it gets lower priority than the postalAddress source: People complain if
the postal address is wrong, since they'd lose snail mail.

> I don't see how you can draw a comparison between this representation
> of an address and what 'street' has to offer.

street and postalAddress contain similar data, so people sometimes treat
them the same way.  That is pretty "obvious", after all.  So I've seen
streets with '$' in the LDAP directory, and clients that break up street
addresses at '$'s.

> And 'postalCode' would be: "55403"

Not at our site.  postalCode, if we used it, would be the postal code of
the postal address.  Usually that is a postbox and the street address
has another postal code.  So street is e.g.  "Research Street 3, 0373
OSLO" or "Admin. building, Problem street 7, 0313 OSLO" (in Norwegian).
That fits the description of street:

   physical addresses of the object to which the entry corresponds, such
   as an address for package delivery.

Oslo is big enough that omitting the postal code would not be a good
idea for package delivery.

> designed to hold multiple components within a single value.

It's true it's not designed for multiple components.  I should have said
that if one wants to stuff multiple components into it, the natural way
is with ", ".  Now that I think of it, I suppose CRLF would be another
way but I haven't seen that usage.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 30 Mar 2005 08:00:43 -0800

The examples we give, as well as the prose describing the
attribute type, should be consistent with X.520.

The X.520 example is: "Arnulfstraße 60".
The X.520 description is:
        The Street Address attribute type specifies a site for
        the local distribution and physical delivery IN a postal
        address, i.e. the street name, place, avenue, and the
        house number.  When used as a component of a directory name,
        it identifies the street address at which the named object
        is located or with which it is associated in some other
        important way.

Emphasis on IN added.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 30 Mar 2005 18:20:17 +0200

>         is located or with which it is associated in some other

Ouch.  Then the descriptions of street in RFC 2256 and [Schema] are
quite wrong.

As in my example (below), a Street Address a above may be unsuitable for
"physical address[es] of the object to which the entry corresponds, such
as an address for package delivery", and a separate postalCode attribute
may not help.

>> postalCode, if we used it, would be the postal code of

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 30 Mar 2005 08:32:09 -0800

>as an address for package delivery", and a separate postalCode attribute

Basically, I think values of location attributes (l, st, postalCode,
streetAddress) were intended for lookup purposes and not for posting
items for delivery.  Values of postalAddress should be used for
posting items for delivery.

Kurt

---

From: John McMeeking <[email-masked]>
Date: Wed, 30 Mar 2005 10:28:27 -0600

RFC 2256 truncated the X.520 definitions quite a bit, and as a result I
believe you are misusing these attributes.  The RFC (and the draft
replacement) does refer to the original documents, but ...

Maybe we should incorporate more of the text from X.520 (or other sources)?

From X.520 1993:

5.3.4 Street Adress

The Street Address attribute type specifies a site for the local
distribution and physical delivery in a postal address, i.e.
the street name, place, avenue, and the house number. When used as a
component of a directory name, it identifies the
street address at which the named object is located or with which it is
associated in some other important way.

An attribute value for Street Address is a string, e.g. "Arnulfstraße 60".

5.6.1 Postal Address

The Postal Address attribute type specifies the address information
required for the physical delivery of postal
messages by the postal authority to the named object.

An attribute value for Postal Address will be typically composed of
selected attributes from the MHS Unformatted
Postal O/R Address version 1 according to CCITT Rec. F.401 and limited to 6
lines of 30 characters each, including
a Postal Country Name. Normally the information contained in such an
address could include an addressee's name,
street address, city, state or province, postal code and possibly a Post
Office Box number depending on the specific
requirements of the named object.

5.6.2 Postal Code

The Postal Code attribute type specifies the postal code of the named
object. If this attribute value is present it will
be part of the object's postal address.

John  McMeeking

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 30 Mar 2005 19:00:17 +0200

Kurt D. Zeilenga writes:
>> As in my example (below), a Street Address a above may be unsuitable
>> for "physical address[es] of the object to which the entry
>> corresponds, such as an address for package delivery", and a separate
>> postalCode attribute may not help.
>

You mean in our case should have two postalAddress values, both the
physical delivery address and the address used by the postal service?
That doesn't work, we want programs like www lookup to treat them
differently.

-- 
Hallvard

---

From: Andrew Sciberras <[email-masked]>
Date: Thu, 31 Mar 2005 13:21:06 +1000

I agree with John.

RFC2256's description: "This attribute contains the physical address of 
the object to which the entry corresponds, such as an address for 
package delivery", is incorrect.

2256 states that the street attribute can hold information required for 
package delivery. However, X.520 makes the distinction that 'Postal 
Address' contains the information for physical delivery and that 'Street 
Address' simply contains a subset of this information.

Since consistency with X.500 is important, I will re-enforce this in the 
new revision of User Schema.

Andrew.

John McMeeking wrote:

>>>>>Section 2.34, street, could use an example with ", " between
> 
> components,
> 
>>>So, I guess my point is, I don't believe that there should be an
> 
> example
>