[Date Prev][Date Next] [Chronological] [Thread] [Top]

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.