[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Discuss on draft-zeilenga-ldap-user-schema-06.txt
Ned, I hope things are going well with you.
And I am sorry to bother you with this as soon as you
start reading email (but there will probably be lots of
this type of stuff anyway).
This one has been blocking (cause it is normatively
referenced by) draft-ietf-policy-core-schema-16
for more than 6 months now.
There is a new draft-zeilenga-ldap-user-schema-mr-00.txt
document (proper subset, Ted's words) that is the one that
is now needed by the RFC-to-be: draft-ietf-policy-core-schema-16.
Based on the new user-schema-mr doc, I have the following
inline answers below to Ned's Discuss. Let me know if I have any
of that wrong.
But if you look at it, then it seems, to me at least, that Ned
did not have any issues with the (proper subset) that is now
in this new document. Ted wrote to me about that:
> It was carefully written to be a proper subset. The rest of the
> document will probably be withdrawn. I don't think it
> needs another last call. Do you?
> Ted
So IESG, what do we do. Do we need to re-issue a IETF Last Call?
If so, then I would like to see that happen ASAP.
If not, then I think we need to wait for Ned to return without
any actions untill then.
Thanks,
Bert
> -----Original Message-----
> From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
> Sent: woensdag 30 april 2003 9:02
> To: iesg@ietf.org
> Cc: iesg-secretary@ietf.org
> Subject: Discuss on draft-zeilenga-ldap-user-schema-06.txt
>
>
> (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.
>
I still do not see such examples, but is it a real DISCUSS or
a "it would be nice" ??
Besides, there are now no longer any attributes in this new doc.
> (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.
>
The new doc does not have any attributes specified, so I think
this becomes moot.
> (3) It would be enormously helpful if the object classes each
> attribute is
> in were listed as part of the attribute description.
>
The new doc does not have any attributes specified, so I think
this becomes moot.
> (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.
>
I think the new doc does have proper references to all the matching rules
They are all in RFC2252 which is listed as norm ref.
> (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.
>
So now the doc contains just matching rules.
I hope that that is OK.
In fact it is needed by the Policy FW WG document that is blocked.
> (6) The definition of associatedName probably should refer to
> RFC 1279 as well as RFC 1274.
>
Seems no longer relevant to new doc
> (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.
>
Seems moot now that we have no more attributes in the doc
> (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.
>
moot in new doc
> (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.
>
moot in new doc
> (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.
>
moot in new doc
> (11) The "host" attribute specifies "a host computer" in what context?
> Perhaps where the user has an account?
>
moot in new doc
> (12) The "homePostalAddress" and "info" attributes can
> contain multiple lines.
> The correct convention to use for line breaks needs to
> be described.
>
moot in new doc
> (13) Section 3.17 on the "mail" attribute should be changed to read:
>
moot in new doc
> 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.
>
moot in neew doc
> (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.)
>
moot in new doc
> (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...)
>
moot in new doc
> (16) Section 3.28 "usage od this" -> "usage of this".
>
moot in new doc
> (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.
>
moot in new doc
> (18) The "rFC822LocalPart" object class is incredibly poorly named.
>
moot in new doc
> (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?
>
moot in new doc
> (20) Reference to RFC 822 should be changed to 2821.
>
moot in new doc
Bert
> Ned
>