schema-07 comments

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

Mostly an update of my message 'schema comments' of 11. Dec 2003, which
you seem to have missed.

> 2.23  postalAddress
> 2.27  registeredAddress

> "15 Main St., Ottawa, Canada"

Please use the LDAP syntax, "15 Main St.$Ottawa$Canada".

> 2.26  preferredDeliveryMethod

>   if mhs-delivery is preferred over telephone-delivery, which is 
>   preferred over all other methods, the value of the value would 
>   be {1, 9}.

That's the ASN.1 representation.  Please use the LDAP string syntax,
"mhs $ telephone".  Or spell your examples of DNs something like
{{{"c", "US"}}, {{"o", "Something, Inc."}}}:-)

> 2.43  x500UniqueIdentifier

>   In X.520 [X.520], this attribute type is called 
>   uniqueIdentifier.  This is a different attribute type from both the 
>   "uid" and "uniqueIdentifier" attribute types.
               ^^^^^^^^^^^^^^^^
If you mean an LDAP "uniqueIdentifier" attribute type, that is not
defined in this document.  Where is it defined?

------------------------------------------------------------------------

Editorial comments:

Sections 2.21 (owner), 2.28 (roleOccupant):

<o=Widget',' Inc.> in DNs should be <o=Widget\, Inc.> or <o=Widget\2C
Inc.'>.  The -06 draft had a different error: The comma was unquoted.

roleOccupant has lost 'o=' in front of Widget.

2.30 (seeAlso), OTOH, has no comma in 'Widget Inc.'.

2.40 (uniqueMember).

I don't think DN examples should have space after the ',' between RDN
components.  IIRC, that was an LDAPv2ism.

Also, these paragraphs have some bad formatting: Text dropped to the
left with no margin, maybe after a spurious line break.  Maybe the RFC
Editor has another nroff than you.  I've seen a similar effect when a
nroff macro receives more arguments than it supported.  For some nroff
commands I believe it can be fixed by putting the .command alone on one
line, so it will take the next line as its argument.

Sections 1.4, 2.26, 2.30 and 2.40 have the same formatting problem.

Spurious blank lines:
  Section 2.4:  2 in first paragraph.
  2.9: 1 in last paragraph.
  2.28: 1 in first paragraph.
  2.42: 1 in first paragraph.
  6: 1 in third paragraph.
  7.2: 2 before the [LDAP-CRL] reference.
  Appendix A: 2 before item 2.

Section 2.35 lacks a blank line before the attribute
definition and has an extra blank line after it.

These formatting problems seem to be new since schema-06, though I've
only checked -06 for a few of them.

> 1.1  Situation

>   Section 3.4 of 
>   this document supercedes the technical specification for the 'dc' 

Section 2.4.

> 2.10  facsimileTelephoneNumber

>   numbers (and, optionally, the parameters) for facsimile terrminals.  
                                                            ^^^^^^^^^^
                                                            terminals.

> 2.28  roleOccupant

>   objects(normally people) that fulfill the responsibilities of a role 
          ^^^
      missing space

> 2.32  sn

>    The sn (surname)attribute type contains name strings for the family 
                   ^^^
              missing space

> 2.35  telephoneNumber

>   (e.g., 1 234 567 8901)  Each number is one value of this 

Suggest '+1 ...' instead of '1 ...'.

> 2.40  uniqueMember

>    Distinguished Names of the object include a value that distinguishs 
                                                            ^^^^^^^^^^^^
                                                            distinguishes

>   "ou=1st Battalion#'010101', o=Defense, c=US".  

Missing 'B' after bit string.

> 3.9  organizationalRole

>   represents a job or function or position in an organization.
                    ^^^^
                 job,   function or position

> 4.  IANA Considerations

>      Specification: RFC XXXX [editor's note:  The RFC number will be 
>            the one assigned to this document.

Missing ']'.

> 7.1  Normative

> ...[ROADMAP]  Zeilenga, K., "LDAP:  Technical Specification Road Map",

Kill the '...'.

> 7.2  Informative

>    [F.1]  Operational Provisions For The International Public Telegram
>    Service Transmission System, CCITT Recommmendation F.1, 1992

Indent 2nd line.

> Appendix A  Changes RFC 2256

s/Changes/Changes made since/.

There are more changes:

- Removed '{number}' (minimum lower bound?) after the SYNTAX oid for
  all attributes that had that.

- Added text about Unicode, SASLprep and UTF-8 for userPassword.

-- 
Hallvard