Subject: [I18ndir] Early review of draft-dnoveck-nfsv4-internationalization-01

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2020 01:07:10 -0500

I have reviewed draft-dnoveck-nfsv4-internationalization.

In my opinion, this draft is extremely important to the Internet
community and beyond, and should progress.  This being an early review,
perhaps I should stop there.

However, there is an important, long-running, low-volume debate to
finally settle here, and it has to be settled in the I18N community.

The architectures and realities of the relevant operating systems makes
it impossible for us to practicably put the onus for I18N on the
filesystem _protocols_.  No, that onus can _only_ live in the
_filesystems_.  I cannot stress this enough.

If you stop reading here, you can take just the above paragraph with you
and consider it carefully.  If you continue reading, please forgive me
for the length of this post.

The document at hand is almost entirely dedicated to convincing the
present audience of the above premise and fact.  Most of the first ten
pages are non-normative text, and when it gets to what happens in
reality... it's essentially still informative rather than normative
text.  The I-D even modifies the meaning of RFC2119 so it can pretend to
be normative while not really being normative, all so it can continue
the fiction that I18N belongs in NFSv4 (and what about WebDAV? and SFTP?
and ...?) and not in the filesystem.

These assertions may cause friction.  Therefore I seek to convince you,
as the author tries as well, but I want to go further: I want to stop
pretending that the filesystem _protocol_ can be responsible for I18N.
Even if this viewpoint ends up on the rough side of consensus, the
running code can. not. change.  Anyone who wishes to argue that we can
only target the protocols and not the filesystems needs to consider this
fact.

The architecture of that running code has been as it is for many decades
-- almost as many decades as there has been an Internet community!

The author gets to the nub of it in section 3, which in pages 5 and 6
says (with marked elisions):

   During the period from the publication of RFC3010 [14] until now, two
   different perspectives with regard to internationalization have been
   held and represented, to varying degrees, in specifications for NFSv4
   minor versions.

   o  The perspective held by NFSv4 implementers treated most aspects of
      internationalization as basically outside the scope of what NFSv4
      client and server implementers could deal with.  This was because
      the POSIX interface treated filenames as uninterpreted strings of
      bytes, ...

   o  Within the IETF in general and in the IESG, there was a feeling
      that new protocols, such as NFSv4, could not avoid dealing with
      internationalization issues, ...

It has now come time to finally settle this debate, these 'different
perspectives'.

The essential detail that we cannot alter is the architecture of most
every general purpose operating system such as Unix, Unix-like
derivatives (e.g., BSD and derivatives), Unix-like non-derivatives
(e.g., Linux), and even Windows, as well as others.  Specifically:

 - there is a pluggable filesystem API -- the virtual filesystem
   switch (VFS);

 - filesystem protocol clients are plugins for the VFS;

 - filesystem protocol servers operate above the VFS;

 - the VFS API, and the SPI that plugins implement, are in the main
   I18N-unaware -- they are just-use-8 (BSD, Linux, Unix) or
   just-use-UTF-16 (I believe Win32 also leaves I18N to the filesystems,
   though I may be wrong about this);

 - the VFS and below are utterly unaware of the locale or even codeset
   used by application clients of that API.

Indeed, on Unix and Unix-like systems, the C library system call stubs,
the system calls themselves, and the entirety of the VFS, treat
filenames and paths as mostly-binary blobs with just two special byte
values: NUL (because these are C strings) and 0x2F (ASCII '/', because
it's the filesystem component separator as there is no array-of-
components representation of paths in the various system calls), and a
few special names in ASCII (e.g., ".", "..").

The kernel side of all of this is even less aware of user-level locale
selection (not. at. all.) than it is of user-level codeset selection
(NULL and / being special and ASCII, so only ASCII and superset codesets
need apply).

That this set of facts is common to such diverse operating systems
should be indicative of how natural this architecture is.  It's really
quite standard to have pluggable interfaces for this sort of
functionality, and it's not at all surprising that software
architectures the evolved in the 1980s didn't account for I18N.

To be sure, there are special-purpose fileservers, of course, and those
might not have a VFS -- who knows what they do.  But that hardly matters
because it suffices that we have decades-long history of VFS
architectures in widespread present use.  That is running code, much,
much running code.

The fact that filesystem protocol servers operate _above_ the VFS
essentially rules out implementation in, e.g., NFSv4 servers, of I18N
behaviors such as:

 - normalize on CREATE

   Sure, NFSv4 servers could, but what about POSIX and WIN32
   applications
   running on the same server?  What about other filesystem protocol
   servers on the same system?  They sure don't and won't, and we can't
   make them do it.

 - preserve form on CREATE and do form-insensitive matching on LOOKUP

   This could be implemented, but conflicts can't be avoided because...
   but what about POSIX and WIN32 applications running on the same
   server?  ... (Ditto.)

 - reject non-Unicode (non-UTF-8 in the case of NFSv4)

   Sure, NFSv4 servers could, but what about POSIX and WIN32
   applications running on the same server?  ... (Ditto.)

   Should NFSv4 servers filter out non-UTF-8 filenames in READDIR??

 - apply specific mappings in case-insensitive filesystems

   (Ditto.)

There's almost no major I18N best practice that an NFSv4 fileserver can
reliably implement on a general-purpose operating system!

Just about the only I18N best practice an NFSv4 fileserver can apply is
to refuse to CREATE new non-UTF-8 filenames.

So why should we have an I18N burden on NFSv4 at all?

If the above is not enough to convince the reader, then what about the
other Internet filesystem protocols, WebDAV and SFTP?

If multiple Internet filesystem protocols can (and they do) co-exist on
the same servers as NFSv4, sharing the same content, how can they have
different I18N requirements and recommendations?  The answer is obvious:
they can't.

And what about non-Internet filesystem protocols, such as:

 - Lustre
 - OpenAFS
 - Auristor
 - CIFS/SMB
 - ...

that also co-exist with Internet filesystem protocols?

We can't advise their designers and implementors, and we can't look to
them to learn from their I18N choices?  Well, we can't impose I18N
requirements on them, no, except by proxy via the Internet filesystem
protocols they also implement (or allow), but again, that just doesn't
work.

And that brings up third-party implementations of Internet filesystem
protocols on general-purpose operating systems.  Those can't possibly
force _our_ I18N values on the platform's native non-Internet filesystem
protocols.  E.g., an SFTP server on Windows co-existing with SMB.

What a mess, no?

But there is a saving grace.

There is one unifying thread: the VFS architecture.  That I18N-unaware
layer above the actual filesystems.  It turns out that this is the key
to the puzzle.

This blissful lack of awareness of I18N at the VFS layer means we can
push I18N all the way down to the filesystem and get good results.  Some
of us reached this conclusion almost twenty years ago, when ZFS
implemented I18N in the filesystem.  Even before that, engineers at
Apple seem to have reached similar conclusions.

In fact, all the problems of filesystem I18N are relatively easy to
address if we push them into the filesystem.  Yes, different filesystem
specifications and implementations may well make different I18N choices
-- they already do anyways, and we can't exactly force them to change.

There are only a few I18N problems to address in the filesystem.  I'll
focus here only on filenames (and pathnames).  We can describe them and
specify solutions as a BCP or even Standard and hopefully those
filesystems that don't yet implement any of these I18N behaviors can get
the hint and start doing so.  These problems are:

 - Unicode equivalence

   There are two approaches in the wild:

    - normalize on CREATE (and typically also LOOKUP)

      HFS+, for example does this.

      HFS+ normalizes to something close to NFD, while input methods
      generally produce sequences closer to NFC, at least for Latin
      scripts anyways.  Other filesystems could well go for NFC, which
      serves to illustrate that there is a variety of I18N behavior in
      the wild.

    - form-preserving on CREATE, form-insensitive on LOOKUP

      ZFS, for example, does this.  Again, diverse I18N behaviors in the
      wild.

   A third and unsatisfying approach is to do nothing.  Naturally we
   would not endorse that approach -- we might not even mention it.

 - Case mappings

   These are only relevant to case-insensitive filesystems.  It is not
   uncommon to have a single server sharing multiple different
   filesystems some of which are case-sensitive, and some of which are
   case-insensitive.

   Here the main problem is that there can be only a single set of
   mappings per-filesystem, and this set of mappings may vary by locale.
   Ergo, each case-sensitive filesystem needs to specify a locale or
   default to a sensible one.

   Note that knowing the locale of user application processes does not
   help here because it is just not possible to have different case
   mappings in the same case-insensitive filesystems for different
   users.

 - What to do about non-Unicode file names

   This is a matter of legacy.  We, the IETF, can say that Internet
   filesystem protocol servers MUST NOT allow the creation of new such
   names, but forbidding such names in the results of listing
   directories is harder.  We can even pretend legacy filesystem content
   does not exist.

   Still, there are only two sensible policies a filesystem might
   implement:

    - forbid non-Unicode;
    - allow non-Unicode, making no attempt to deal with equivalence.

A document that explains all of the above and correctly addresses I18N
requirements mainly at filesystems can be shorter than the document I
just reviewed, and can avoid the uncomfortable attempt at providing
alternate definitions of RFC2119 terms.  Let us do that.  I volunteer to
author or edit such a document if need be.

All that said, there is one way in which I18N does apply specifically to
NFSv4: in non-filename Unicode strings, such as the name@domain
representation of users and groups in access control lists (ACLs).
Fortunately there is no controversy about that, or the choices made in
NFSv4 regarding those, and nothing more need be said about that.

Nico
--

---

From: David Noveck <[email-masked]>
Date: Tue, 2 Jun 2020 08:40:03 -0400

> I have reviewed draft-dnoveck-nfsv4-internationalization.
Thanks.

> perhaps I should stop there.

In any case, you chose not to, which makes sense to me.   I find your
remarks interesting  even if though I do not agree with all of them.

> Fair enough, but I worry about the prospect of turning a long-running
low-volume debate into a long-running high-volume debate.

It would be nice to finally settle this but if it is not settled soon, this
is not going to help me.   Still, you will do what you think is best for
I18N overall and I'll try to adjust.

> filesystem _protocols_.

I agree.

> No, that onus can _only_ live in the
> _filesystems_.

It's been placed on the protocols for a considrable time and the results
have not been all that positive.

Placing it on the filesytems would be an interesting alternative,but
filesystems are not really someting the IETF is charged with
standardizing.    It might be possible to create rules for filesystems used
by internet fileystems protocols and I would support such an effort.

> I cannot stress this enough.
>
> I think you stress it adequately.   Although there may well be resistance
to your views, I'm not sure additional stress on your valid points is the
answer.   I have to object to the word "only" as shared resposibility for
this might be viable approch.

> for the length of this post.

I don't have a problem with the length of this post.   However, it will
take a while to respond to most of it.

> text.

Given the nature of what this document and RFC7530 sought to do, it is
wrong consider "normative" and "informative" as alternatives.   It does not
seek to create norms but presents existing norms so that interoperable
implementations can be created.   These norms are derived from
existing implementations, since there are many implemtation that do not
follow the normative descriptions in RFC3530 and RFC5661 and many that do
follow RFC7530.

The I-D even modifies the meaning of RFC2119 so it can pretend to
> be normative while not really being normative,

The document does not modify the *meanings*  of the terms defined in
RFC2119.

Section 2.1 affirms these meanings and does not appear with fingers
crosed.   Section 2.2 explain how the sttements in this document were
derived and are still compatible with Section 2.1.   This is the same
approach used in RFC7530 and the IESG had no problem with it.

all so it can continue
> the fiction that I18N belongs in NFSv4

I don't see how you can first point out that I agree with you on where
responsibility for this matter is best placed and then accuse (I think that
is the right word) me of collaborating in an effort to impose this supposed
fiction on the internet community.

For the record, while I feel that assigning the responsibility for this to
NFSv4 was a misjudgement that I would prefer to see corrected, there is no
way it can be categorized as a "fiction".  In any case, regardless of where
the responsibility for this matter is best placed, people implementing
NFSv4 clients andservers need reliable guidance of how they (and the
filesystems servers export) need to deal with internationalization issues.

> (and what about WebDAV? and SFTP? and ...?)

What about them?  I don't say anything about them because I don't know
anything about them, and feel it is best to get internationalization for
all minor versions of NFSv4 documented clearly, in order to be compatible
with an eventual rfc5661bis.

> and not in the filesystem.
>

My document does give appropriate attention to the role of the file
system.    While I agree it would probably be better to assign
responsibility in a more formal way, I'm not sure that is possible in a
resaonable time frame.   Note that the milestone for this document is
12/2020 and while that can move if necessary, this is needed for
rfc5661bis (no target date yet, but anything beyond two years might as well
be "never").

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2020 10:37:50 -0500

FYI, I didn't see any instructions for the early review till I hit the
"complete review" button on the datatracker.  There were instructions to
get guidance from Pete R. first.  In particular I missed the desire that
I check whether earlier discussion had been captured in -01 -- I didn't
check for that at all.

Nico
--

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 02 Jun 2020 11:47:36 -0500

> I check whether earlier discussion had been captured in -01 -- I 

If any of the comments posted here earlier weren't captured in Nico's 
review, drop a note to Nico and me. We'll work on getting those 
incorporated and update the review as necessary. I haven't had a chance 
yet to read through the review myself, but I will later today.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Jun 2020 12:04:21 -0500

> > I have reviewed draft-dnoveck-nfsv4-internationalization.

Well, evidently I didn't do what was actually desired.

Thanks.

I could have made even more arguments for why the burden of filesystem
I18N cannot be placed at the edges of the system, but belong only at the
core (either in the VFS or in the filesystem(s)).  Indeed, I will make
those arguments here and later.

> low-volume debate into a long-running high-volume debate.

An important debate that is settled by default rather than by having it,
is not useful to anyone.

> I18N overall and I'll try to adjust.

I understand your take.  Your draft's text drips with the sweat of your
attempt to square a circle.  I believe it's time to stop and rethink.

> > it impossible for us to practicably put the onus for I18N on the

I.e., you only just want to publish, even if it means not acknowledging
reality?

I think we must not do that.  Not without first having a robust debate.

If at the end of that robust debate, you and I are left on the rough
side of consensus, so be it.  To be sure, it would be a serious mistake,
it would be a mostly academic and mostly inconsequential mistake: no
implementor, but no implementor, would actually do what would be asked
of them.

> have not been all that positive.

It's also never really been done there by implementors.

There's a cardinality argument for not pushing filesystem I18N to the
edge I only made half-way earlier:

 - there are N > 1 places above the VFS -- if we're going to put the
   onus of I18N above the VFS, then we must impose the same requirements
   on all N places:

    - NFSv4

    - WebDAV

    - random HTTP servers that serve filesytem content w/o being WebDAV

    - SFTP

    - random non-Internet protocol access methods:

       - POSIX/WIN32 system calls or user-land C (and other) library stubs

       - SMB/CIFS

       - *AFS

       - and many others

   compared to:

 - N == 1 at the VFS

 - N > 1 below the VFS

However, this is not sufficient to recommend implementing I18N at the
VFS because a) some filesystems already implement I18N, b) N need only
be 1 or maybe 2 below the VFS in actual deployments, c) doing I18N at
the VFS precludes form-preserving and form-insensitive behavior.

A VFS could implement normalize-on-{CREATE, LOOKUP} for I18N-unaware
filesystems, and just-use-8 for I18N-aware filesystems so they can
possibly implement form-{preserving, insensitive} behavior.  This is the
best of all worlds, really, though even so, it seems unlikely that we
can get various operating systems implementors to implement that in
their VFS layers.  Instead we can get NFSv4 implementors to "certify"
I18N compliance when used with I18N-aware filesystems that comply with
our guidance.

This cardinality analysis shows it's not appropriate to put the burden
of filesystem I18N above the VFS.

> by internet fileystems protocols and I would support such an effort.

I don't agree.

We can very much publish either an FYI or a BCP, or even an STD,
targeted at filesystem implementors.  Nothing stops us from doing so,
just as we lack a compliance police.

It's also clearly not true that we lack sufficient filesystem
experience.  Clearly NFSv4 WG participants have that experience.  Also,
I do, even if I'm not an active NFSv4 WG participant (and haven't been
for almost a decade).  Also, we don't need to be experts -- we can all
educate ourselves and reason our way out of this paper bag.

More importantly, it is simply impossible to interoperate if different
access methods have conflicting I18N requirements.  This means that even
if we choose to continue with the approach of pushing I18N up the stack,
we can't succeed unless implementors of non-Internet Protocol access
methods agree to be bound by our specifications (or vice-versa).

If skepticism of our ability to address filesystem implementors remains
insurmountable, then we can publish either an FYI or a BCP and not an
STD.  We can then wait some time to gain experience before promoting to
STD.

> this might be viable approch.

So far since my review there's been no pushback.

Regarding "only" -- yes, I18N can be done at the VFS layer (see above).
However, it can't be pushed further up the stack, and my preference is
either a the filesystems do it, or the VFS does it for I18N-unaware
filesystems.

> take a while to respond to most of it.

I was concerned about others' time.

> follow the normative descriptions in RFC3530 and RFC5661 and many that do

I disagree or fail to understand.  We only have normative and
informative language categories.  You imply there is a third
alternative.

Any attempt to create a third category will be the sort that least to
enormous threads on [email-masked], and should be undertaken only with
the understanding that there is that risk, and only because we
absolutely must have a third category.

But what you then describe sounds like "informative" anyways.

At the very least this matter has to be resolved.

> fiction on the internet community.

Oof, I certainly don't mean to accuse or personalize!  Did my language
really come across that way?

It is true though that the language of the I-D you wrote feels -to me-
tortured.  You might call that an accusation, but I think of it as your
being unwilling to have the debate you agree we must settle because,
also as you say, you want to be done.  I don't blame you.  But speaking
for myself, we must have this debate and settle it, and whether we
manage to do so on your schedule or not, is less important to me than
actually getting it done, though I do appreciate your time constraints
and will do my part to get this done in a timely fashion.

To settle this in a timely fashion we'll need the rest of the IETF I18N
community to chime in.

> with an eventual rfc5661bis.

See above.

> rfc5661bis (no target date yet, but anything beyond two years might as well

We first had this argument back in... 2008?  A dozen years ago?  I don't
see a problem with lack of time.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Jun 2020 22:47:51 -0500

FYI, I've begun writing an Internet-Draft targeting publication as a BCP
laying out best practices (using normative language) for filesystems and
remote filesystem protocols like NFSv4.

You can see an early version here:

https://github.com/nicowilliams/ietf-fs-i18n
https://raw.githubusercontent.com/nicowilliams/ietf-fs-i18n/master/fs-i18n.unpg

I'm surprised not to find useful Unicode references in the bibxml
database.  Or maybe I missed them.  Is there a search engine for bibxml?

I spoke to one filesystem protocol implementor who pointed out that
caching clients need to know what I18N functionality (e.g., case-
insensitivity) to apply when using cached directory listings.  Think of
disconnected clients.  I believe this means that we'll need to have
filesystems and servers identify what I18N behaviors the implement, what
Unicode versions they use, and what case mapping tailorings they use (if
any) if they are case-insensitive.  Since we agree that localization
demands such tailorings, possibly on a per-filesystem or per-fileserver
basis, it seems reasonable to have a registry for them with small
identifiers by which to reference tailored case mappings.

Nico
--

---

From: David Noveck <[email-masked]>
Date: Fri, 19 Jun 2020 08:48:35 -0400

> Well, evidently I didn't do what was actually desired.

Well, I wanted an honest review and you gave me that.  However I did expect
something different in that:

   - With regard to the part of the document that essentially generalized
   RFC7530 to apply to multiple minor versions, I wasn't expecting much
   comment and I certainly wasn't anticipating arguments that what I was doing
   was difficult or impossible.  Aftter all, it had already been done in
   RFC7530.
   - With regard to the section that dealt with the IDNA issues, I was
   expecting some comment as to whether I got it right, but I didn't receive
   any.

> those arguments here and later.

Ok, but the vast scope of what you propose to do is troubling to me, since
I was able address the issues for NFSv4.0, to the satisfaction of the
working group, the IESG, and myself, without the major changes you think
necessary.

> An important debate that is settled by default rather than by having it,

A good point but the converse is not necessarily the case.   If you are
debating about the wrong thing, no resolution will be helpful, or stick.

> I understand your take.

I don't think you do.

Your draft's text drips with the sweat of your
> attempt to square a circle.

I did the same thing for NFSv4.0 without all that much sweat in RFC 7530.
Doing the same thing for all of NFSv4 was not  difficult for me and
certainly not impossible as your metaphor suggests.

I believe it's time to stop and rethink.

I don't agree.   If it were necessary to resolve the issues you raise to
address NFSv4 internationalization, then it would have been time to rethink
things just before RFC7530 was published and I don't think it would have
been a good idea to let NFSv4 go so long without a coherent, accurate
discussion of how it dealt with internationalization.

It might have made sense to stop and rethink before the
intenationalization section of RFC3530 was stringprep-ized, but that didn't
happen, alas. At the time the IESG believed it was in possession of the
*truth* about internationalization and was prepared to impose it on working
groups that did not share their view.

> > > it impossible for us to practicably put the onus for I18N on the

Let me qualify that.

I agree that we should not come up with internationalization schemes and
put the onus of conforming to them on the protocols and their implementers.

I don't think it is wrong to have protocol specifications describe how
internationalization is dealt with in a protocol, as was done in RFC7530.

> > I.e., you only just want to publish, even if it means not acknowledging

I do want to publish, and believe that can be done without addressing the
needs of WebDav, SMB, etc.,  I feel the needs of NFSv4 are addressed
realistically.

 If you don't agree, please explain what relavant reality I fail to
acknowledge

> > I think we must not do that.  Not without first having a robust debate.

If you want to have a robust debate, I'm prepared to take part.  However,
I see no clear justification for your belief that I can only do address
internationalization on NFSv4.1 *after* that.
debate is successfully completed.  This seems to me a very unreasonable
position given that RFC7530 satisfactorily dealt with the issue, albeit in
a more limited context.

> side of consensus, so be it.

That would be OK, if publication of draft-ietf-nfsv4-internationalization
and draft-ietf-nfsv4-rfc5661bis is not held up.  I don't see any reason
they should be.

> To be sure, it would be a serious mistake,

That's what happened with the internationalization approach dictated by the
IESG in RFC3530.  Nobody followed it, so that, when we were ready to do the
bis document, we described what actual clients and servers did.

> It's also never really been done there by implementors.

That kind of sucks.  When we had that problem with NFSv4.0, we derived the
internationalization approach from implementations rather than the IESG's
view of what had to be there.

>    on all N places

I don't see the justification for saying you "must" have the same
requirements for all of these.  It is certainly desirable that these be the
same, but in some cases that is simply not possible.  POSIX treats names as
uninterpreted strings of bytes while for others it is a sine qua non that
two canonically equivalent names designate the same file.  There is no set
of requirements that will satisfy everybody.

>     - NFSv4

The prime requirement on NFSv4, which RFC3530 unfortunately ignored, is
that it be compatible with existing filesystems in which internationalized
names might be stored according to a vast number of different encodings, i.
e. That it be interoperable with NFSv3.  Many other protocols might  not
have analogous requirements.

>     - WebDAV

Not sure of its needs.  The treatment of internationalization that I've
been able to find is quite limited.  If you want to address WebDAV's
internationalization, I suggest you discuss that with them and not decide a
p*riori that* they have to be the same as those of NFSv4.

>     - random HTTP servers that serve filesytem content w/o being WebDAV

Random servers probably have random needs, so this seems like a big waste
of time.

>     - SFTP

Haven't looked into this in detail but I expect SFTP and NFSv4 to have
similar needs.

>
>     - random non-Internet protocol access methods

No ability or need for us to address this, which to me is a good thing.

> :

Out of scope for us. POSIX and WIN32 are very different anyway so there is
would clearly be no way to address all of these inthe same fashion anyway.

>        - SMB/CIFS
>
> the big problem with this is case-insensitivity which gets to be a real
drag given the way unicode deal with turkish dotted and dotless i.  i tried
to find out what SMB does about this but I was never able to.

>        - *AFS

No way to impose new requirements on this and have them implemented.

>        - and many others
>
> I hope the set is finite but I can prove it is denumerable. :-)

> VFS because a) some filesystems already implement I18N, b) N need only

be 1 or maybe 2 below the VFS in actual deployments,

I'm not sure we should be making the sort of implementation
recommendations you anticipate.

c) doing I18N at
> That would suck.

> filesystems,

It could and RFC7530 allows that tto be done for NFSv4.0.  Putting it in
the VFS imposes that behavior on everybody, which many might find
inconvenient.

> and just-use-8 for I18N-aware filesystems so they can
> possibly implement form-{preserving, insensitive} behavior.

Another possible RFC7530 choice.

> This is the
> their VFS layers.

Yes.

> Instead we can get NFSv4 implementors to "certify"

Or you can give implementors the valid choices as part of the protocol spec
and dispense with certification and file-system-specific guidance.

> just as we lack a compliance police.

I don't see the point of publishing a standard nobody is going to follow..

> experience.  Clearly NFSv4 WG participants have that experience.

True but they seem to lack interest in the matter.

Also,
> I'm not seeing the problem you do.

> methods agree to be bound by our specifications (or vice-versa).

Then you can't succeed.

> STD.  We can then wait some time to gain experience before promoting to
Or not (more likely).

> So far since my review there's been no pushback.

Until now.

> either a the filesystems do it, or the VFS does it for I18N-unaware

As far as where something should be implemented, it is not your preferences
that matter, reasonable as they are.  this should be up to the
implementers.

> I was concerned about others' time.

Understood but the problem is it is now even longer.

> I disagree or fail to understand.

I think both are the case

We only have normative and
> informative language categories.  You imply there is a third

In this case, we derive what implementations need to do to interoperate
(normative) from the way actual implementations interoperate (descriptive,
informative).

> At the very least this matter has to be resolved.

This was no problem in doing RFC7530, if someone wants to make it a problem
now, they are free to do so, but I'm prepared for that.

> really come across that way?

It does although I accept that it was not your intention.   I see you did
not mean to personalize the issue but feel that when you cast this as a
case of truth vs. fiction, you made that inevitable.   To me, the issue of
how these issues are to be addressed is a matter of judgment and different
people will naturally come to different judgment.   If, on the other hand,
this a matter of truth vs. fiction, those propagating the "fiction" are
inevitably ether culpable or clueless.

> tortured.  You might call that an accusation,

I don't.  I feel it is a misjudgment, though.

> but I think of it as your
> also as you say, you want to be done.

I'm not unwilling to debate.   Also I don't agree to "must settle" but
would agree to "helpful to settle".

> I don't blame you.  But speaking

OK.

> To settle this in a timely fashion we'll need the rest of the IETF I18N

I think it would help to clearly state want you want to do and stick with
it, rather than expanding the scope of the effort as  seems to have
happened here.

> > with an eventual rfc5661bis.

We just differ on this.

> see a problem with lack of time.

I do see lack of time as an issue given the current treatment of
internationalization in RFC5661 is totally wrong and as never been
implented.   It should have been addressed years ago and now needs to be
addressed as part of doing rfc5661bis.

As far as the long-running debate:

   - rfc3530bis was published without resolving this and there is no reason
   rfc5661bis should not be as well.
   - To me, the fact that the debate has gone on over a decade is a sign
   that the wrong thing is being debated.   It is certainly not a
   justification to continue the debate at the same unsatisfactory pace.

> --MN p