On Sep 10, 2009, at 12:23 PM, J. Bruce Fields wrote:
On Thu, Sep 10, 2009 at 12:14:27PM -0400, Chuck Lever wrote:
On Sep 10, 2009, at 11:03 AM, J. Bruce Fields wrote:
On Wed, Sep 09, 2009 at 06:18:11PM -0400, Chuck Lever wrote:
IDNs are UTF16. /var therefore has to support UTF16 filenames;
either
byte in a double-byte character can be '/' or '\0'. That means the
underlying fs implementation has to support UTF16 (FAT32 anyone?),
and
the system's locale has to be configured correctly. If we decide
not to
depend on the file system to support UTF16 filenames, then statd
has
to
be intelligent enough to figure out how to deal with converting
UTF16
hostnames before storing them as filenames. Then, we have to teach
matchhostname() and friends how to deal with double-byte character
strings...
Googling around.... Is this accurate?:
http://en.wikipedia.org/wiki/Internationalized_domain_name
That makes it sound like domain names are staying ascii, and they're
just adding something on top to allow encoding unicode using ascii,
which may optionally be used by applications.
There is a mechanism that provides an ASCII-ized version of domain
names
that may contain non-ASCII characters, expressly for applications
that
need to perform DNS queries but can't be easily converted to handle
double-byte character strings. This can be adapted for statd,
though I'm
not sure if the converted ASCII version of such names specifically
exclude '/'.
Internationalized domain names themselves are still expressed in
UTF16,
as far as I understand it.
From a quick skim of http://www.ietf.org/rfc/rfc3490.txt, it appears
to
me that protocols (at the very least, any preexisting protocols) are
all
expected to use the ascii representation on the wire, and that the
translation to unicode is meant by use for applications.
So in our case we'd continue to expect ascii domain names on the wire,
and I believe that's also what we should store in any database. But
if
someone were to write a gui administrative interface to that data, for
example, they might choose to use idna for display.
That's a reasonable and specific objection to my claim that our
current host record storage format is inadequate to support IDNA.
I've also confirmed that ToAscii with the UseSTD3ASCIIRules flag set
is not supposed to generate a domain label string with a '/' in it.
My remaining concern here is that we could possibly see hostnames that
are too long to be stored in directory entries of some file systems,
especially considering that the ASCII-fied Unicode names will be
longer than typical ASCII names we normally encounter today.
What about multi-homed host support? The same mon_name can be used
with more than one my_name, for multi-homed hosts. Using the current
on-disk scheme, statd turns that SM_MON request into a no-op. So
additional records for the same hostname can't be stored, or we have
to resort to adding multiple lines in the same file. This is possible
to do with just POSIX file system calls, but it does add complexity to
manage several lines in each hostname file without increasing the risk
of corruption if a file update (especially the deletion of one record
in the middle) is interrupted.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
