Re: [I18ndir] I-D on filesystem I18N

[John C Klensin <[e-mail]>]

--On Tuesday, July 7, 2020 10:05 -0500 Nico Williams
<[e-mail]> wrote:

>...
> For filenames and paths I believe there are only display
> issues.  That was Patrik's point.  Thus the I-D should say as
> much and normatively reference Unicode.
> 
> And yes, the display is absolutely not in scope for an I-D
> that provides advice to designers of filesystem protocols and
> implementors of those and filesystems!  Both of those are far
> from the display action.  And from user input too, for that
> matter.  There is nothing we can say to them that will alter
> anything about input and display.  Therefore it is appropriate
> and correct to leave display (and input) issues out of scope.

See my earlier response to your later note.

>> Priority question: we have a whole series of long-outstanding
>> and core i18n documents more or less in queue with
>> draft-faltstrom-unicode12 (and the now-required
>> draft-faltstrom-unicode13), draft-klensin-idna-rfc5891bis,
>> draft-freytag-troublesome-characters, and some SMTPUTF8
>> ("EAI") tweaks that have not been turned into I-Ds as obvious
>> examples along with, perhaps, draft-sullivan-lucid-prob-stmt,
>> the notorious draft-klensin-idna-5892upd-unicode70, and
>> others.  How do we want to prioritize those probably tedious
>> (but important to make/keep existing standards track specs
>> workping] well) specs versus work relative to Nico's much
>> more exciting file system proposal?
> 
> My I-D is the result of my writing an early review of an
> external I-D that I was assigned by a directorate chair to
> review.  You might even recall pointedly telling me to write
> one if I wanted the issues in question addressed (I already
> had written it, just not submitted it).

I am not objecting to your posting the draft.  I still think
that was a good idea.  When I will have  time to do a careful
review is a separate problem but I note that a quick reading of
parts of it turned up several things I would question.

What I'm concerned about -- and what caused that question about
priorities -- is, at an even higher level, the sort of issue
covered by the note I just sent in response to Patrik's.  With
one qualification below (which I predict you won't like), if the
IESG (via IETF LC), a WG, an AD, or maybe an individual author
who is proposing an update in line with documents that have
already achieved IETF consensus requests a review _from the
directorate_, and Pete assigns that review to someone and they
do it, then that is great.  

The qualification is that, if the review was requested from the
directorate about a document that has been written consistent
with established IETF consensus documents _and_ that does not
reopen or contradict the questions that were presumed to be
settled by that consensus, then that review ought to respond to
the i18n issues raised by the document and suggest issues with
them, not say "well, the whole concept of which the spec under
review is a {proposed) part is broken and I have a better idea".
Should the latter occur, I believe that, if we are really
functioning as a directorate, a second reviewer should
immediately be recruited and assigned to provide the review that
was requested.

Let me give two examples that are more extreme and closer to
home in the hope that they will clarify the point I'm trying to
make: 

(i) Suppose that discussions that are now underway lead to
useful results and we have an rfc5322bis in IETF Last Call.  Now
suppose someone writes a review that says "this whole effort is
a waste of time, traditional name-value pairs are outdated and
take up too much space, and the whole thing should be replaced
by a JSON structure which I am about to propose"   Now, whether
that would be a good idea or not, it would not be a useful
review of a rfc5322bis.

(ii) Even closer to home, suppose that, at some point, revised
documents are prepared to move the IDNA2008 and PRECIS documents
to Internet Standard.   At least the former is widely deployed
and, if we ignore the UTR#46 issues for a moment, demonstrated
to be interoperable.  Now suppose someone writes a review that
says "all of the problems with matching clearly show that the
decision to go to Unicode was nuts and we should go back to ISO
2022 and code pages, a decision that would allow us to encode
and process information on a per script and per language basis
and that would discourage the types of script mixing and
identification of code points as inheriting properties that have
caused so much trouble".   I'd expect such a person to be
treated as nut case, but I'd hope that a serious proposal and
write up and the rationale for it would be considered carefully
and fairly.   But, would it be a useful review of revised and
updated IDNA2008 or PRECIS documents?  Probably not.

So I think "we" owe a more focused review, perhaps modeled on
the comments Asmus and I made early on to that documents, its
author, and the NFS community.

And that brings me back to your draft and the specific issue I
was trying to raise.

>...
> As I understand it, the chairs are currently not available, so
> in further answer to your question, unless we self-organize,
> it may be a few more weeks before we get assignments to review
> the I-Ds you listed.

I'm not interested in reviews in the same sense that we are
reviewing external documents.  I'm interested in efforts closer
to what went into the discussions of draft-faltstrom-unicode11
(and 12) over a year ago, the discussions that resulted in both
RFC 8754 and the update of the IANA tables.  I think those are
fundamentally different from reviews of more external documents.

 
> As to self-organization, I don't mind trading a review of some
> of the above-mentioned I-Ds if that's what it takes to get
> more review of mine.

If I understand you correctly, you are suggesting that your
ideas about an i18n filesystem is sufficiently important that it
justifies pushing existing core i18n specifications, including
the reviews of Unicode 13 (and, to some extent, 12) required by
RFC 8753 aside so we can all work on your document.  I
respectfully disagree and suggest that -- or essentially turning
the directorate into a WG or design team specific to your
document and ideas -- is not a good idea.  I assume we will just
need to agree to disagree about that.

best,
   john