Re: Re: stability

JFC (Jefsey) Morfin wrote:
> At 02:53 16/03/2005, Erik van der Poel wrote:
> 
>> Martin v. Löwis wrote:
>>
>>> What is much more relevant is how further constraints in the registry
>>> (beyond those imposed by IDNA) get implemented. Only when that is
>>> sufficiently settled and deployed, considering *updates* to IDNA
>>> should start.
>>
>> I disagree. The IETF should not wait for any of the registries to do 
>> anything before publishing new drafts or RFCs. The registries are not 
>> the only other players here. We have application developers and zone 
>> administrators depending on our work too.
> 
> Fully true. But we are in a real world. If you propose anything again 
> without the support of the Registries you will have a lack of 
> understanding, adherence and support. Also what you will propose will be 
> less reviewed from different point of view and will have more risks to 
> have its own flaws. You will not be able to tell the Registries they 
> shared in the mistake they have to share in the fix. 

I agree, and I can see why you react in this way to my email, but please 
look again at Martin's email. If we followed Martin's advice, we would 
wait quite a long time before even *considering* updates to IDNA. I 
think it's reasonable to *consider* changes and even to write drafts 
*before* the registries deploy further constraints.

Of course, we must involve the registries in the draft review process.

Re: Re: stability

--On Tuesday, March 15, 2005 5:53 PM -0800 Erik van der Poel 
<erik <at> vanderpoel.org> wrote:

> Martin v. Löwis wrote:
>> What is much more relevant is how further constraints in the
>> registry (beyond those imposed by IDNA) get implemented. Only
>> when that is sufficiently settled and deployed, considering
>> *updates* to IDNA should start.
>
> I disagree. The IETF should not wait for any of the registries
> to do anything before publishing new drafts or RFCs. The
> registries are not the only other players here. We have
> application developers and zone administrators depending on
> our work too.

Yes.

And let me add one observation.  At the moment, "the registries" 
(remember that there are around 275 of them) are going in every 
direction possible.  ICANN's guidance, based to some extent on 
the advice that IESG gave them, is so vague as to permit almost 
any interpretation, clearly doesn't work for some important 
cases (encouraging even more interpretations), and is being 
outright ignored by some ccTLDs.   If we want the registries to 
do something, we are going to need to provide some more specific 
guidance and we are going to need to document why it is a good 
idea.  The same observation applies to application writers: 
unless we actually change the standard (the algorithms or the 
tables), all we are doing is offering advice.  That advice will 

Re: character tables

Quoting Erik van der Poel:

> I've been told that some communities use a set of letters that are 
> currently encode in two different ranges of the Unicode space 
> (e.g. Latin and Cyrillic). Today, my idea is that these 
> communities can "occupy" their "own" part of the DNS space, for 
> example a .tld or a .2ld.tld.

The community occupying 2ld.tld doesn't write the rules that 
determine the character repertoire available for use in .tld, and 
can therefore not necessarily represent even its own name as it 
might ideally prefer. The 2ld.tld folks do get to make the 
corresponding decision for 3ld.2ld.tld (if permitted in .tld 
policy). In the reasonably commonplace situation where all 
subdomains under 2ld.tld are operated by a single entity, coherent 
rules can be applied throughout. This situation is, however, by no 
means the only one that pertains, and it certainly does not apply to 
the point of delegation under a TLD.

Most people would probably use the term 'language' to designate the 
attribute of community identity that is expressed by its use of a 
certain set of letters. A community wishing to project that identity 
into the domain namespace will therefore need either to locate a 
parent domain that accepts the registration of names including the 
needed characters, or convince what would otherwise be the most 
desirable parent to implement that support. Languages are, however, 
frequently shared by numerous communities without any other aspect 
of shared identity, and identical sets of letters often appear in 
more than one language. (This is one of the reasons why gTLDs so 
prominently appear in the present discussion.)

Re: Re: character tables

----- Original Message ----- 
From: "Adam M. Costello" <idn.amc+0 <at> nicemice.net.RemoveThisWord>
To: <idn <at> ops.ietf.org>
> I still like the idea of allowing every TLD to have one synonym-TLD per
> script, although we might need to recognize some scripts in addition to
> the Unicode scripts, for example, the subset-of-(Latin-plus-Cyrillic)
> script that you allude to.

   I appreciate this idea of  allowing every TLD to have one synonym-TLD per
 script  in general. however, in China, Simple Chinese Characters and Traditonal Chinese Characters are
equality. So the TLDs which have both Simple Chinese Characters and Traditonal Chinese Characters
should be authorized to the same organization.

YAO Jiankang

 

mailing list

gTLD Registry Constituency's statement

The gTLD Registry Constituency issued a statement about the homograph 
attack: http://www.icann.org/topics/news022305.html

    For languages that use the LDH characters and for which a registry
    does not have explicit inclusion tables, the LDH table may be used
    as a default table for registration requests tagged with those
    languages, pending fully developed inclusion tables becoming
    available during the course of dialogue between the registries and
    their reference groups in the respective language communities. The
    decision to apply the LDH default to a given language will be made
    in consideration of the requirements applying to the other scripts
    that might appear in the full inclusion table, such as the
    restrictions on bidirectional strings imposed by the IDNA standard.

    These measures will be implemented in the shortest possible time by
    all of the IDN registries listed above.

AFAIK, only com/net has not implemented the restriction in the paragraph 
quoted above. This may be an indication that Verisign will essentially 
stop allowing languages for which they have no inclusion tables? If 
that's the case, it's certainly good news for the community.

Nothing has been said about the pre-existing names in those registries, 
and how they would deal with them in the case of renewals.

wil.

RE: punctuation

--On Thursday, 24 February, 2005 11:30 -0800 Michel Suignard
<michelsu <at> windows.microsoft.com> wrote:

> Erik, I don't think it is useful to engage on a debate about
> web site design and the appropriateness of multi node web
> site. All your points are probably valid there but they are
> mostly orthogonal to the discussion here.
> 
> I am still not convinced that reversing the display order of
> domain names is a good idea. And there are many more reasons
> that the ones I already gave, such as disruption of the
> current logical order. Especially if we can convince quickly
> ICANN and most registry orgs to effectively deprecate usage of
> all homographs of URI reserved characters. This seems to me a
> more realistic approach and it doesn't prevent browsers to pay
> attention to those homographs when they are detected in IRIs.

Michel,

If we can reach some reasonable consensus about what characters
(URI-reserved or otherwise) that ICANN should deprecate, I'm
more than happy to put my liaison hat on and forcefully carry
the message over there.  

But we need to remember that ICANN's authority, and hence the
impact of their deprecating something, is very limited.   In
particular:

	* For the gTLDs, they can create additional guidelines
	or modify the existing ones, but it is not clear how
	forcefully they can, or will, apply them if some gTLDs
	decide to ignore those guidelines.  As has been pointed
	out, the example that started these thread could almost
	certainly not have been registered if the intent of the
	existing guidelines had been observed by all relevant
	domains.
	
	* For the ccTLDs, ICANN can recommend and advise, but
	their enforcement power is between "slight" and "none",
	at least unless there is a clear violation of a standard
	(see below).
	
	* For any domain below the second level -- i.e., a
	registration in a TLD -- ICANN is generally not only
	completely lacking in authority but most of the relevant
	domain administrators don't even have a way to hear
	about the fact that ICANN has deprecated (or otherwise
	recommended against the use of) some characters.

So, yes, let's do something.  Note, fwiw, that they have opened
a public comment forum at idn-homograph <at> icann.org -- see the
"IDN Homograph Concerns" section on
http://www.icann.org/topics/idn.html.

But, if we think particular characters are bad news, we need to
follow up whatever actions browser-writers take spontaneously,
and whatever we ask ICANN to do, by deprecating them in
nameprep.  If those nameprep changes are implemented, then the
characters get rejected at both registration and lookup time, in
a consistent way, and get rejected in any domain and at any
level of the tree.   And violating the standard is something
that gives ICANN at least a little leverage, since most
registries have agreed -- as a consequence of accepting RFC 1591
if not by explicit agreements with ICANN, that ignoring
standards is a Bad Thing.

      john

homographs of the delimiters aka syntax chars

I've added a table of protocols (DNS, URI and email) with their 
delimiters to the doc at:

http://nameprep.org/

Please send me your additions.

Also, readers on this list may be interested to see:

http://www.unicode.org/reports/tr36/tr36-2.html

This doc calls them "syntax characters".

Erik

RE: another BIDI/ASCII representation problem on w3.org

That comment from the public-iri list has been disposed a long time ago by the authors of the now RFC 3987 (IRI).
BIDI introduces its own set of security issues on IDN and IRI but these issues are not homograph related.

Furthermore, the recommendation concerning mix of rtl and ltr characters in IRI (such mix may make the host
name in a IRI visually undetectable because of the mix with with path and query parts) is only a 'should' in
RFC speak, because an IRI (as well as URI) may be opaque (i.e, never visually displayed). However it is
pretty clear that it is expected that a user agent displaying an IRI containing bidi content would enforce
the IRI bidi restrictions. In all cases the IDN bidi restrictions apply.

Please refere to the IRI RFC for more details.

Michel

-----Original Message-----
From: owner-idn <at> ops.ietf.org [mailto:owner-idn <at> ops.ietf.org] On Behalf Of Soobok Lee
Sent: Wednesday, February 23, 2005 1:03 AM
To: Soobok Lee
Cc: idn <at> ops.ietf.org
Subject: Re: [idn] another BIDI/ASCII representation problem on w3.org

Soobok Lee wrote:

>
> Even stringprep-validated name label maybe cause problems when being 
> prefixed by

name lable ==> BIDI name lable.
this label may be arabic or hebrew one.

>
> digits-only label or digits-only mailbox names. If we should redesign 
> stringprep/nameprep we should take the following BIDI issue together.
>
> Please see this article from W3.org:
>
> http://lists.w3.org/Archives/Public/public-iri/2003Sep/0000.html
>
> Soobok Lee

another BIDI/ASCII representation problem on w3.org

Even stringprep-validated name label maybe cause problems when being 
prefixed by
digits-only label or digits-only mailbox names. If we should redesign 
stringprep/nameprep
we should take the following BIDI issue together.

Please see this article from W3.org:

http://lists.w3.org/Archives/Public/public-iri/2003Sep/0000.html

Soobok Lee

Re: Re: nameprep, IDN spoofing and the registries

At 21:30 22/02/2005, Erik van der Poel wrote:
>JFC (Jefsey) Morfin wrote:
>>2. could someone list all the Unicode codes to blacklist that way?
>
>It will take a while to create a relatively complete table of homographs, 
>but here are a couple of starting points:
>
>https://bugzilla.mozilla.org/attachment.cgi?id=174139
>https://bugzilla.mozilla.org/show_bug.cgi?id=279099#c192
>
>Also, I've been thinking of writing a program that would look at the 
>"cmap" of every font on a Windows box and check to see which pairs of 
>Unicodes have the same glyph index (which leads to identical display).

This would help.
But a ccTLD managing IDNs in computer environment and wanting to avoid any 
mistake, manages names in most of the case under the ACE format. In ASCII. 
I am not sure about existing dispute cases, but we consider that two IDNs 
are different if they have different in ACE format?
Anyway, I answer you below.

>>3. could someone point a Perl code to use to enter a IDN and to get it 
>>properly punycoded, which could use such a list.
>
>I don't know about Perl, but I believe Python has IDN.

Thank you, but as I said, I have no resource on this. So what would be 
great wold be that this list would actually help preparing a Draft - may be 
someone of more technical skill and competence would be interested in 
leading it? So we can start working on something real. I listed my pratical 
needs. I suppose others would have others to add.

Stephane is key person in supporting many ccTLDs in real life. I am sure he 
will be of great help. So would Gervase's with the ability to test in 
Firefox environment.

I have reported the problem and my request on the ccTLD list. I asked about 
the additional requirements they might have. I will inform this list of any 
additional demands they may have IRT a practical solution for them. I also 
documented that my concern was not about the phishing issue but about the 
ccTLD owns operations. This leaves the legal aside and may be more 
motivating since their own Registry could be the first victim of a 
confusion (in Whois display, for example).

jfc