Re: [I18nrp] Additional input needed for i18nRP BOF

[Adam Roach <[e-mail]>]

It seems that these are two very different problems indeed, and probably 
in need of two different solutions. Again, I ask you -- as one of the 
BOF proponents -- to put a concrete suggestion on the table to serve as 
a basis for conversation.

/a

On 6/6/18 11:31 PM, John C Klensin wrote:
> 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
>