[Date Prev][Date Next]
Re: Syntax open issues
My comments are in-line marked "KLD:".
"Kurt D. Zeilenga" wrote:
> Kathy listed a number of "topics yet to be addressed". My comments:
> > Paragraph 2.2.3 - Should attribute syntaxes be allowed to be referenced
> > by a common name, and if so, where should the name come from? An
> > optional NAME has been added to the BNF for SyntaxDescription in
> > paragraph 2.2.4.
> I posted a separate message regarding this issue.
> > Paragraph 2.2.3 - Should any syntaxes listed in the table be removed?
> For clarity, I suggest only those syntaxes which are (fully)
> specified in the I-D be listed.
KLD: It is ok to have only the fully specified syntaxes in the table.
However, I think there should be an annex documenting the complete
list of Syntax OIDs.
> > Should any new syntaxes be added?
> In general, no. Syntaxes are features. We cannot add new features.
> > How does the data model draft <draft-wahl-ladpv3-defns-00.txt> affect
> > this draft?
> In short, it doesn't. The yet to be produced "LDAP Overview /
> Data Model" I-D might, that depends on what this I-D ends up
> looking like.
> > Section 3 - Should all listed syntaxes from paragraph 2.2.3 be
> > detailed in this section?
> The table should be trimmed to just those syntaxes which are
> specified in the "core" specification. We must avoid adding
> new syntaxes (syntaxes are features).
> I note as well that we need to trim some of the syntaxes, in
> particular X.509 certificate syntaxes, which were specified in
> rfc2252 for specification and/or implementation report issues.
KLD: The problem with deleting the X.509 certificate syntaxes is that
it gives the impression that LDAPv3 is not as capable as LDAPv2.
Deletion also indicates that these attributes and syntaxes are
not important. Considering that LDAP implementations of the
X.509 certificate attributes already exist, I believe that there
would be a proliferation of non-standard mechanisms for carrying
the X.509 certificate attributes in LDAP. At least keep the
capability to exchange certificates as encapsulated "binary". A
a better string encoding can be added later.
> > Section 6 - Recognized list of Object classes needs to be reconciled
> > with updated RFC 2256 and the data model draft.
> I am not sure what list you are referring to.
KLD: The "list" is just the object classes specified in the I-D.
> > Section 7 - Proper security statement needs to be formulated.
KLD: Help is needed on this one.