[I18ndir] I18NDIR advice and process (was: Re: I18ndir last call review of draft-ietf-regext-dnrd-objects-mapping-06)

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

--On Friday, March 6, 2020 13:14 -0600 Pete Resnick
<[e-mail]> wrote:

> On 6 Mar 2020, at 12:39, John C Klensin wrote:
> 
>> So it seems clear to me, if only from this issue and the UTF-8
>> one, that the document needs work and that it is possible that
>> some of that work will be significant enough that another Last
>> Call will be needed.
> 
> Please let's keep comments about how an AD or Chair should run
> the IETF process off of this list and instead take it to
> private email (if at all). This discussion should be limited
> to the technical comments on problems in documents. The only
> process discussion on this list should be about how the
> directorate do things.

Sorry, Pete, even if its form was not ideal from your point of
view, that was a suggestion about how the directorate does
things.  The directorate is supposed to give advice to the ART
ADs on how to make progress on i18n topics.  The advice I am
giving (or, if you prefer and are actually going to organize and
moderate discussions as I understood you were tasked to do and
have promised to do, a suggestion I am making to i18ndir for a
recommendation to the AD(s) is:

(1) This document, in its current form, is not ready for a
document action and publication as a Proposed Standard.  That
recommendation is perfectly appropriate as part of a document
review.  If it is not, I've lost sight of what IETF Last Calls
are supposed to be about. 

(2) The work required to fix it will probably result in
sufficiently substantive changes that it will be necessary for
the WG to be consulted -or- will require the WG to make some
substantive decisions.  For example, while my opinion (and that
of Scott and Asmus) that some additional references and
explanation of what was intended to appear in various strings
may fall into the range of fixes that are often specified by the
IESG for the authors and/or RFC Editor to sort out, a change to
require UTF-8 is substantive enough that anyone who thinks
UTF-16 (or for that matter, UTF-32 or UTF-7) is an important
enough option to justify retaining should have a chance to weigh
in on that decision.  Alerting the AD and IESG to that seems
completely orderly and a reasonable part of a Last Call review,
whether by the directorate or by an individual.

(3) When a Last Call review raises substantive issues that
involve specialized knowledge, some complexity, or both, there
are two ways to write that review and proceed.  One is to
explain the problem, the specialized knowledge, and the
alternatives in sufficient detail that authors or a WG can go
off and do the right thing.  This stuff is not obvious: I've
learned things from Asmus, Marc, and Scott today.  I would like
to at least hope that they have learned a bit from me and that
those who have been lurking have learned from all of us.  The
second option is to explain the problem sufficiently to make it
clear to the WG and the IESG that there _is_ a problem, then
volunteer to the WG to work with them to develop a solution.
Usually the latter is likely to be more efficient and is
appreciated.  I can remember reviews and discussions over the
years in which that approach has been taken and WG Chairs and
ADs have thanked me for being willing to step in and volunteer.
My memory might be playing tricks, but I vaguely remember having
just such interactions with some Apps AD in the 2011-2015 period
whom you presumably know fairly well.    So I suggest that part
of that advice was just a variation on "not ready for
publication" and the other part was suggesting a way to move
forward.  Either would be appropriate in a review; either would
be appropriate as advice for the directorate to give the AD(s).

(4) At least from my perspective, looking at this document (and
several others, but we haven't talked about them this week) has
suggested that it may be time to update the advice the IETF
gives document authors about i18n issues.  That might possibly
including revising/ updating BCP 18/ RFC 2277 to make a clear
recommendation to use UTF-8 and to reinforce the RFC 2277
requirement that UTF-8 is  mandatory to implement, to justify
any other options, and to make some suggestions about when
normalization (in the Unicode sense) is appropriate and/or to
discuss the tradeoffs.  The days when it was desirable to
encourage individual clients and servers to make their own
choices of CCS or charset, including as possibilities selected
parts of ISO 8859, assorted proprietary code pages (with or
without ISO 2022-based switching), and selected national
standards is long past. I note on rereading 2277 that use of any
other encoding scheme instead of UTF-8 is a sufficiently big
deal as to require a variance procedure, a policy that has not
been followed but which would lay a foundation for sorting some
of these issues out by appeals if we cannot devise a more
appropriate and orderly mechanism.   If it is now time, that is
appropriate advice to get the ADs.  If it is not time but we see
the time coming soon, _that_ is appropriate advice  to give the
ADs.  So the only problem I can see with that part of the
discussion is if you believe that the directorate is only
allowed to examine topics that you assign to it.  If you do,
then I think we are overdue for a discussion about how, in your
words, the directorate does things.

So, can you better explain what problem you see with the
discussion and recommendations -either to the AD or to the
directorate to recommend to the AD- so I can better understand
what I'm forbidden to say and why?

thanks,
   john