Re: [nfsv4] [RFD] How to interpret empty path components in fs_locations/fs_locations_info

>      1. The server may specify a 'pathname4' entry with no components
>      2. The server may specify a 'pathname4' with a single component
of
>         length 0.

> The following question then arose: if we allow representations 
> of type 2. above, then presumably we must also allow for the fact 
> that the server may embed zero-length components anywhere in the 
> 'pathname4' array. 

Why do you presume that?

I guess it is the only way you can make representation 2 appear logical.

I just don't think that representation 2 is logical.  Representation 1
makes the most sense having more than one representation for the same
thing does not really make sense.

But we have a practical problem, in that some servers generate
representation 2 and it doesn't seem fair at this point to reject what
they are sending if we can figure out what was intended.  The spec
didn't tell them to do something else.

So I think it makes sense to say:

     you SHOULD send representation 1.
     you MAY send representation 2.
     you MUST NOT send a pathname4 with a zero-length component 
         unless it is an instance of representation 2.

     you MUST accept representation 1.
     you SHOULD accept representation 2.
     you MUST reject a pathname 4 with a zero-length component
         unless it is an instance of representation 2. 

-----Original Message-----
From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
Of Trond Myklebust
Sent: Tuesday, October 19, 2010 5:25 PM
To: nfsv4@ietf.org
Subject: [nfsv4] [RFD] How to interpret empty path components in
fs_locations/fs_locations_info

Hi,

An issue was raised in the fedfs concall last week concerning how to
represent the root directory in fs_locations/fs_locations_info.

As near as the group on the call could determine, there are 2 possible
representations, neither of which appear to be explicitly forbidden by
the spec:

     1. The server may specify a 'pathname4' entry with no components
     2. The server may specify a 'pathname4' with a single component of
        length 0.

The following question then arose: if we allow representations of type
2. above, then presumably we must also allow for the fact that the
server may embed zero-length components anywhere in the 'pathname4'
array. We assume that the interpretation would then be the same as a
POSIX path of the form /a/b/////c (i.e. the path should be interpreted
as equivalent to /a/b/c)?

The question we'd like to put to the list is therefore whether or not
clients should be required to deal with this, or whether the spec should
be amended to discourage (or even forbid) servers from using this kind
of representation for a path?

Cheers
  Trond

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4