schema-08 notes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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