Re: schema-08 notes

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.


Hallvard B Furuseth wrote:
> 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.

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.

> 
> ==
> 
> 
>>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.
> 
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).

> ==
> 
> 
>>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.
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


> 
> ==
> 
> Editorial comments:
> 
> 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.

>>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.
> 


Thanks,

Andrew Sciberras.