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

> >      you MUST reject a pathname 4 with a zero-length component
> >          unless it is an instance of representation 2. 
>
> I'm not sure I agree with this. If a client is given a crazy 
> pathname by the server, through an fs_locations request, but 
> it still manages to make sense of it, then why shouldn't it 
> make the attempt? The alternative would be to tell the application 
> 'EIO'... 

Note that the third point which you agreed says you MUST NOT send
something like that.  If someone sends me something that the spec says
he MUST NOT, I feel that the best thing to do is to reject it.
Otherwise, you the spec has to decide what this thing that it has
defined as not valid means, and why bother doing that.

-----Original Message-----
From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] 
Sent: Thursday, October 21, 2010 3:33 PM
To: Noveck, David
Cc: nfsv4@ietf.org
Subject: RE: [nfsv4] [RFD] How to interpret empty path components in
fs_locations/fs_locations_info

On Tue, 2010-10-19 at 21:08 -0400, david.noveck@emc.com wrote:
> >      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.

Agreed.

>      you MUST accept representation 1.
>      you SHOULD accept representation 2.

Agreed

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

I'm not sure I agree with this. If a client is given a crazy pathname by
the server, through an fs_locations request, but it still manages to
make sense of it, then why shouldn't it make the attempt? The
alternative would be to tell the application 'EIO'...

Cheers
  Trond

> -----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
> 