Re: [I18nrp] Additional input needed for i18nRP BOF

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

Two very quick observations and then I need some sleep...

(1) This discussion and some of its examples are, IMO, getting
very far into solution space including examples and
categorizations that may not be as convincing as they look at
first glance.  Or not, but it is probably worth being aware of
the risk.

(2) It seems to me that, very crudely, there are two rather
different types of documents of interest.   One, which seems to
have been dominating the discussion, is a protocol or other spec
for which i18n issues are incidental or only part of the story
and that requires that they be checked for having been
competently addressed.  The other is an actual i18n spec.  So,
as an exercise for those designing solutions, consider 
   draft-klensin-idna-5892upd-unicode70
   and   
   draft-klensin-idna-rfc5891bis

and how the proposed solutions would work for them.

Procedural issues aside, the first of these, in its most recent
posted form (-05) is essentially an informational document
describing a problem or closely-related set of problems.  Noting
that there are almost certainly recognized i18n experts who
believe that document is much ado about nothing and/or that it
would be irrelevant if the IETF were willing to apply an
additional constraint or two, how would one evaluate and reach
consensus about that document so a descendent of it could be
published as an IETF specification?  And, assuming it is
necessary, how would one develop solutions to the issues it
identifies.

Similarly, the second is essentially a clarification of a policy
matter (not, in the usual sense, a technical or engineering one)
in the basic IDNA2008 specifications.  How would the sort of
Directorate that is being proposed go about determining that it
is actually a clarification, rather than specifying new things,
and then determining whether the policies being clarified and
emphasized are what the IETF should be standing behind.

Nothing above makes the Directorate idea(s) and their
refinements any less useful for the family of documents people
have been talking about in this thread.  But let's not fall into
the trap of solving the easier problem and pretending that the
other one(s) don't exist.

best,
   john