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

[David Noveck <[e-mail]>]

On Tue, Jun 9, 2020, 1:05 PM Nico Williams <[e-mail]> wrote:

> On Tue, Jun 02, 2020 at 08:40:03AM -0400, David Noveck wrote:
> > On Tue, Jun 2, 2020 at 2:07 AM Nico Williams <[e-mail]>
> wrote:
> > > I have reviewed draft-dnoveck-nfsv4-internationalization.
> >
> > Thanks.
>
> 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.


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

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.

>
> > > However, there is an important, long-running, low-volume debate to
> > > finally settle here, and it has to be settled in the I18N community.
> >
> > Fair enough, but I worry about the prospect of turning a long-running
> > 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.
>

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.

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

>
> > > 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_.
> >
> > I agree.


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

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.

>
> If at the end of that robust debate, you and I are left on the rough
> 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,
> it would be a mostly academic and mostly inconsequential mistake: no
> implementor, but no implementor, would actually do what would be asked
> of them.
>

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.

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



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

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.


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

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. :-)

   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,


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

c) doing I18N at
> the VFS precludes form-preserving and form-insensitive behavior.
>
> That would suck.


> A VFS could implement normalize-on-{CREATE, LOOKUP} for I18N-unaware
> 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
> 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.


Yes.


> Instead we can get NFSv4 implementors to "certify"
> I18N compliance when used with I18N-aware filesystems that comply with
> our guidance.
>

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

>
> This cardinality analysis shows it's not appropriate to put the burden
> of filesystem I18N above the VFS.
>
> > 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 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.
>

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

>
> It's also clearly not true that we lack sufficient filesystem
> experience.  Clearly NFSv4 WG participants have that experience.


True but they seem to lack interest in the matter.

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.
>
> I'm not seeing the problem you do.


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

Then you can't succeed.


> 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.
>
>
Or not (more likely).


> > > 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.
>
> So far since my review there's been no pushback.
>

Until now.

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

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.

>
> > > 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.
> >
> > I don't have a problem with the length of this post.   However, it will
> > take a while to respond to most of it.
>
> I was concerned about others' time.


Understood but the problem is it is now even longer.


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

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


> Any attempt to create a third category will be the sort that least to
> enormous threads on [e-mail], 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.
>

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.

>
> > 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.
>
> Oof, I certainly don't mean to accuse or personalize!  Did my language
> 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.


>
> It is true though that the language of the I-D you wrote feels -to me-
> tortured.  You might call that an accusation,


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


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

OK.

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

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.

>
> > 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.
>
> See above.
>

We just differ on this.


>
> > > 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").
>
> We first had this argument back in... 2008?  A dozen years ago?  I don't
> 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.


> Nico
> --MN p
>