Subject: Syntax open issues

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Jun 2001 15:08:51 -0700

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.

>   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.

>   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.

> Section 7 - Proper security statement needs to be formulated.

Yes.

---

From: Kathy Dally <[email-masked]>
Date: Mon, 25 Jun 2001 20:46:36 -0400

Hi All!

My comments are in-line marked "KLD:".

Kathy

> 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.

> In general, no.  Syntaxes are features.  We cannot add new features.
KLD:  Agree!!
> 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.      
> 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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Jun 2001 20:58:00 -0700

I believe that further standardization of X.509 certificate
schema for LDAPv3 is quite important.  In particular, the
X.509 certificate schema needs to get fixed.

The "core" specification also needs to consistently reference
X.500. It needs to reference a single edition, the 2nd.

We should avoid recycling the "core" specification at Proposed
if at all possible.  Fixing the certificate schema or including
material allowing references to multiple X.500 editions will
likely cause recycling.

For these reasons, I suggested removing the broken certificate
schema from the "core" specification and working with PKIX
WG to include fixed certificate schema in their LDAPv3 schema
document.  I have contacted the PKIX'ers and find they are
willing and able to do the necessary schema work as part
of their existing work.

As far as the problem you raise, this can be somewhat
mitigated by stating in the Changes section something like:

  - Certificate schema removed.  Updated certificate
    schema is specified in [insert reference].

Kurt