Subject: [nfsv4] Part of open issue NSDB-5: storing pathnames as an XDR blob

From: Chuck Lever <[email-masked]>
Date: Mon, 20 Aug 2012 14:03:32 -0400

I believe this to be the last known open issue for the NSDB protocol draft.  In this e-mail, dated April 16, 2012:

 http://www.ietf.org/mail-archive/web/nfsv4/current/msg10851.html

Howard Chu comments:

> 4.2.1.14
>   XDR blobs? Really?

Section 4.2.1.14 describes the fedfsNfsPath attribute, part of the NFS-specific subclass of FSL record types.  The value of this attribute is converted by file servers into part of an fs_locations4 or fs_locations_info4 response.  It is stored in LDAP as a binary single-valued attribute.

Since the content is already XDR-encoded, file servers don't need to unmarshal and re-encode this value when responding to a referral.  In addition, LDAP does not have a type that represents an ordered list of UTF-8 strings, so encoding of some kind is required for this data item.

However, these blobs are not human-readable when stored in LDAP, and are not friendly for script-based LDAP clients.  We are interested in providing simple mechanisms for editing and updating FedFS content stored in LDAP.  An XDR blob is not simple to view or modify with typical LDAP tools.

I propose changing this attribute to contain something that is friendlier to LDAP, scripting, and humans.  Here are three options for replacing fedfsNfsPath:

1.  Store a single UTF-8 string that represents the whole pathname.  Store the pathname separator in a separate attribute.

2.  Store the pathname as file: URL.  This is a US-ASCII string with standard escaping mechanisms for representing UTF-8 and alternate separator characters.

3.  Replace fedfsNfsPath, fedfsFslHost, and fedfsFslPort with a single attribute that stores the location as an NFS URL.  This is a US-ASCII string with strict code point conversion rules and standard escaping mechanisms that can represent all three items in a single human-readable and easily editable attribute.

To garner feedback from people who know from LDAP, I've discussed these options on the [email-masked] mailing list.  The LDAP folks prefer option 3.

Since we are trying to represent a the universal location of a network-accessible resource, and LDAP in our case is a significant part of the presentation layer of NSDB administrative tools, I have to agree that option 3. has appeal.  I believe we can represent IDNA hostname labels and UTF-8 pathnames using this scheme.

However, we would need to specify the meaning of NFS URLs within the context of NFSv4.  The ancient RFC 2224, which defines the NFS URL format, discusses only legacy versions of NFS.  It may be enough simply to lay out our interpretation of NFS URLs in the NSDB protocol draft.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com