Proposed Charter for the IDNAbis Working Group

[John C Klensin]

--On Wednesday, 26 March, 2008 10:09 -0700 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

> I also like this version of the charter.  I do have a couple
> questions.

Shawn, 

Personal opinion only, but this is more or less the boundary
point between "discuss charter and what this is about" and "need
to read the drafts before discussing them".   I'll try to get
summary answers to your questions below, but there is no
substitute for reading the drafts, since summary comments on
what is in them may not be accurate enough (and I have a history
of mis-remembering even things that I wrote :-( ).
 
> I like that phishing is out of scope, but I expect that some
> security related issues will come up (ie: symbols?)?  I
> wouldn't mind pointing users to a more appropriate doc (like
> UTR36 or something)

The response I sent to Gerv earlier may help with this, but,
basically, the current IDNA200X drafts permit only the ASCII
hyphen plus characters that one might reasonably think of as
letters, digits, and the marks and mechanisms needed to form
them.  That leaves the symbols, box-drawing characters,
miscellaneous punctuation, etc., etc. out.   There are many
reasons for doing things that way.  Phishing is not high on the
list, even though making phishing somewhat harder is a useful
side-effect.   

The intention is that "Rationale" discuss and explain all of
this.  If the explanations there are not adequate, I'd welcome
specific suggestions about where improvements are needed or,
even better, recommended text.

> I don't know how to interpret the "that removes any character
> mapping in the protocol" part of (iii).  Perhaps I'm
> misreading "character mapping."  I expected that many
> characters are expected to be removed (eg: symbols).

While the implications and details are much broader, one of the
characteristics of IDNA2003 is that compatibility characters,
unnormalized strings, and upper-case characters are permitted to
appear in queries (and equivalent operations) and are mapped to
their base, normalized, and case-folded equivalents.  The
IDNA200X proposals work only on those target strings, viewing
any mapping from one character to another (even case-folding and
canonical (NFC) normalization) as outside the protocol.  While
this change raises important transition issues --which have been
extensively discussed on this list in recent weeks and months--
and the main reasons for it are to reduce confusion about what
is permitted and simplify the protocol, it can also be seen as a
component of an anti-phishing strategy.

> Additionally, above it says that non-backwards compatible
> changes could be considered.  What should my expectations be?

That the WG will have the opportunity to examine and discuss
every such change as to whether the benefits are worth the costs.

I believe that "Rationale" is fairly clear about what we intend;
if it is not, input and suggestions would be welcome.

    john