[nfsv4] Follow-up re draft-dnoveck-nfsv4-internationalization-00

[David Noveck <[e-mail]>]

I've been looking at the changes needed to avoid normatively referencing
obsolete RFCs and think I have a good shot at doing so, but I need to get
information about how current implementations deal with internationalized
domain names.

The problem is that RFC 7530 was written to conform to IDNA 2003 while any
new document would need to conform to IDNA 2008, whose rules are more
complicated.  This.sounds daunting, but actually it isn't.  The more
complicated rules have resulted in the spec limiting the set of actors who
must check them, or fix up non-conforming names to be conforming without
adversely affecting the user, essentially avoiding the need for us to
understand whether the strings we deal with are IDNA-compliant.

It looks pretty simple to get to a reasonable -01 by deleting a lot of IDNA
2003 wordage.   However, the potential problem is the possibility that
existing implementations might have followed the treatment in Section 12.6
of RFC 7530, potentially creating interoperability issues.

My guess is that nobody did that but it would help to get the input of
people familiar with the implementations.  Specifically what I need to know
is:

   - Does the implementation treat any character other than 0x2c aka FULL
   STOP as a domain separator? Specifically I'm worried about FULLWIDTH FULL
   STOP, IDEOGRAPHIC FULL STOP, or HALFWIDTH IDEOGRAPHIC FULL STOP, all of
   which RFC 3490 (now obsolete) says "MUST" be recognized as domain
   separators.


   - Does the implementation check domain names for IDNA compliance
   including checks for normalization form, BIDI violations, unassigned or
   otherwise inappropriate (according to IDNA) code points, or length?


   - If it does do such checks and they fail, what does it do?  Does it
   ever revise the domain name as Section 12.6 suggests it might/should?


Also, do any servers accept the Punycode equivalent of internationalized
names as section 12.6 says they SHOULD?