Subject: RE: [nfsv4] Stringprep Compares

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 17 Mar 2005 11:38:51 -0500

Jim Rees says:
> Nico thinks link text should be opaque, 

Sometimes I agree with him.  I keep going back and forth on this issue,
since there are benefits and detriments either way.  

However, as you point out:

> but the spec currently says it's UTF-8,

Right, but to explain the underlying basis for my fear (or maybe that is
too strong, sense of unease, perhaps), let's consider some facts.

a) The spec says the server should check symlinks (at CREATE) for 
   matching the UTF-8 definition, and return INVAL if not valid.

b) I don't do that yet and I don't know of any server that does, so
   I worry that we are not in a position to actually understand the
   consequences.

c) Although this discussion may change that, people are surprised
   when (a) is pointed out, suggesting that there has not been a 
   lot of attention to this issue.

d) All the API's out there that I know about assume that symlinks are
   opaque, and the spec is ambivalent, both saying that they are opaque
   and that they are UTF-8.  

As an example, I had been working on internationalization support 
including interaction with v2v3, CIFS, etc. and then someone asked
about symlinks, and I went to the spec and was astonished to find
that I had ignored them.  I concluded that I would have to take
v2v3 symlinks stored as opaque and convert them to UTF-8 assuming 
that they were stored in the volume's current language.  Conversely,
v4 symlinks would have to have the reverse translation to the native 
v2v3 language setting.  Also, you have to deal with the cases where 
such translation cannot be done.  The result is that you have to 
distinguish on disk between symlinks created by v2v3 and by v4
(and deal with revert issues).  And I didn't realize any of this
until someone innocently asked, "Hey, what about symlinks.  Are 
they UTF-8 in v4?"  To which my response was something like, "They're
opaque, see here in the spec, oh shit".  I'm just thankful CIFS
doesn't have its own symlink format.

> and as Dave pointed out, stringprep is already defined.

It may be defined but the consequences are not clear at all.

The first issue is this whole "character repertoire" thing.  Is
the server supposed to go beyond checking for UTF-8 format and 
check that the characters themselves are in some specified 
character repertoire.  The spec does not say so explicitly.  
There is a mention of checking characters for those that the
server supports and returning BADCHAR if not.  Note that that
the texts talks about characters "that are not supported by
the server as a value for that string".  I would expect that 
for symlinks (as opposed perhaps to filenames), servers will
support the entire character range (0-0x7fffffff), in the 
interests of a greater approximation to the opacity that the
world in general assumes about symlinks.

> Normalization will be too if we fix the spec.

The spec says that in v4.0 normalization is not defined and that it may
be in a future revision, so if people want this to be in v4.1, I think
they'd better get busy and submit an I-D.

Or are people supposing that this can be changed/fixed in v4.0?  I
don't see how.  It may be a mistake (I don't know if it is), but it
is not an erratum.

In that context, I would oppose any normalization form requirement
for the text of symlinks, precisely because making it UTF-8 is as
far along the non-opacity route as I think we should go.  In the case
of filenames, there is an argument that since we can have two different
UTF-8 strings that are "the same" (according to a particular definition
of "the same"), we need normalization to help us deal with the issue
of a many-to-one mapping (I take it that that is Nico's point).  But
as far as symlinks, the filesystem does not ever compare them or do
anything except store them.  Imposing a normalization form on them 
would be almost like imposing a normalization form on the data people 
store.  I know that we have imposed the UTF-8 requirement on symlinks
already but that doesn't to me seem like a precedent to go farther.  
I'm ambivalent about the UTF-8 restriction for symlinks, but am really
against any further restrictions.

> So I don't think we need any extra changes for symlinks.  

You think we don't need any "extra changes" for symlinks.

I don't think we need we need any changes for symlinks at all.  Let's
learn to live with the big change of making them UTF-8 before we go any
further.
 
> I'm not sure why Dave is so afraid.  Existing symlinks are no scarier 
> than existing non-utf file name components.

And no less scary :-)

I think the real difference is that everybody out there assumes that 
symlinks are like file data (store what you want, we don't look at or
interpret it), and the spec, while paying homage to that view, makes
them
non-opaque, and that conflict is a signal to me that there are going 
to be lots of tiny ugly little details for implementers to worry about.

For filenames, everybody understands that this is fs metadata, so people
by and large have had an opportunity to think about the consequences.
That's a decision we made with our eyes open while for symlinks, it 
looks like we were dozing off after pulling an all-nighter.  That
doesn't
mean we'll have a bad result in the latter case, but it is what makes
me anxious about this whole area.

-----Original Message-----
From: Jim Rees [mailto:[email-masked]] 
Sent: Thursday, March 17, 2005 7:11 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] Stringprep Compares 

Nico thinks link text should be opaque, but the spec currently says it's
utf-8, and as Dave pointed out, stringprep is already defined.
Normalization will be too if we fix the spec.

So I don't think we need any extra changes for symlinks.  I'm not sure
why
Dave is so afraid.  Existing symlinks are no scarier than existing
non-utf
file name components.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 17 Mar 2005 13:09:13 -0500

> since there are benefits and detriments either way.  

Don't I need to be able to use symlinks to store paths that traverse
(non-NFSv4) filesystems that permit non-UTF8 component names?

--b.