Minutes from the Tuesday, March 23rd, 2009 IDNAbis WG meeting

[Mark Davis]

Thanks to Eric as well; taking notes in that kind of meeting is very hard.
For the one case where what I said was "missed by scribe", my response was
something like:

There are different kinds of "suspicious" domain names; for example, a
company like Google keeps list of known spoofing sites. However, *that* kind
of suspicious domain name has nothing to do with the character content of
the URL, nor with the choice of characters to allow in domain names. The
only type of "suspicion" that is of concern for us is visually
confusability.

Mark


On Mon, Apr 6, 2009 at 05:25, Vint Cerf <vint at google.com> wrote:

> thanks to eric for taking notes
>
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
>
>
>
>
> Begin forwarded message:
>
> *From: *Eric Brunner-Williams <ebw at abenaki.wabanaki.net>
> *Date: *April 5, 2009 4:27:33 PM EDT
> *To: *Vint Cerf <vint at google.com>
> *Cc: *ebw at abenaki.wabanaki.net
> *Subject: **Minutes from the Tuesday, March 23rd, 2009 IDNAbis WG meeting*
>
> Minutes from the Tuesday, March 24th, 2009 IDNAbis WG meeting, scribe Eric
> Brunner-Williams (ebw at abenaki.wabanaki.net). Transcribed from notes,
> supplemented with Andrew Sullivan's jabber log.
>
> The meeting began at 9am with blue sheets and agenda modification.
>
> Patrick Faltstrom (PAF) continued the prior day's discussion of
> casefolding, commented that Stuart had checked the {b u-umlaut} vs {B
> u-umlaut} case (no change)
> Paul Hoffman (PH) responded that the a-umlaut case was correct (change)
>
> Agenda modification Paul Hoffman's IDNAv2 proposal for 30min, followed by
> questions.
>
> PH - IDNAv2 presentation, in brief, explain what the difference relative to
> IDNA2008, see slides (Pauls). Different mapping solution (2008 is no
> mapping)
> PAF - "more complicated than that", difference over what "mapping means"
> PH - map in registration vs map in UI, suggest we tighten definition of
> "map"
> Mark Davis (MD) - clarification (repeated later) that "protection" (from
> "abusive registration") is not simply via registry policy, but also via the
> client implementation, followed by a discussion of browwer display of
> "suspicious characters".
> Vint Cerf (VC) - browsers are not the only applications that will use IDNs
> so human processing (visual simularity, "looking") isn't the only test
> MD - suspicious is homoglyphs, so "looking" is the test
> John Klensin (JK) - suspicious is bad registry policy, and/or bad font
> and/or bad character set and/or bad content experience
> MD - rejoinder (missed by scribe)
> Thomas Narton (TN) - is there agreement that ICANN can't go ahead? if we
> avoid edge cases ...?
> PH - yes, avoid edge
> TN - avoid edge in leading rounds
> Cary Karp (CK) - not the central issue, ICANN needs to enter into
> contracts, no one is prepared to agree to conformance with protocol not
> written so if delay then IDNA2003 goes into those contracts
> Harald Alvestrand (HA) - there is no difference (between 2003 and 2008) for
> the set of labels ICANN has announced, there are no edge cases
> Eric Brunner-Williams (EBW) - not all characters are known yet
> HA - not all submissions have been made public
> Tina Dam (TD) - public strings are announced, but not all chars (other than
> TLD labels) disclosed (this is a reference to the SLD and subordinate chars,
> scribe)
>
> End of the IDNAv2 presentation.
>
> VC - slides, discussion of stringprep, nameprep and upgrading, as well as
> occurrence elsewhere, e.g., kerberos for password matching
> JK - procedural issues with "this updates stringprep", update issue
> discussion
> HA - when do we discuss substantive issues? Two points of violent
> objection: (1) it retains all the chars valid in '03 including snowman,
> stupid mistake, and (2) treatment of bidi, current bidi spec fails to
> achieve goals, AN, EN issue "simple bidi fix is too simple", and has other
> stylistic objections.
> MD - agrees 08 bidi much better than 03 bidi, disagree snowman is stupid,
> overblown objection, doesn't hurt much to take it out, square-root (dot) com
> example (some mac fan), neutral on eliminating symbols.
> PH - agree, not violently, about (heart) (removing it, scribe)
> PAF - more violent disagreement with IDNAv2, (1) still table based, not
> rules, why not use rules? same ending discussion so same time to complete.
> no comments (to current -table draft in five months. problem in jabber/xmpp
> stored input (pre-map form), and (2) definition of a-labels and u-labels,
> but maybe has been added to v2. Problem with *prep -- no understanding of
> difference between the character that is mapped to something and then
> stored, so people have stored the pre-mapped character, mapping was big
> mistake in idna2003. New mapping suggestion for idna2008 is just a help to
> applications.
> Leslie Daigle (LD) - timeliness is a red herring, v2 plus one or two things
> won't work
> JK - IDNAv2 will be slower (than IDNA2008) and the difference between table
> based and rule based is significant, as is exclusion vs inclusion
> MD - process for how context rules change a concern, lack of mappings is a
> concern, argues for mapping only for lookup, not for registration, 2003
> compatibility with some exceptional characters
> VC - ZWJ? ZWNJ??
> MD - see UTR/46
> PAF - re: mapping, excellent example why WG moves slowly, first draft of a
> lookup mapping written some time ago, if important, do something about it
> PH - not fair
> MD - was told a mapping draft would not be welcome, there is a text in the
> UTC list, mentions context rules and need for implementation
> VC - moving on, Jamos permitted under IDNAv2 (Jamo slide), removed under 08
> PH - irrelevant under 2003 because they're mapped, in non-mapping protocol,
> must get rid of. Not true in mapping protocol
> Dowon Kim (DK) - strongly recommend Jamo not allowed in 08
> MD - disagree with PH, jamo in syllables, but leading jamo (old hangul
> chars)
> PH - only for ancient syllables
> VC - important to satisfy Koreans, not get tangled again
> MD - two (not three) possibilities: (1) jamo can occur under '03, (2) v2
> model, registry and clients to ban
> VC - the "extra dots" code points
> DK- Korean internet community doesn't want Jamo allowed under v2
> (Andrew Sullivan's jabber log ends)
> VC - observation slides (0), (1) -- canonical representation may be useful,
> canonical IDNs slide
> MD - ambiguity is the wrong term, in 03 a unicode label turns uniqeuly to a
> domain name, the reverse path is where there is an ambiguity, e.g., final
> sigma. (2) can preserve symmetry between U and A labels but not the
> assumption that only the canonical form is stored or used (unicode urls in
> email user expectation)
> VC / MD - JK's work on what a domain slot in discussion of local mapping
> (M-label)
> PH - vehemently agree w/PAF, mapping has to be very carefully handled, very
> precise where and what kind of mapping we're talking about
> CK - (1) IDN guidelines could or should go into a BCP document, (2) the .gr
> registry would greatly appreciate it if people who aren't registry operators
> working in greek would stop representing .gr's issues and positions (yeah!!!
> scribe)
> PAF - rules agree with MD?
> JK - (something i didn't catch, scribe)
> DK(?) - mapping is essential
> James Seng (JS) - half-width, full-width mapping has to be done somewhere
> VC - if non-canonical forms are not exported ...
> JS - non-IDN-aware A-labels, IDN-awere U-labels, so for IDN-unaware,
> A-label is canonical, for IDN-aware, U-label is canonical
> MD - end up with soup transporting Unicode and A-labels, reference to TR46
> on mapping
> HA - disagree with MD, wild variety of non-sensical representations not as
> useful as cononical form, IETF should define these canonical forms. appendix
> reference (to MD's TR46 reference, supra, scribe)
> Dave Crocker (DC) - canonical form offers architectural advantages, agree
> with HA
> Ucido(?) - CJK mapping makes canonical U-label
> Eric van der Pool (EvdP) - wants U-label restricted to SMTP, but for web,
> no restriction, then combine best ideas of both 08 and v2
> JK - tradeoffs ... worried about interoperability, many more IDNs in things
> we've not seen in 5+ years, variant forms make for more potential risk,
> discourage old (03) stuff
> VC - discusses 08 -> 03 dual lookup (in appendix), IRI/URI at
> protocol-specification level
> MD - there's "reasonable" and "unreasonable", but people think these things
> are reasonable: u-umlaut, full-width, etc. -- this won't go away, local
> mappings would be a disaster.
> Ted Hardie (TH) - in Bill Manning's absence in the role of the "Bad Idea
> Fairy" (1) if xn-- and xo-- are a bad idea (two theories with a signal), why
> is two theories without a signal (the "compromise" mentioned between 03 and
> 08, above) not just as bad (or worse)?
> EvdP - (something i missed, scribe)
> PAF - xmpp, jabber retain identifiers, case independent matching, mentions
> Pete Resnik's invention of stringprep -- what's pain now, not 2bn users
> later (for the xmpp user base)
> JK - multiple forms a bad idea
> EvdP - new protocol jabber/xmpp, very old protocol DNS, between them is the
> "web world" and it is not this group's (idnabis) decision what they (the web
> world) do
> ----------
> break
> ----------
> VC - test a thory - value for canonicalization, poses question "do you
> disagree with canonical forms as useful?"
> MD - mentions steps to a canonical form (CF), refine and identify canonical
> definition form
> VC - if we adopt that (CF as useful), what else should we do, if anything,
> transition?
>   (a) accept the pain soon, strict canonical
> or (b) what else not increassing pain?
> or (c) 08 +v2 anyone?
> or (d) v2 anyone?
> EvdP - strongly object to not being allowed to pick good features from both
> 08 and v2, if web community goes off and does its mappings (DENIC reference)
> it could be bad
> VC - asks no discussion of specific chars (the DENIC reference)
> MD - if there is a mapping step in 08, that has a dramatic effect on
> eszett, ZWNJ, etc. if we have to choose right now between two, hard choice
> VC - if unassigned, unallocated codepoints aren't looked up, then what is
> needed?
> HA - three choices:
>   (a) 08 as is, mapping informative in an appendix
> or (b) 08 with mapping required on lookup
> of (c) v2. nobody seems to what to change bidi (08), protocol, tables, etc,
> the status of mapping in the protocol is the sticking point. details later,
> pick one
> VC - if pursue mapping & incorp. in 2008 structure, is that acceptable?
>   q1: how many people would object to moving ahead with 2008 as currently
> stands?
>   q2: use 2008 as basis, incorporate mapping (on lookup only, scribe)?
>   q3: use v2?
> TH - mentions the difference between normative rule and optional appendix
> HA - current documents have an appendix
>
> scribe vote count: four object to (a), more object to (c)
>
> VC - ok, (b), how to overcome limitations of IDNA2008 as it stands?
> PH - add a non-optional non-appendix, something to tell people what to do
> with inputs
> JS - suggesting a BCP (separate document)
> PAF - don't care if separate document, appendix, but need mapping, if
> mapping it MUST ... don't want fluffy definition
> VC - mapping during lookup, not registration, using the canonical form
> MD - agree, but needs to be a requirement, for loop somewhere in 5.2 to 5.4
> (protocol doc section refs, scribe), but in 4.x (ditto) MUST NOT map in
> registration, store in U-label form
> Pete Resnick (PR) - pass
> VC - is there consensus for IDNA2008 and try to include non-optional
> (lookup only) mapping?
> MD - and to include a SHOULD for storage?
> VC - yes
> JK - permanent or transitional?
> VC- transitional for the purposes of backward compatibility
> PH - need time
> VC - there is consensus to proceed on this (08 + lookup mapping)
> PAF - unhappy with mapping is a MUST
>
> Meeting ends at 11am. Blue sheet reminder and collection.
>
>
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090406/60c6fe5c/attachment-0001.htm