Discuss on draft-zeilenga-ldap-user-schema-06.txt

[ned.freed@mrochek.com]

(1) There isn't a single example in this entire document. It would really
    help to have some in LDIF format, especially for the more commonly used
    attributes.

(2) Every attribute defined in this document is multivalued, yet the
    descriptive text in almost every case implies the attribute is single
    valued. In each case the descriptive text needs to be changed to make
    it clear multiple values are possible.

    This may sound like a trivial issue but in practice it is not. Consider the
    uid attribute, which "specifies a computer system login name". The
    implication that each user has a single uid had resulted in many
    implementations only supporting single valued uid attributes. This then
    causes major trouble when such implementations encounter multivalued uid
    usage - which is perfectly legitimate and even useful.

(3) It would be enormously helpful if the object classes each attribute is
    in were listed as part of the attribute description.

(4) Most of the matching rules used in this specification are not mentioned
    in either section 2 or 6:

    caseIgnoreIA5Match              RFC 2252
    caseIgnoreIA5SubstringMatch     RFC 2798
    distinguishedNameMatch          RFC 2252
    caseIgnoreMatch                 RFC 2252
    caseIgnoreSubstringsMatch       RFC 2252
    telephoneNumberMatch            RFC 2252
    telephoneNumberSubstringsMatch  RFC 2252
    caseIgnoreListMatch             RFC 2252

    RFC 2252 is a normative reference, so a bit of text saying that these
    matching rules are defined there would be sufficent. RFC 2798 is an
    informative reference updated by this document, however, so the
    specification of caseIgnoreIA5SubstringMatch probably needs to be added
    to this specification.

(5) Conversely, only one of the matching rules specified in section 2
    (caseIgnoreListSubstringMatch) is actually employed by any of the
    attributes specified in this document! I guess this is OK on the
    grounds that these matching rules can be considered "user schema
    elements", but it seems a bit strange.

(6) The definition of associatedName probably should refer to RFC 1279 as
    well as RFC 1274.

(7) The various document* attributes and object classes would normally be
    associated with a document entry in the directory, not a user entry. This
    specification clearly states it is describing user attributes. Either the
    various document attributes and object classes should be removed
    (preferable) or else the scope of the specification needs to be
    expanded to include document as well as user schema.

(8) Assuming the documentLocation attribute is retained, the use of a
    multivalued attribute to describe "the location of the document
    original" seems a bit peculiar. Either (1) Make this attribute single
    valued, (2) Remove the term "original", or (3) Make it clear that
    all of the values must refer to the same actual location.

(9) The "homePhone" and "pager" attributes should refer to
    draft-allocchio-gstn-04.txt as a source for a "preferred" syntax for
    telephone numbers. This syntax should not be required, however.

(10) We have "homePhone" and "homePostalAddress" attributes but no "workPhone"
     and "workPostalAddress" attributes. This also seems peculiar. It also
     doesn't match up with vCard very well.

(11) The "host" attribute specifies "a host computer" in what context?
    Perhaps where the user has an account?

(12) The "homePostalAddress" and "info" attributes can contain multiple lines.
     The correct convention to use for line breaks needs to be described.

(13) Section 3.17 on the "mail" attribute should be changed to read:

3.17. mail

The mail (rfc822mailbox) attribute type holds an Internet mail
address conforming to the syntax of the Mailbox production
from [RFC2821] (e.g.: user@example.com).  (Source: RFC 1274)
      
    ( 0.9.2342.19200300.100.1.3
      NAME ( 'mail' 'rfc822Mailbox' ) 
      EQUALITY caseIgnoreIA5Match                
      SUBSTR caseIgnoreIA5SubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

It is noted that the directory will not ensure that values of this
attribute conform to the Mailbox production [RFC2821].  It is the
application's responsibility to ensure that the addresses
it stores in this attribute are appropriately represented.

Additionally, the directory will compare values per the matching
rules named in the above attribute type description.  As these rules
differ from rules which normally apply to Mailbox comparisons,
operational issues may arise.  For example, the assertion
(mail=joe@example.com) will match mail value JOE@example.com even
though the local parts differ.  Also, where a user has two mailboxes
which whose addresses differ only by case of the local-part, both
cannot be listed as values of the user's mail attribute as they are
considered to be same by the mail attribute's equality matching rule.

     This is a slightly edited variant of the replacement text Kurt
     suggested. I did remove a reference to IDNA since I don't think
     it is appropriate to refer to that prior to there being a
     specification on how IDN is to be used in email.

(14) I question the utility of "otherMailbox" specified in section 3.21.
     Without knowing the other mail system involved it is difficult to see
     how this could be used in a consistent fashion. One way to solve this
     would be to suggest that the original-receipient-address production
     from RFC 3461 be used. This production includes an address type
     label. Additional labels can be registered for "other" mail systems.
     (A label and syntax is already registered for X.400, I believe.)

(15) It is probably too late to change, but it would definitely be
     useful for "uniqueIdentifier" be single valued. (Failing that, a
     single value "reallyUniqueIdentifier" attribute would be useful...)

(16) Section 3.28 "usage od this" -> "usage of this".

(17) The various object classes defined in section 4 refer to all sorts of
     attributes that aren't defined in this document, e.g.
     facsimileTelephoneNumber. Why weren't these attributes included in this
     document? The rules for inclusion or exclusion of various attributes
     seem obscure at best here.

(18) The "rFC822LocalPart" object class is incredibly poorly named.

(19) Is the "room" object class intended to specify an office location or
     something similar? Or does it not belong in a user schema specification?

(20) Reference to RFC 822 should be changed to 2821.

				Ned