[nfsv4] [FedFS] Empty fedfsNcePrefix attributes

[Chuck Lever <[e-mail]>]

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.

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?

-- 
chuck[dot]lever[at]oracle[dot]come