Re: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)

[Chuck Lever <[e-mail]>]

On Nov 4, 2010, at 2:49 PM, James Lentini wrote:

> 
> 
> On Thu, 4 Nov 2010, Chuck Lever wrote:
> 
>> 
>> On Oct 22, 2010, at 1:31 PM, James Lentini wrote:
>> 
> <snip>
>>> 
>>> Revised text for Section 4.2.1.12 
>>> (if fedfsAnnotation is retained):
>>> ------------------------------------------
>>> 
>>> 4.2.1.12. fedfsAnnotation
>>> 
>>> 
>>>  A fedfsAnnotation contains an object annotation formatted as a 
>>>  key/value pair.
>>> 
>>>  This attribute is multi-valued; an object type that permits
>>>  annotations may have any number of annotations per instance.
>>> 
>>>  A fedfsAnnotation attribute is a human-readable UTF-8 string.
>>>  The value MUST NOT contain a non-terminal NUL character and
>> 
>> Rob pointed out to me that UTF-8 strings by definition may not have 
>> a non-terminal NUL character, so the above MUST NOT text is not 
>> necessary.
> 
> Since arriving at this conclusion required some discussion, I think 
> noting this point would be benefit future readers. The "MUST NOT" 
> could be removed like this:
> 
>   A fedfsAnnotation attribute is a human-readable UTF-8 string.
>   By definition, the value will not contain a non-terminal NUL character.
>   The value MUST be formatted according to the following ABNF [RFC 5234]
>   rules:
> 
> Is that better?

"As a UTF-8 string by definition does not contain a non-terminal NUL character, the annotation value (VAL) can never contain a non-terminal NUL character." might be a little more clear for the second sentence.  I do realize this restriction applies for the entire fedfsAnnotation value, but my issue was specifically around what the intended payload of VAL might contain.

I still might wish for a fedfsAnnotation format that was less sloppy (ie, easier to parse without worrying about white space variations).  Is there any reason to allow such flexibility?

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