Re: [jig] SSAC report on Single Character IDN TLDs

[Avri Doria <avri@xxxxxxx>]

Hi,

Well a IAB stmt that refers to the Liman/Abley draft came out yesterday.

http://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook/

it is a terse document and at times takes work to parse, but I do not see how 
this would refer to this WG's specific subject.  But I only read it once.

Certainly stmts like the following make me cautious.

> 2. Internationalized strings encoded according to the IDNA2008 specification 
> [RFC5891] [RFC5892] MUST be permitted in general, but the set of Unicode 
> characters which are permissible in TLD U-labels MAY be constrained in order 
> to satisfy other requirements. The most conservative interpretation of this 
> constraint is the “only alphabetic requirement”.

but they also say:

> The most conservative interpretation of the constraints set by [RFC1123] is 
> that a TLD is ‘alphabetic’ only. The specification of this interpretation in 
> the IDNA context would not allow numbers, symbols such as punctuation marks, 
> or diacritics in either A-labels or U-labels, except in A-labels that begin 
> with ‘xn--’.
> 

so maybe it is ok.

The other strange one is:

> 4. The syntax definition SHOULD be compatible with existing assumptions by 
> application developers and users, to the extent that those assumptions can be 
> determined.


And while SHOULD means there are occasion when it MAY NOT, still being 
restricted to what existing applications can do, seems limiting.  It is 
certainly something that should be noted and approached with care., but 
avoidance seems problematic.  But this does intersect, perhaps, with the 
universal adoption plans.

I see noting that impinges in the single character u-label issue.  But I admit 
I might have missed it.

avri




avri

On 3 Feb 2012, at 14:24, Avri Doria wrote:

> 
> Hi,
> 
> This is not an IETF product.
> This is an individual draft that is being proposed.  albeit the 6th revsion 
> of the individual proposal.
> In fact it is an individual proposal being made by an ICANN 
> volunteer/consultant and an ICANN employee.
> 
> In fact at this point in the IETF draft cycle, it would actually be useful 
> for an ICANN policy group to review it and determine whether it is something 
> we support or not.  And perhaps even make an IETF comment before the IAB acts 
> on it.
> 
> It is certainly not an IETF end-product that should be seen as controlling 
> over ICANN policy requirements.
> 
> avri
> 
> 
> On 3 Feb 2012, at 13:56, Gomes, Chuck wrote:
> 
>> 
>> Forwarded with Patrik's approval.
>> 
>> Chuck
>> 
>> -----Original Message-----
>> From: Patrik Fältström [mailto:patrik@xxxxxxxxxx] 
>> Sent: Friday, February 03, 2012 11:56 AM
>> To: Gomes, Chuck
>> Cc: Julie Hedlund; edmon@xxxxxxxxxxxxx; 'jig'
>> Subject: Re: [jig] SSAC report on Single Character IDN TLDs
>> 
>> The work to update the RFC that say what characters are allowed. My personal 
>> interpretation say that it specifically touches the M* class of code points, 
>> as I think there is agreement of L* class code points.
>> 
>> See http://tools.ietf.org/html/draft-liman-tld-names-06
>> 
>> SSAC have been in touch with IAB, and I hope that IAB will say something on 
>> this matter.
>> 
>> I hope this posting to JIG might be possible to be approved, or you Chuck 
>> might be able to forward this to the list?
>> 
>>  Patrik
>> 
>> On 3 feb 2012, at 17:31, Gomes, Chuck wrote:
>> 
>>> Thanks Julie.  It would be helpful to know what IETF recommendations Patrik 
>>> is referring to that would be overridden.
>>> 
>>> Chuck
>>> 
>>>> -----Original Message-----
>>>> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of
>>>> Julie Hedlund
>>>> Sent: Friday, February 03, 2012 9:40 AM
>>>> To: edmon@xxxxxxxxxxxxx; 'jig'
>>>> Cc: Patrik Fältström
>>>> Subject: Re: [jig] SSAC report on Single Character IDN TLDs
>>>> 
>>>> 
>>>> Dear Edmon,
>>>> 
>>>> Since he does not have posting rights to this list, Patrik Faltstrom,
>>>> SSAC
>>>> Chair, has asked me to forward the following message.
>>>> 
>>>> Best regards,
>>>> 
>>>> Julie
>>>> 
>>>> Julie Hedlund
>>>> Director, SSAC Support
>>>> 
>>>> -------------Forwarded from Patrik Faltstrom---------------------
>>>> 
>>>> Edmon,
>>>> 
>>>> I do not think you actually say things differently from what the SSAC
>>>> says
>>>> in SAC052. But, there are a few points I want to make:
>>>> 
>>>> Yes, normal review of confusability can occur. No new process is
>>>> needed.
>>>> But, instructions for how to do the evaluation must be clear. Whether a
>>>> character is confusing or not is not black or white. There is a sliding
>>>> scale, and it must be made clear when a character is to be approved and
>>>> not.
>>>> 
>>>> These instructions for approval of IDN TLD labels were just revised and
>>>> that
>>>> for the SSAC indicates that the rules currently in use are not stable,
>>>> but
>>>> good enough for labels longer than one character.
>>>> 
>>>> Specifically the SSAC wants to point out that what is one character
>>>> might be
>>>> more than one code point, and then we start to move into an area where
>>>> the
>>>> IETF does have ongoing activities. It is the SSAC view that ICANN
>>>> should not
>>>> override recommendations from the IETF.
>>>> 
>>>> Finally, yes, there are cases that are "simple" and it should be
>>>> possible to
>>>> identify which ones they are. The SSAC does not say all one-character
>>>> strings are dangerous, or that the current confusability rules are
>>>> broken.
>>>> 
>>>> Only that the instructions to the evaluation teams does not describe
>>>> the
>>>> case of one character. Remember, it is very specific regarding two
>>>> characters that might be confusing.
>>>> 
>>>> Patrik
>>>> 
>>>> 
>>>> On 2/2/12 8:28 PM, "Edmon Chung" <edmon@xxxxxxxxxxxxx> wrote:
>>>> 
>>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> Please find the SSAC report on Single Character IDN TLDs:
>>>>> http://www.icann.org/en/committees/security/sac052.pdf
>>>>> 
>>>>> The summary of findings are:
>>>>> Finding 1: Single-character TLDs are more likely to cause user
>>>> confusion than
>>>>> TLDs with more than one character.
>>>>> Finding 2: No other significant security concerns are apparent with
>>>> the
>>>>> delegation of single-character TLDs.
>>>>> Finding 3: Current work on string similarity and variant issues has
>>>> not been
>>>>> completed.
>>>>> 
>>>>> Recommendations:
>>>>> 1. Given the potential for user confusion and the currently
>>>> unfinished work on
>>>>> string similarity and IDN variants, the SSAC recommends a very
>>>> conservative
>>>>> approach to the delegation of single-character IDN top-level domains.
>>>> In
>>>>> particular, ICANN should disallow by default the delegation of all
>>>>> single-character IDN TLDs in all scripts; exceptions are possible,
>>>> but only
>>>>> after careful consideration of each individual case.
>>>>> 2. Because important relevant work on string similarity, IDN variant
>>>> issues,
>>>>> and TLD label syntax is currently underway within ICANN, the Internet
>>>>> Engineering Task Force (IETF), and other bodies, ICANN should review
>>>> the
>>>>> Findings of this report, and any policies that it adopts in response
>>>> to
>>>>> recommendations made in this document, no later than one year after
>>>> the three
>>>>> work items mentioned above
>>>>> have been completed.
>>>>> 
>>>>> 
>>>>> Think the report is a good read.  However, the logic of the report
>>>> seems
>>>>> confusing:
>>>>> - If possible user confusion is the only concern
>>>>> - Then the issue comes down to work on string similarity
>>>>> - If the SSAC believes that the work on string similarity is not
>>>> complete
>>>>> - Then the whole new gTLD process should be called to stop
>>>>> 
>>>>> The report explains that in cases of 2 or more characters, where one
>>>> character
>>>>> is non-similar, then the string can be considered non-confusing.  The
>>>> logical
>>>>> conclusion for cases of 1 character should be the same, where one
>>>> character is
>>>>> non-similar, then the string can be considered non-confusing.
>>>>> 
>>>>> In cases of 2 or more characters, there exists cases where both (or
>>>> all)
>>>>> characters are similar, then the string is considered confusing. In
>>>> such
>>>>> cases, the string contention process or the first-come-first-served
>>>> rule comes
>>>>> into effect.
>>>>> 
>>>>> The conclusion of the SSAC report seems to be in conflict with such
>>>> contention
>>>>> and FCFS rule. i.e. if the SSAC findings and recommendations hold for
>>>> single
>>>>> characters, there is no reason why the same conclusions and
>>>> recommendations
>>>>> will not hold for 2 or more character strings (which was in effect
>>>> the
>>>>> conclusion of the JIG report).
>>>>> 
>>>>> More specifically:
>>>>> - the result of 2 TLD strings considered confusing is that they go
>>>> through
>>>>> contention process (and FCFS rule by round)
>>>>> - that should be the same regardless of whether the TLD strings are 1
>>>> or 2 or
>>>>> 3 characters or more
>>>>> 
>>>>> The SSAC findings simply states that there may be more likelihood of
>>>> strings
>>>>> that may be considered similar/confusing, but does not explain why
>>>> when such
>>>>> similarity/confusability occurs the same process as 2 or more
>>>> characters could
>>>>> not be applied.  The logical conclusion should be simply to warn the
>>>> applicant
>>>>> that there may be more cases which may require contention process
>>>> than for
>>>>> multi-character TLD applications.
>>>>> 
>>>>> I believe we have some SSAC members on this list as well.  It would
>>>> be good to
>>>>> hear from them what the logic is behind the recommendation and why it
>>>> believes
>>>>> it does not impact 2 or more character strings.
>>>>> 
>>>>> Edmon
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
>