ICANN ICANN Email List Archives

[jig]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [jig] Single character labels question framing

  • To: jig <jig@xxxxxxxxx>
  • Subject: Re: [jig] Single character labels question framing
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Wed, 31 Mar 2010 00:27:59 -0400

Hi Terry,

Are you saying that you believe there are security risks specific to single 
character u-labels?

thanks

a.

On 30 Mar 2010, at 22:32, Terry L Davis, P.E. wrote:

> Avri
> 
> I was just back from a weekend with our daughter and grand-daughter in
> Anaheim and I over-slept not joining till about 4:40AM instead of 4AM.  So I
> missed most the discussions.
> 
> Q1- I think I agree with you here.
> 
> Q2- Again I think I agree.
> 
> Q3- This seems to require some serious discussions, I think.
> 
> All that said, my initial primary concern is simply "how do we get the tools
> to validate the puny-code stored in DNS"?  We have a stored value that is
> not humanly intelligible in either latin or the orginal script.  I spend a
> good part of any day worrying "cyber security" in one form or another, so
> having "certified" tools that provide that translation from stored puny-code
> to humanly readable script to me is a key need.  We will need it for most of
> our security tools; anti-virus, firewalls, etc.
> 
> I think "white lists" and such will be part of our discussions as we go
> forward.
> 
> Take care
> Terry
> 
> -----Original Message-----
> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Avri
> Doria
> Sent: Tuesday, March 30, 2010 5:17 AM
> To: jig
> Subject: [jig] Single character labels question framing
> 
> 
> Hi,
> 
> I hope it is ok, for an observer to the group to ask framing questions this
> early in the process.  If the questions are premature (or stupid), please
> ignore it.
> 
> 
> While I understand that there are financial and policy issues to be
> discussed in terms of IDN single character (like which are ccTLDs and which
> are gTLDs and is there some sort of premium on single character idn labels)
> , I think we need to be careful in our conversion to distinguish which sorts
> of labels we are talking about at any moment. 
> 
> 
> A single character a-label is fundamentally different from a single
> character u-label (though occasionally they look alike).
> I also think that the IDN WG indicates that there should not be a blanket
> prohibition of single character u-labels, though there are considerations to
> be considered.
> 
> So in some sense I think this discussion may boil down to the following
> questions:
> 
> Question 1: do single character a-labels remain prohibited? 
> 
> Is that even an issue for this group?  I think probably not
> 
> Question 2: which, if any, single character u-labels should be prohibited
> and why?
> 
> E.g. extended ASCII u-labels or Cyrillic u-labels that resemble LDH-labels
> are problematic from the point of view of confusion and should probably be
> prohibited.  But otherwise what reason could there be for limiting single
> character idn u-labels?
> 
> Question 3: for those u-labels not prohibited what policy conditions
> pertain?
> 
> This might be the bulk of the discussion.
> 
> Another differentiation people could make, and seem to make in discussions,
> is which u-labels are 'words'.  Somehow, it seems that stating that if a
> single u-label represents a real-world word it is somehow more acceptable
> then just a single character u-label that does not represent a real-world
> word. I am not sure I understand why this would be the case, though the
> financial considerations may be different there is no reason that any TLD
> needs to represent a word - as the set of existing TLDs shows there are very
> few words among them.
> 
> Finally, reading the IDN WG report with these issues in mind is somewhat
> confusing to me in that they do not seem to have made such distinctions.  I
> would be curious to know whether this sort of analysis was considered.
> 
> Again if this note is out of place or badly timed, please ignore and excuse.
> 
> 
> a.
> 
> 
> 
> 
> 
> 
> 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy