Subject: [I18nrp] Additional input needed for i18nRP BOF

From: Adam Roach <[email-masked]>
Date: Tue, 5 Jun 2018 23:44:33 -0500

On today's BOF approval call, the IESG and IAB had an in-depth 
discussion of the i18nRP BOF proposal. One of the topics that was most 
discussed is a concern that the BOF does not have a clear path to 
success, largely because the proposal has very little discussion of 
proposed potential outcomes. While we do not expect the proponents to 
presuppose an outcome, we believe that achieving a positive outcome 
requires one or more specific proposals to serve as a basis for the 
conversation.

At the same time, the volume of traffic on the IETF mailing list on this 
topic does seem to demonstrate that there is interest in discussing 
topics related to internationalization. The ART area directors have 
therefore provisionally approved the BOF, subject to the proponents 
and/or any other interested parties providing concrete proposals as a 
basis for discussion.

Concretely, this means that the secretariat has been requested to 
schedule a one-hour slot for the Montreal meeting for the proposed BOF. 
If no concrete proposals for procedural approaches to address the issues 
described by the BOF proponents are available by Wednesday, June 13th, 
the secretariat will be requested to remove the BOF from the schedule.

Although it did not come up during the call, I personally wish to point 
out that open-ended brainstorming sessions without concrete proposals 
are typically handled as unofficial side-meetings (either in person or 
virtually). If the BOF proponents wish to maintain the open-ended 
brainstorm session described in the current proposal, the side meeting 
scheduling mechanism remains available; and I would be happy to help out 
should any difficulties occur in using that mechanism.

Please send proposals and any other follow-up messages to [email-masked]

/a

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 6 Jun 2018 06:34:49 +0000

I wish email had a “like” button. Good call. 

Eliot

> On Jun 6, 2018, at 6:45 AM, Adam Roach <[email-masked]> wrote:
> 
> On today's BOF approval call, the IESG and IAB had an in-depth discussion of the i18nRP BOF proposal. One of the topics that was most discussed is a concern that the BOF does not have a clear path to success, largely because the proposal has very little discussion of proposed potential outcomes. While we do not expect the proponents to presuppose an outcome, we believe that achieving a positive outcome requires one or more specific proposals to serve as a basis for the conversation.
> 
> At the same time, the volume of traffic on the IETF mailing list on this topic does seem to demonstrate that there is interest in discussing topics related to internationalization. The ART area directors have therefore provisionally approved the BOF, subject to the proponents and/or any other interested parties providing concrete proposals as a basis for discussion.
> 
> Concretely, this means that the secretariat has been requested to schedule a one-hour slot for the Montreal meeting for the proposed BOF. If no concrete proposals for procedural approaches to address the issues described by the BOF proponents are available by Wednesday, June 13th, the secretariat will be requested to remove the BOF from the schedule.
> 
> Although it did not come up during the call, I personally wish to point out that open-ended brainstorming sessions without concrete proposals are typically handled as unofficial side-meetings (either in person or virtually). If the BOF proponents wish to maintain the open-ended brainstorm session described in the current proposal, the side meeting scheduling mechanism remains available; and I would be happy to help out should any difficulties occur in using that mechanism.
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jun 2018 09:58:58 -0400

Adam,

I had hoped to see an open discussion in the weeks between now
and the start of the IETF meeting but, while I have some ideas,
the absence of specific proposals in the BOF proposal was
deliberate.   

As we know from many previous discussions, including earlier
threads in this one, this is an area in which tempers tend to
get very short, and frustrations rise, very quickly.  We see
proposals, even about procedures rather than substantive
details, that would work well except for almost-inevitable bad
effects on language ABC or some hypothesis about next billion
users of the Internet; those who use that language or who are
trying to look ahead to those users tend, quite reasonably, to
have reactions that such proposals are unreasonable and
discriminatory.  We see suggestions that this is just a small
matter of engineering, that a particular easy approach will
solve everything, or that the only critical issue is "ABC".
Those types of suggestions are extremely problematic for some of
those who have been trying to push this rock uphill for many
years, both because they think they know better (from extensive
experience) and because some of those comments sometimes feel as
if they are being told they are idiots for having put all of
that time and energy into the efforts.  

The claims that have been made that some of the comments made
earlier in this discussion were unprofessional, patronizing,
and/or insulting only reinforces the comments above (whether one
accepts those claims or not).

I think all of us know how rapidly small miscommunications on
email can turn into large ones.  Maybe a face to face meeting
with a tight schedule (asking for only an hour was also
deliberate even though many of us could easily discuss some of
the substantive issues for a week or more) and the ability to
say "we agreed to not spend time on that in this session" or
"calm down and stay brief" in real time can help us hold a
discussion without people coming to blows.  Or maybe not.  But I
think it is worth a try and that try includes allowing (or
encouraging) the most controversial subjects to be deferred to a
f2f conversation.   I'd feel differently if I (and others who
are probably more sensible) didn't think that all of the other
options everyone has been able to think of --other than
admitting defeat and leaving this area, including existing
standards-track protocols, to whatever SDO or other organization
will willing to fill the vacuum that would leave -- had been
tried and failed.

Finally, I addressed the side-meeting option in my proposal for
the BOF.  While I had expected to be in Montreal, several of the
people whose participation in this BOF I think are important may
need to participate remotely, which means full Meetecho
coverage.  More important, and again because I see this as a
kind of last try before giving up (or recognizing that the IETF
and IAB have already given up), I think it is important that
there be a place on the formal agenda, minutes, and other things
that the community can treat as at least the beginning of a
consensus process (and part of the historical record) and the
IESG can and should interpret as guidance.    Informal
discussions and side meetings have been held and led nowhere (as
others have pointed out).  You might even recall the
conversation on this subject in Chicago, which also led nowhere.
BOFs have been held with more or less specific ideas to address
specific substantive matters and have resulted in either nothing
or a further loss of energy.  Let's do this as an organized
activity or make some plan we haven't tried already.

That leads me to something I should have thought of sooner:
please add a scheduling request to the BOF request that this
session be scheduled before the plenary.   If the BOF produces
no ideas for going forward, I think it will be desirable,
perhaps necessary, to ask the IESG (and maybe the IAB) the
question as to what we do next, even that if is a formal
statement that the IETF is giving up.

best,
    john

--On Tuesday, June 5, 2018 23:44 -0500 Adam Roach
<[email-masked]> wrote:

> discussion of the i18nRP BOF proposal. One of the topics that
> was most discussed is a concern that the BOF does not have a
> clear path to success, largely because the proposal has very
> little discussion of proposed potential outcomes. While we do
> not expect the proponents to presuppose an outcome, we believe
> that achieving a positive outcome requires one or more
> specific proposals to serve as a basis for the conversation.
> 
> At the same time, the volume of traffic on the IETF mailing
> list on this topic does seem to demonstrate that there is
> interest in discussing topics related to internationalization.
> The ART area directors have therefore provisionally approved
> the BOF, subject to the proponents and/or any other interested
> parties providing concrete proposals as a basis for discussion.
> 
> Concretely, this means that the secretariat has been requested
> to schedule a one-hour slot for the Montreal meeting for the
> proposed BOF. If no concrete proposals for procedural
> approaches to address the issues described by the BOF
> proponents are available by Wednesday, June 13th, the
> secretariat will be requested to remove the BOF from the
> schedule.
> 
> Although it did not come up during the call, I personally wish
> to point out that open-ended brainstorming sessions without
> concrete proposals are typically handled as unofficial
> side-meetings (either in person or virtually). If the BOF
> proponents wish to maintain the open-ended brainstorm session
> described in the current proposal, the side meeting scheduling
> mechanism remains available; and I would be happy to help out

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Jun 2018 10:43:47 -0600

> requires one or more specific proposals to serve as a basis for the

Thanks, Adam.

Research indicates that open-ended brainstorming sessions are less
effective than one might hope; see the citations here:

https://en.wikipedia.org/wiki/Brainstorming#Challenges_to_effective_group_brainstorming

Individual brainstorming ahead of time, formalized into concrete
proposals, seems to fare better.

Peter

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Jun 2018 13:23:02 -0500

> the absence of specific proposals in the BOF proposal was

I'd like to add two points of clarification, to make sure we're not 
talking past each other.

 1. This is not a request to revise the BOF request itself. We are
    looking for concrete process proposals within the next week on this
    mailing list.

 2. The proposals that are developed within the next week do not
    necessarily need to be those that are presented in Montreal. We are
    looking for a guarantee that there will be at least one concrete
    proposal going into the BOF. If a more preferred idea is proposed
    between next Wednesday and the meeting, it could be used as the
    basis for conversation instead of the initial proposals.

Thanks.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Jun 2018 08:29:37 +1200

>     looking for concrete process proposals within the next week on this

Isn't there one fairly straightforward proposal already implied in
the mail threads? Something like:

* Before the following IETF, the IESG (via a suitable AD) should
create an I18N Directorate which should perform I18N reviews
on all drafts during IETF Last Call, and provide advice and
assistance to draft authors and WGs earlier in the process when
possible.

    Brian

> _______________________________________________
> i18nRP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i18nrp
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jun 2018 16:58:26 -0400

Adam,

Understood and appreciated.

I will try to generate a scenario or two and post them within
the next week, but don't want to make promises.   Others should
post their own ideas.  

To put one stake in the ground I believe is logically necessary,
one of those scenarios is that the IETF formally goes out of the
i18n business.  That includes not only not processing the
documents we have not been processing, including not processing
IDNA or PRECIS updates, but not processing (or even chartering
or continuing WGs to produce) any protocol spec that requires
internationalization provisions (including but not limited to
non-ASCII characters) that cannot be satisfied by simple "do
what it says there" references to existing specs like IDNA2008
or PRECIS.  Even that exception is questionable if some
mechanism is needed to look at new versions of Unicode and we
don't have a working one of those.

That is fairly close to reductio ad absurdum and I hope no one
will actually support it.  On the other hand, it could be close
to where we end up if specification authors (or WGs) identify
internationalization considerations or the human rights effort
identifies internationalization requirements and an effort is
organized to appeal the announcement of an IETF Last Call on any
specification with those considerations on the grounds that the
IETF has no mechanism to competently review it.

Brian's suggestion is more realistic and I hope more palatable
but my personal view is that, without significantly more details
and framework, such a Directorate would turn into another
example of something we've tried before and that has failed.

I think there are other options, but those two should be
sufficient to start at least a semi-focused discussion.

   john

--On Wednesday, June 6, 2018 13:23 -0500 Adam Roach
<[email-masked]> wrote:

>> and the start of the IETF meeting but, while I have some
>> ideas, the absence of specific proposals in the BOF proposal
>> was deliberate.
> 
> 
> I'd like to add two points of clarification, to make sure
> we're not talking past each other.
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Jun 2018 16:06:14 -0500

> example of something we've tried before and that has failed.

I'd rather not see this effort aim for failure and, upon hitting it, 
declare that its goals have been met. I trust that you will attempt to 
provide these additional details?

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Jun 2018 15:06:35 -0600

> assistance to draft authors and WGs earlier in the process when

Concisely described; thanks!

I believe it would also be helpful to:

* Publish an RFC on "Internationalization Considerations for Internet
Protocols" (similar to RFC 3552 on security and RFC 6973 on privacy)
offering guidance for developing internationalization considerations for
inclusion in protocol specifications, with the goal of making designers
and implementers of Internet protocols aware of design choices related
to internationalization.

Such a document would gather, in one place, many of the lessons we have
learned over the last ~20 years from IETF work on UTF-8, IDNA[2008],
Stringprep, EAI, PRECIS, Net-Unicode, et al. Writing down this tribal
wisdom will help the proposed I18n Directorate complete its reviews,
train and mentor new participants, and educate outside experts in
particular scripts or languages regarding the challenges and constraints
of applying internationalization techniques to Internet protocols such
as the DNS, HTTP, and email.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Jun 2018 15:08:12 -0600

On 6/6/18 3:06 PM, Adam Roach wrote:
> declare that its goals have been met.

Perhaps it would help for us to describe the things we've tried before
and the ways in which they succeeded or failed...

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Jun 2018 15:19:27 -0600

On 6/6/18 3:06 PM, Adam Roach wrote:
> I trust that you will attempt to

Adam, what are the IESG's requirements and expectations regarding
creation of a new directorate? Is it expected, for instance, that a
charter of some kind will need to be provided and approved? Guidance
would be helpful.

Thanks!

Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Jun 2018 16:37:59 -0500

> and the ways in which they succeeded or failed...

It does seem like it would be useful to have those all written up in
a single place.  (It would be asking a lot of someone to write it
this fast, but if even a rough cut was available before Montreal, it
would help people attempting to come up with new concrete proposals
to avoid some of the pitfalls that have already been discovered.)

-Benjamin

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Jun 2018 17:11:13 -0500

> charter of some kind will need to be provided and approved? Guidance

With the caveat that I may have overlooked some bit of formal process...

In the general case, the creation of a new directorate simply requires 
convincing an area director that such directorate would serve a useful 
purpose. While directorates don't have charters per se, as a practical 
matter, they need to have a reasonably complete description of their 
purpose and role.

I'll note that directorates have a broad range of formality and document 
coverage associated with them: on one end, SECDIR and GENART have active 
secretaries who assign every document during IETF last call to a 
volunteer from a large pool of specialists (SECDIR) or generalists 
(GENART). On the other end, the SDPDIR has a relatively small pool of 
self-directed experts that authors, chairs and area directors can reach 
out to for advice and review. The SDPDIR does not proactively review 
documents.

In the specific case of establishing an i18n review directorate: based 
on the comments made so far, I think we would want a carefully defined 
process (possibly documented in an RFC, but perhaps just part of the 
directorate description) that described what role the directorate would 
play in the development and publication of specifications.

We would also need a plausible group of volunteers to execute that 
process. For example, if the proposed process were to review every 
document, in the style of SECDIR and GENART, I'd want to see a group of 
i18n expert volunteers (or volunteers who are willing and able to 
educate themselves into being experts) of roughly the same size as those 
directorates. For reference, the SECDIR has 64 members, and GENART has 
27. By contrast, if the role were to provide feedback only as requested, 
it could be similar in size to the SDPDIR, which has seven members.

In practice, I suspect the process the interested parties might 
reasonably settle upon would be somewhere in between, with someone 
(possibly a rotating duty) providing light triage on documents during 
IETF last call for the purposes of identifying which have an 
intersection with i18n, and a pool of dedicated reviewers to whom 
documents that do are assigned. The number of people such activity would 
require to succeed is, of course, a judgement call, but based on the 
size and function of existing directorates, I think we can safely say 
that it is significantly more than seven, and somewhat less than 27.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Jun 2018 16:31:54 -0600

> that it is significantly more than seven, and somewhat less than 27.

Thanks for the helpful context.

SECDIR, GENART, and ARTART reviewers seem to check the whole document.
By contrast, I18N reviews would have a smaller scope (along the lines of
what the SDPDIR does). As a point of comparison, the W3C I18N WG [1] is
quite busy but is very small: John Klensin and I and a few others help
out, but most of the work is done by two people.

To gauge the scope of work for an I18N directorate, we could look at the
IESG telechat agendas for the last two months and see how many documents
would have been reviewed, and how much text in each document needed
attention.

Peter

[1] https://w3c.github.io/i18n-activity/i18n-wg/

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Jun 2018 17:56:47 -0500

On 6/6/18 5:31 PM, Peter Saint-Andre wrote:
> what the SDPDIR does).

I'm not sure how good a comparison this is. Any document that doesn't 
mention SDP is clearly not a candidate for SDPDIR review. Any document 
that doesn't mention i18n, probably *does* need a check that such 
omission makes sense. In that way, I think the required task is more 
like SECDIR than SDPDIR.

Thanks for mentioning ARTART. Its process is useful as a third point on 
the continuum of rigor exhibited by directorates. ARTART only reviews 
those documents that are flagged as potentially having ART interactions, 
rather than the intended full coverage of SECDIR, OPSDIR, and GENART. It 
is probably more in line with what is appropriate for an 
internationalization directorate, both in function and size. It 
currently has 12 members, although we would ideally like a slightly 
larger pool.

> As a point of comparison, the W3C I18N WG [1] is

Taken together with the assumption that any IETF directorate would 
probably involve substantial overlap with that group of people, I'm now 
concerned about scaling. I couldn't quickly find statistics on how many 
documents the W3C finalizes in any given year, but my impression is that 
it's somewhat smaller than the IETF's output. Given that your 
description uses the words "quite busy," do you think that same group of 
individuals could double or triple their i18n review load without losing 
efficacy or burning out?

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Jun 2018 17:27:05 -0600

> omission makes sense. In that way, I think the required task is more

As stated in BCP 18:

   Internationalization is for humans. This means that protocols are not
   subject to internationalization; text strings are.

If there are no human-readable text strings in a protocol, then no i18n
review is needed. In the IETF, that significantly narrows the field. My
sense is that few INT or RTG area specs, a somewhat higher proportion of
OPS, SEC, and TSV area specs, and a preponderance of ART area specs
would at least need a spot check to determine if review is required.

Furthermore, the IETF often publishes documents that re-use core
protocols. Examples just from the 2018-06-07 telechat tomorrow include
YANG data models, HTTP header fields and status codes, IMAP extensions,
and URN namespace registrations. One hopes that the i18n aspects of
these protocols were addressed long ago, and that these documents are
re-using i18n methods already in place.

And this is not to mention procedural documents about meeting policies,
IANA registry rules, and other things I see on tomorrow's agenda.

> it's somewhat smaller than the IETF's output. 

Perhaps. However, many or most of the specs that the W3C develops are
human-facing, which is the relevant measure (see above).

You can get a sense for the range of review tasks here:

https://w3c.github.io/i18n-activity/reviews/

Also, the W3C team is engaged in a variety of more outward-facing
activities (articles, language-specific task forces, etc.):

https://w3c.github.io/i18n-activity/projects/

And they are working on their own documents, such as the Character Model
for the World Wide Web:

https://www.w3.org/TR/charmod-norm/

So it's hard to compare apples to apples. But overall I would say that
the W3C I18N WG is operating at high efficiency.

> Given that your

I can't say whether they'd ever have to double or triple their
activities, or how they'd handle that. The might reprioritize certain
tasks, review some things more slowly, seek more volunteers, etc. I can
ask them during tomorrow's I18N WG call.

Peter

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jun 2018 21:45:28 -0500

> >By contrast, I18N reviews would have a smaller scope (along the lines of

FWIW, I concur with Peter that your message about directorate
organization and functions was quite useful.

> mention SDP is clearly not a candidate for SDPDIR review. Any document that
> doesn't mention i18n, probably *does* need a check that such omission makes
> sense. In that way, I think the required task is more like SECDIR than
> SDPDIR.

Might it be reasonable to expect shepherds and/or responsible ADs to
detect I18NDIR review opportunities and refer documents to it?

> Thanks for mentioning ARTART. Its process is useful as a third point on the
> continuum of rigor exhibited by directorates. ARTART only reviews those
> documents that are flagged as potentially having ART interactions, rather
> than the intended full coverage of SECDIR, OPSDIR, and GENART. It is
> probably more in line with what is appropriate for an internationalization
> directorate, both in function and size. It currently has 12 members,
> although we would ideally like a slightly larger pool.

This sounds right.

> probably involve substantial overlap with that group of people, I'm
> now concerned about scaling. I couldn't quickly find statistics on how
> many documents the W3C finalizes in any given year, but my impression
> is that it's somewhat smaller than the IETF's output. Given that your
> description uses the words "quite busy," do you think that same group
> of individuals could double or triple their i18n review load without
> losing efficacy or burning out?

Regardless of what the answer to that is, it might be possible to start
small and scale up.  Starting small means triaging more demurely.  At
any rate, starting small is probably the only realistic way to get
started.  But there's no point starting small if we can't scale up, so
we do need to have some idea of how big to scale, and how.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jun 2018 22:17:53 -0500

> would at least need a spot check to determine if review is required.

Almost.  Consider SSHv2...

SSHv2 carries UTF-8 strings in some of its messages, and supports
language negotiation for localization of messages to users.  This is
very nice and maybe was fairly forward-thinking at the time.

SSHv2 easily could have not carried any such strings -- at least if we
ignore password and interactive authentication methods, which I will for
the sake of the argument I'm about to make.

   [TL;DR?  My point is this: even a protocol which carries no strings,
    but which does carry session text data, or documents, might need to
    support language or locale negotiation.
    
    Related point: it's not just I18N we should think about, but also
    L10N (localization).  In the IETF we tend to include L10N in I18N,
    but elsewhere I've seen G11N (globalization) used as encompassing
    I18N + L10N.]

But the whole point of SSHv2 is to carry "shell session" user data,
including user _interactive_ session data, which means: text -- text
that the protocol carries as-is no matter the choice of codeset, so
there are no internalization issues in SSHv2 regarding that text.  But
there are still _localization_ issues regarding that text: specifically,
negotiation of server-side locale for user sessions.

So even if SSHv2 had carried no strings in its various messages, it
would still have needed to support locale negotiation.

The protocol only supports language negotiation, but for the sessions it
establishes it kinda needed to support codeset negotiation as well, and
maybe other locale attributes.  Users make do by just sending LANG
and/or LC_* POSIX environment variables without any kind of negotiation,
hoping for the best.

Note also that the IETF has no standard notion of locale (unless that
has changed recently), which is partly why SSHv2 doesn't either.  In our
protocols we speak of language tags and codesets completely from each
other, and we try hard to only use Unicode and UTF-8.  But operating
systems tend to deal with {language, codeset} as units -- locales.
(There's a bit more to a locale than language + codeset, but let's
ignore that for a moment.)

It might be useful for the IETF to adopt (a subset of?) the POSIX notion
of locale.  Though admittedly we have very few protocols where we'd need
it, thus lacking a notion of locale has not been noticeably problematic.

Nico
--

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Jun 2018 22:29:26 -0500

> detect I18NDIR review opportunities and refer documents to it?

Perhaps, but my experience is that such things can easily fall between 
the cracks when left to shepherds and ADs.  Possibly, we could amend the 
shepherd writeup template to ask whether the document deals at all with 
human-readable text; and, if so, whether a directorate review has been 
requested -- perhaps that would work. I do note that the shepherd 
write-up is already quite long; and that (presumably as a consequence) 
such questions are often given pro-forma responses. On the occasions 
that I run id-nits on documents submitted to the IESG for review and 
find issues, I've found that about half of the shepherd's writeups 
answered the question about id-nits with the incorrect statement that no 
issues were found.

So while it would probably be ideal to rely on AD and/or shepherds to 
flag documents, I suspect we'll get better coverage by having a 
dedicated directorate triage (with an obvious increase in load on the 
directorate). I'm not sure what the best trade-off is here. Perhaps we 
run a series of experiments to see what works best.

> we do need to have some idea of how big to scale, and how.

This sounds reasonable, and is pretty much what I had in mind when I 
said "volunteers who are willing and able to educate themselves into 
being experts". I say this while agreeing with John about the 
complexities and subtleties of this topic.

/a

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jun 2018 22:30:07 -0500

An initial, rough, incomplete questionnaire for triaging:

 - does the document deal with a protocol?

   No?  -> no I18NDIR review

 - does the protocol carry error and other messages for users?

   Yes? -> I18NDIR review necessary; the protocol should support
           language negotiation for localization (L10N), and it should
           use UTF-8.

 - does the protocol carry identifier strings (e.g., usernames,
   filenames, ...) or passwords?

   Yes? -> I18NDIR review necessary; the protocol should specify some
           sort of stringprep, whether to normalize or allow
           form-insensitivity, etc..

 - does the protocol have domainname slots?

   Yes? -> I18NDIR review necessary; must indicate which slots are
           IDNA-aware and so on.

 - does the protocol carry "shell" session data?

   Yes? -> I18NDIR review necessary; the protocol should support locale
           negotiation, or at least negotiation of language and codeset.

Note that the use of constant strings in protocol elements does not imply
I18N considerations if they are not to be displayed to users, or if
localization of them is a local problem.

If "no" to all of these questions, then no I18NDIR review should be
needed.

Nico
--

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Jun 2018 22:38:30 -0500

Thanks for taking a first stab at this. I think one of these criteria 
needs a bit of expansion:

>             form-insensitivity, etc..

This will also be the answer if you have any protocol that compares 
UTF-8 strings, regardless of whether they are identifiers or passwords. 
For example, if one were to define a SIP header field whose value can 
contain characters greater than U+007F, and defined semantics for 
comparison of that value to another string, then such considerations 
would apply.

/a

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jun 2018 22:44:48 -0500

On Wed, Jun 06, 2018 at 10:29:26PM -0500, Adam Roach wrote:
> This sounds reasonable, and is pretty much what I had in mind when I said
> "volunteers who are willing and able to educate themselves into being
> experts". I say this while agreeing with John about the complexities and
> subtleties of this topic.

That's fair.  Directorate members' I18N expertise might vary, with some
better able to review email- or DNS-related I-Ds, and others better able
to review filesystem- or web-related I-Ds.  I18N is a fairly big topic,
and I wouldn't expect every directorate member's expertise to be
sufficient to review every comer.

Also, John notes that reasonable people can and do disagree regarding
various I18N issues, so we can probably expect some of that from the
directorate.  I hope directorate members can recognize and acknowledge
which aspects are more objective and which more subjective.  Still, I
believe a lot of I18N issues are basic and can be dealt with objectively
at this point, so a directorate should be helpful.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jun 2018 22:47:53 -0500

On Wed, Jun 06, 2018 at 10:38:30PM -0500, Adam Roach wrote:
> Thanks for taking a first stab at this. I think one of these criteria needs
> a bit of expansion:
> 
> This will also be the answer if you have any protocol that compares UTF-8
> strings, regardless of whether they are identifiers or passwords. For
> example, if one were to define a SIP header field whose value can contain
> characters greater than U+007F, and defined semantics for comparison of that
> value to another string, then such considerations would apply.

Sure.  Those would either be identifiers (if the protocol is open to
arbitrary headers) or protocol constants (whose exact encoding needs to
be specified without further I18N considerations).

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jun 2018 00:31:49 -0400

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Jun 2018 23:41:27 -0500

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jun 2018 01:02:47 -0400

--On Wednesday, June 6, 2018 23:41 -0500 Adam Roach
<[email-masked]> wrote:

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

Adam,

I'll work on that although, if I had suggestions that were
clearly better than the ones we discussed in Chicago I would
have proposed  them long ago.  In the interim, the discussion of
directorates for review of documents that are only partially or
incidentally about i18n issues, or that need review to determine
whether or not they are, should probably continue.  I may not be
able to get back to it before the weekend, however.

To clarify my earlier comment about Brian's original note in the
light of these conversations, my concerns were about this
separation of problems (i.e., problems that traditional
directorate models probably don't solve) and, for the directory
model, precisely the issues about expertise and number of live
bodies needed that have been under discussion in this thread.

  best,
     john

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 7 Jun 2018 11:13:15 -0600

> at this point, so a directorate should be helpful.

In RFC 8141, we provided the following guidelines to designated experts
and registrants of URN namespace identifiers; something along these
lines might be appropriate in this context, too:

###

   Experience to date with URN namespace registration requests has shown
   that registrants sometimes do not initially understand some of the
   subtleties of URN namespaces and that defining the URN namespace in
   the form of a specification enables the registrants to clearly
   formulate their "contract" with the intended user community.
   Therefore, although the registration policy for formal URN namespaces
   is Expert Review and a specification (as distinct from the
   registration template) is not strictly required, registrants SHOULD
   provide a stable specification documenting the URN namespace
   definition and expanding upon the issues described herein.

   Because naming can be difficult and contentious, URN namespace
   registrants and the Designated Experts are strongly encouraged to
   work together in a spirit of good faith and mutual understanding to
   achieve rough consensus (see [RFC7282]) on handling registration
   requests.  They are also encouraged to bring additional expertise
   into the discussion if that would be helpful in providing perspective
   or otherwise resolving issues.

###

---

From: Larry Masinter <[email-masked]>
Date: Fri, 8 Jun 2018 12:09:56 -0700

Focus on confusables, untypables. Unicode greatly expands these.

I say 'greatly expanded' because ASCII has confusables (MlCR0S0FT - note
lower-L vs upper-i and zero vs upper-o) but short lower-case ASCII might be
ok. 

Separate unintended vs. malicious cases.

*	Unintended can be reduced by providing more information to those
choosing names.
*	To address maliciously introduced confusables may require protocol
changes:

To deal with maliciously introduced confusables, reduce the reliance on
humans to compare or read or retype accurately of unvalidated name from a
non-trusted source (as commonly exploited by phishing) might mean
recommending the 'resolution' of typed-in or even copy-pasted URLs into
searches, and using directory search for non-ASCII email addresses as well.

Give up trying to enumerate and mandate the non-use of confusables ,as it is
too dependent on the population, their language, and the software they have.

Larry

---

From: Adam Roach <[email-masked]>
Date: Fri, 8 Jun 2018 14:34:20 -0500

Thanks, Larry. It's good to hear from you.

This seems like sound advice. I'll point out that we're trying to 
determine a *process* for addressing i18n issues rather than addressing 
the actual issues right now.

/a

On 6/8/18 2:09 PM, Larry Masinter wrote:
> I say ‘greatly expanded’ because ASCII has confusables (MlCR0S0FT – 
> note lower-L vs upper-i and zero vs upper-o) but short lower-case 
> ASCII might be ok.
>
> To deal with maliciously introduced confusables, reduce the reliance 
> on humans to compare or read or retype accurately of unvalidated name 
> from a non-trusted source (as commonly exploited by phishing) might 
> mean recommending the ‘resolution’ of typed-in or even copy-pasted 
> URLs into searches, and using directory search for non-ASCII email 
> addresses as well.
>
> Give up trying to enumerate and mandate the non-use of confusables ,as 
> it is too dependent on the population, their language, and the 
> software they have.
>
> Larry
>
>
>

---

From: Larry Masinter <[email-masked]>
Date: Fri, 8 Jun 2018 16:43:14 -0700

I’m trying to address what I think is a ‘process’ question:

Dealing with unintentional confusables is not something that ‘more specifications’ can address, because what makes something confusable depends on too many factors that are transient, because the people who want a name with a problem they might not be aware of won’t care about the other 99% of bad cases, they just want THEIR name. 

Procedurally:

*	Stop trying to make standards-track documents about how to normalize names. 
*	Widely available services or tools for avoiding confusable names would be handy, but they can err on the side of caution. 
*	 An informational document might be useful, perhaps starting with insightful emails on the list.

Dealing with malicious confusables is mainly a security issue. You don’t need to know any of the details of whether something is or isn’t confusable except to acknowledge that the there is no complete agreement on how to compare Unicode strings and agreement is unlikely in the foreseeable future. 

Procedurally:

*	Introduction of confusables is part of the attack surface that the “Security Considerations” of any protocol with i18n elements must address. No separate I18N-considerations necessary.
*	Document how current services deal with confusables and mitigate the problems (phishing, domain name poaching, etc.) in a BCP if you can get some agreement on which Current Practices are Best.

I’m trying to address process by suggesting things that IETF might be able to make progress on without new acquisition of expertise. 

Larry

From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, June 8, 2018 12:34 PM
...

This seems like sound advice. I'll point out that we're trying to determine a *process* for addressing i18n issues rather than addressing the actual issues right now.

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Jun 2018 14:59:02 -0700

> and how the proposed solutions would work for them.

John --

After thinking through this issue a bit, I suspect the answer would look 
something like this:

Given the assertions that have been made about the likelihood of 
successfully creating a working group that would adopt and progress 
these documents, and given their nature, it seems that they would be 
reasonable candidates for AD sponsorship. In the context of the 
thumbnail sketch that has been building up on this list, I would expect 
that the sponsoring AD would work closely with the proposed i18n 
directorate to ensure that the proper level of review has taken place.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Jun 2018 13:59:47 -0700

Based on the proposals and discussion we've seen in the past week, this 
BOF will be meeting in Montreal. Many thanks to Peter St. Andre and Pete 
Resnick for agreeing to chair the session.

/a

On 6/5/18 21:44, Adam Roach wrote:
> At the same time, the volume of traffic on the IETF mailing list on 
> this topic does seem to demonstrate that there is interest in 
> discussing topics related to internationalization. The ART area 
> directors have therefore provisionally approved the BOF, subject to 
> the proponents and/or any other interested parties providing concrete 
> proposals as a basis for discussion.
>
> schedule a one-hour slot for the Montreal meeting for the proposed 
> BOF. If no concrete proposals for procedural approaches to address the 
> issues described by the BOF proponents are available by Wednesday, 
> June 13th, the secretariat will be requested to remove the BOF from 
> the schedule.
>
> Although it did not come up during the call, I personally wish to 
> point out that open-ended brainstorming sessions without concrete 
> proposals are typically handled as unofficial side-meetings (either in 
> person or virtually). If the BOF proponents wish to maintain the 
> open-ended brainstorm session described in the current proposal, the 
> side meeting scheduling mechanism remains available; and I would be 
> happy to help out should any difficulties occur in using that mechanism.
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jun 2018 14:47:49 -0400

--On Wednesday, June 13, 2018 14:59 -0700 Adam Roach
<[email-masked]> wrote:

>> The other is an actual
>> i18n spec.  So, as an exercise for those designing solutions,
>> consider draft-klensin-idna-5892upd-unicode70
>>     and
> After thinking through this issue a bit, I suspect the answer
> would look something like this:
> 
> Given the assertions that have been made about the likelihood
> of successfully creating a working group that would adopt and
> progress these documents, and given their nature, it seems
> that they would be reasonable candidates for AD sponsorship.
> In the context of the thumbnail sketch that has been building
> up on this list, I would expect that the sponsoring AD would
> work closely with the proposed i18n directorate to ensure that
> the proper level of review has taken place.

Adam,

Maybe.   Let me see if I can explain my concern.  Over the years
and depending on who is on the IESG, I think I've seen a general
pattern in the difference between individual submissions and WG
documents, at least for documents that end up being treated as
the slightest bit controversial, i.e., where the consensus among
all of those who have opinions is not clear and obvious.

I need to temporarily take a few steps back from i18n and look
at patterns of document review.

WG documents come into IETF Last Call with claims of WG
consensus, often better than just "rough".   For many of these
controversial documents, here is an uproar during IETF LC.
Again, there are exceptions, perhaps many of them, but there are
often strong assertions that the WG contained most or all of the
people in the IETF who were both expert and interested
(effectively by definition), that anyone who was an expert but
did not participate actively in the WG had given up their right
to comment, etc., etc.  Typically, the IESG does not fine
tuning, but the document ultimately goes through.  Maybe I
wasn't paying attention when it happened, but I cannot remember
a single instance in which a WG has submitted a document for
standards track approval and, after IETF Last Call and IESG
review of the document and results, the IESG goes back to the WG
and says "no to the document and it is clear that the views and
expert conclusions of your active participants are out of line
with those of the community and we are shutting you (and this
work) down until there is a plan to create well-worked-out and
better aligned documents".   Now perhaps that never occurs
because WGs always have adequate representation of all of the
positions in the community, are never dominated (even if
accidentally) by a particular narrow cluster of interests, and
so on, but I hope you agree that there are a few other
hypotheses that may be plausible in at least some cases.

For an independent submission, the pattern has sometimes been
quite different.  If there is evidence that a document is likely
to be controversial and/or viewed by the community as
problematic technically, it typically will not be AD-sponsored
and hence won't even see IETF LC.   That is probably how it
should be: I assume that, if ADs were asked how many individual
submissions they had sponsored and put into IETF LC that they
knew were defective for substantive technical reasons, the
answer would be few or zero.  There also appears to be a bias in
the system with documents generated by people with close
relationships to particular ADs and/or strong track records in
the IETF having much better success getting AD sponsorship than,
e.g., newcomers.   However, if one of those individual
submission documents gets into Last Call and there is a
significant (in volume) uproar, the document is far more likely
to be dropped or withdrawn than one that was generated and
submitted by a WG.  Again, that may very well be as it should be
in the overwhelming majority of cases -- for individual
submissions, IETF LC is the only public, group, review of the
specification and that review is useless if it doesn't filter
out bad (or insufficient) work.

It is implicit, but the above depends on the assumption that the
community and/or internal expertise in the IESG will, in
reviewing comments, be able to rather easily determine the
differences among:

(i) Legitimate and informed comment (whether one agrees with
it/them or not).
(ii) Well-intentioned comment from someone who is thoroughly
confused or that isn't relevant to the particular specification
(e.g., is about something else entirely or makes assumptions
that the IETF has already considered and reach consensus to
reject.
(iii) Trolls

Occasionally, it is hard to distinguish between (ii) and (iii)
but, while the difference may be important with regard to the
noise level and the question of whether it is worth investing
time and energy to help the person making the commenter
understand, probably neither should influence decisions made
about the specification and they rarely do.  

As an extreme example, assume there is a new spec for a TCP
Congestion Control variation.  I'd expect many comments from
people who at least mostly understand the issues, some in favor,
some opposed, and some raising questions about fine points,
relationships to other approaches, and details of documentation.
If we are ordinarily unlucky, a few comments will also show up
about how, if we only adopted TCPv7 and IPv17, we wouldn't have
any of those pesky congestion control problems.   It seems clear
that those comments would not be taken seriously enough to
increase the odds that the specification would be rejected or
returned to the author for drastic revision.

[Disclaimer: some of the comments that follow echo ones I made
in more detail and a more specific context in my note to Nico
yesterday.  Neither that note nor this one are an attack on him;
I have found some of the recent discussions with him very
helpful in improving my own understanding and appreciate his
patience with me as we tried to sort out how and where we
disagreed.  Yes, there are positions and behaviors that bear a
partial and superficial resemblance to some comments he has made
and for which I have bad words, but I don't believe those are
his positions or behaviors.]

However, when we apply whatever those patterns predict to
individual submission i18n documents, we find what I think is a
different problem.  We've heard comments made with great
conviction in BOFs, WGs, and the IETF list that reflect the
assumption that what people have learned about the writing
systems for one or two languages (possibly even using the same
script) is enough to generalize to everything else or that, if
one understands a couple of very different languages and writing
systems, everything else is enough like one or both of those
that a solution for them will take care of everything else.
Similarly, we've seen people who believe the whole problem (or
all of its interesting aspects) are about how one codes
characters without understand the many issues there much less
all of the issues coding doesn't cover) are about confusability,
typically confusability at the code point level.  The latter has
been much more common around ICANN and Internet Governance
circles than around the IETF, but that has not helped with the
noise level).  In addition, we've had arguments made against
particular aspects of, or changes to, details of, e.g., IDNA or
PRECIS, that are based on rejection  And so on.

I've save time and space by not trying to explain why many of
those complaints, proposals, and statements are incorrect even
if they have enough elements of truth in them for which examples
can be given, but the questions are about detection and
strategy.   Those types of comments are sometimes difficult, but
possible, to handle in WGs where there is a clear focus on a
chartered task and, usually, enough concentration of knowledge
to at least recognize the problem, just as a TCP-related WG
would have no trouble telling the difference between a proposal
to improve on our current congestion control techniques and
someone who claims to be able to eliminate the need for it
entirely or who method merely requires operating a backchannel
that runs above the speed of light.

I'm less sanguine about BOFs (we've seen some bad experiences)
or a directorate because the mission statements and control
policies have generally been less clear (usually in the interest
of desirable flexibility).  And I'm concerned about whether the
IESG (all of the IESG) would actually pay attention to advice
from a directorate in the presence of rather loud contradictory
advice during a Last Call.   I don't think those potential
problems are insurmountable, but I think that being aware of the
potential problems and factoring them in, would provide a much
more likely basis for success (rather than a lot of frustration
and needing to have this discussion again in a few years) then
just deciding to create a directorate and a few extra rules and
hoping everything works out.

As a closing comment, I do not consider myself an expert in this
area, except in the sub-area of having learned a lot about what
I don't know.  The latter is an important store of knowledge and
seems to be ever-increasing.   As a specific example, almost
every time I've consulted an expert on some specific aspect of
our i18n work, I come away with three things and sometimes a
fourth:

 * An answer, which is usually more complex and ambiguous
	than I had hoped for or anticipated
 * An in-depth understanding that the question I asked
	was incomplete, showed ignorance of the issues, or was
	just the wrong one and why.
 * A considerable increase in the size of  yet another
	area in which I didn't know nearly enough and still
	don't.  
 * More support for the hypothesis that, in this area,
	almost any simplistic solution is either not going to
	work or is going to need a good deal of explanation
	about what problems it isn't going to solve.

I think that, if more of us could adopt that sort of stance
toward this material, we be making big steps toward resolving
issues (and identifying those 5hat cannot be resolved) rather
than going around and around in the same circles.  Noting that
we don't need that attitude toward things that are simply
engineering problems (even hard ones with tradeoffs like
congestion control), that is just my personal opinion and as of
this week.

Thanks for listening.  And, Adam, thanks for signing off on the
BOF.

best,
    john

---

From: "John R. Levine" <[email-masked]>
Date: 15 Jun 2018 21:32:43 -0400

On Thu, 14 Jun 2018, Adam Roach wrote:
> Based on the proposals and discussion we've seen in the past week, this BOF 
> will be meeting in Montreal. Many thanks to Peter St. Andre and Pete Resnick 
> for agreeing to chair the session.

I see the BOF is tentatively scheduled Thursday afternoon at the same time 
as dnsop.  Considering how deeply intertwined i18n is with the DNS, any 
chance you can ask to move it?

R's,
John