Re: [nfsv4] [FedFS] Empty fedfsNcePrefix attributes

[James Lentini <[e-mail]>]

On Wed, 14 Jul 2010, Chuck Lever wrote:

> Section 4.1 of the latest FedFS protocol draft:
> 
>   http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-06
> 
> states that
> 
> > The naming context’s root entry MUST include the
> > fedfsNsdbContainerInfo (defined below) as one of its object
> > classes. The fedfsNsdbContainerInfo’s fedfsNcePrefix attribute
> > is used to locate the naming context’s NCE.
> 
> and that
> 
> > A fedfsNsdbContainerInfo’s fedfsNcePrefix attribute contains a
> > string. Prepending this string to the namingContext value produces
> > the Distinguished Name (DN) of the NSDB Container Entry. An empty
> > fedfsNcePrefix string value indicates that the NSDB Container Entry
> > is the namingContext’s root entry.
> 
> However, the fedfsNcePrefix attribute is defined thusly:
> 
> > 4.2.1.7.  fedfsNcePrefix
> >    A fedfsNcePrefix stores a UTF-8 encoded string.
> >    This attribute is single-valued.
> >    <CODE BEGINS>
> >            ///
> >            /// attributetype (
> >            ///     1.3.6.1.4.1.31103.1.7 NAME ’fedfsNcePrefix’
> >            ///     DESC ’NCE prefix’
> >            ///     SUP name
> >            ///     SINGLE-VALUE
> >            ///     )
> >            ///
> >    <CODE ENDS>
> >    OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517].
> 
> On my 389-ds server, "SUP name" is actually OID 121.1.15, not 121.1.12.

The last line of text is referring to the DN syntax, 
which is OID 1.3.6.1.4.1.1466.115.121.1.12. 

The intention was for the fedfsNcePrefix attribute to use the DN 
syntax, which felt like the appropriate syntax to use.

Unfortunately, it looks like I neglected to fully update the text to 
use the DN syntax, including the fedfsNcePrefix's LDAP schema 
definition as you've pointed out. I blame xml2rfc :)

The intention was to define the fedfsNcePrefix as follows:

attributetype (
    1.3.6.1.4.1.31103.1.7 NAME 'fedfsNcePrefix'
    DESC 'NCE prefix'
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE
    )

I believe this is a better definition as it constrains the contents of 
a fedfsNcePrefix to DNs, but I'd appreciate feedback from those with 
more LDAP expertise.

We'll correct this one way or the other in the next update. Thank you 
for spotting it.

> However it's defined, it appears that a string type attribute does not allow
> its value to be an empty string.  I have not found a way to insert a
> fedfsNcePrefix attribute with the value of an empty string into my 389-ds
> instance.  (admittedly I'm an amateur, but...)
> 
> I found this e-mail from November of 2002:
> 
>   http://www.openldap.org/lists/openldap-devel/200211/msg00059.html
> 
> wherein Kurt Zeilenga claims that a directory string can never be empty, and
> that OpenLDAP (unclear whether he is referring to the client library or the
> server) treats all strings as directory strings.
> 
> Is specifying an empty string value as the fedfsNcePrefix well supported by
> all known LDAP implementations?

The intention was to define the fedfsNcePrefix with the DN syntax 
which can contain an empty value (at least in my OpenLDAP config). 

-james