From nobody Mon Aug 4 03:06:46 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEA91B29A6 for ; Mon, 4 Aug 2014 03:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.232 X-Spam-Level: ** X-Spam-Status: No, score=2.232 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7gMXxX68A1J for ; Mon, 4 Aug 2014 03:06:41 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF331B299A for ; Mon, 4 Aug 2014 03:06:41 -0700 (PDT) Received: from 21.104.14.81.rev.sfr.net ([81.14.104.21]:26949 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XEFA7-0001Sz-Gu; Mon, 04 Aug 2014 03:06:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Aug 2014 12:06:30 +0200 To: rhill@hill-a.ch,"Eliot Lear" , "Stephen Farrell" , "Avri Doria" , From: JFC Morfin In-Reply-To: References: <53DF369A.2080306@cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2090483285==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/187ZD0b1Djc7UlhPuKncw1DGDDE Cc: "iucg@ietf.org" Subject: Re: [iucg] [ianatransition] Jurisdiction (was Composition of the ICG) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 10:06:44 -0000 --=====================_2090483285==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 11:04 04/08/2014, Richard Hill wrote: >You are right, the term "Internet technical community" has also >frequently been used. But I still don't understand why we should >use any term other than the one used by NTIA, which is "global >multi-stakeholder community". This seems correct thinking if you want to answer the NTIA question. This becomes anecdotal when you consider the situation created by the NTIA abdication. Once gone, gone its particular terminology. As usual this vacuous debate reflects the common lack of fundamental architectonic home/common work. >Regarding people who don't have access to the Internet, they can >contribute through representatives that do have access, in >particular through civil society groups that work to exapand Internet access. The representatives they vote and pay for are their Governments, the NTIA currently disregards. I accept that the NTIA is pragmatically (but not democratically) right. Their position is not due to a lack of representativeness of the states but to an evaluation of a lack of adequate architectonical knowledge and thinking by ***everyone***, the USG astutely tries to strategically takes advantage from. When I say everyone I include myself: I was laid off the global network leadership in 1986 because I only partly understood their trick (God forgive: I did not read the Einsenhower farewell address by then :-)). The NTIA created virtuality, has lead to the mailing list irreality, where human rights are defended by GAFATM employees and sponsored academics against the governements of the people by the people for the people. However, there is H.R. 20: http://www.demos.org/publication/government-people-act, the proposed "The Government By the People Act". I will be myself interested in the I*core positions along the "The Governance By the IUsers RFC" they should start discussing first. jfc >Best, >Richard >-----Original Message----- >From: Eliot Lear [mailto:lear@cisco.com] >Sent: lundi, 4. août 2014 09:31 >To: rhill@hill-a.ch; Stephen Farrell; Avri Doria; ianatransition@icann.org >Subject: Re: [ianatransition] Jurisdiction (was Composition of the ICG) > >Hi again Richard, >On 8/4/14, 9:10 AM, Richard Hill wrote: >>Well, then different definitions are used in different forums. The >>definition I've heard during the past 10 or so years is the one >>that Avri referred to. >I think there's been some confusion because at times, particularly >in the ITU context, the term "Internet technical community" has been >used to refer to not just the I*s but also operators and their >vendors. At least to me, that's a slightly different kettle of fish. >> >>Anyway, I think that the "global multi-stakeholder community" also >>includes people who don't at present use, or even have access to, >>the Internet, so that is still broader than the definition below. >Of course if someone has does not have an email address, then one >will have great difficulty submitting comments. >Eliot > >_______________________________________________ >ianatransition mailing list >ianatransition@icann.org >https://mm.icann.org/mailman/listinfo/ianatransition --=====================_2090483285==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 11:04 04/08/2014, Richard Hill wrote:
You are right, the term "Internet technical community" has also frequently been used.  But I still don't understand why we should use any term other than the one used by NTIA, which is "global multi-stakeholder community".

This seems correct thinking if you want to answer the NTIA question.
This becomes anecdotal when you consider the situation created by the NTIA abdication. Once gone, gone its particular terminology. As usual this vacuous debate reflects the common lack of fundamental architectonic home/common work.

Regarding people who don't have access to the Internet, they can contribute through representatives that do have access, in particular through civil society groups that work to exapand Internet access.

The representatives they vote and pay for are their Governments, the NTIA currently disregards.

I accept that the NTIA is pragmatically (but not democratically) right. Their position is not due to a lack of representativeness of the states but to an evaluation of a lack of adequate architectonical knowledge and thinking by ***everyone***, the USG astutely tries to strategically takes advantage from.

When I say everyone I include myself: I was laid off the global network leadership in 1986 because I only partly understood their trick (God forgive: I did not read the Einsenhower farewell address by then :-)).

The NTIA created virtuality, has lead to the mailing list irreality, where human rights are defended by GAFATM  employees and sponsored academics against the governements of the people by the people for the people.

However, there is H.R. 20: http://www.demos.org/publication/government-people-act, the proposed "The Government By the People Act". I will be myself interested in the I*core positions along the "The Governance By the IUsers RFC" they should start discussing first.

jfc


Best,
Richard
-----Original Message-----
From: Eliot Lear [ mailto:lear@cisco.com]
Sent: lundi, 4. août 2014 09:31
To: rhill@hill-a.ch; Stephen Farrell; Avri Doria; ianatransition@icann.org
Subject: Re: [ianatransition] Jurisdiction (was Composition of the ICG)
Hi again Richard,
On 8/4/14, 9:10 AM, Richard Hill wrote:
Well, then different definitions are used in different forums.  The definition I've heard during the past 10 or so years is the one that Avri referred to.
I think there's been some confusion because at times, particularly in the ITU context, the term "Internet technical community" has been used to refer to not just the I*s but also operators and their vendors.  At least to me, that's a slightly different kettle of fish.
 
Anyway, I think that the "global multi-stakeholder community" also includes people who don't at present use, or even have access to, the Internet, so that is still broader than the definition below.
Of course if someone has does not have an email address, then one will have great difficulty submitting comments.
Eliot

_______________________________________________
ianatransition mailing list
ianatransition@icann.org
https://mm.icann.org/mailman/listinfo/ianatransition
--=====================_2090483285==.ALT-- From nobody Mon Aug 4 16:18:22 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4F1A042D for ; Mon, 4 Aug 2014 16:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.232 X-Spam-Level: ** X-Spam-Status: No, score=2.232 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_48=0.6, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR1u-w9Ubgn7 for ; Mon, 4 Aug 2014 16:18:18 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BF01A041B for ; Mon, 4 Aug 2014 16:18:18 -0700 (PDT) Received: from 21.104.14.81.rev.sfr.net ([81.14.104.21]:63680 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XERWC-00077L-Ku; Mon, 04 Aug 2014 16:18:17 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Aug 2014 01:14:42 +0200 To: Andrew Sullivan ,ianatransition@icann.org From: JFC Morfin In-Reply-To: <20140804213613.GZ34733@mx1.yitter.info> References: <20140804141507.GB34733@mx1.yitter.info> <20140804153525.GH34733@mx1.yitter.info> <53DFB351.2060801@meetinghouse.net> <20140804164819.GQ34733@mx1.yitter.info> <21471.62506.316620.467114@world.std.com> <20140804213613.GZ34733@mx1.yitter.info> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_87936281==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/AhdJDSOZ72Zwb4XgJ1KGuaLo2WE Cc: IAB , "iucg@ietf.org" Subject: Re: [iucg] [ianatransition] Disaster scenarios (was Re: Jurisdiction) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 23:18:20 -0000 --=====================_87936281==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear all, I am familiar with the mathematical theory of catastrophes, physical SOC (self-ordering criticality), precision computation and probalities. However, IANAL and I am unable to evaluate the pertinence of this IAB led legal debate. Is there a lawyer on this ICANN list who could help us in explaining what is the case? the IAB position? What Andrew does not want to explain? and the resulting risks for the users? I must accept that I am lost with the undecidability of the words I have put in bold characters. All I grasp is that, should an US Judge respect the US law, it might happen, under conditions I am unable to identify, that the whole internet might collapse. This seems to lead to the idea that the internet architecture should be updated and become US law-proof. And by the same token law-proof to any national legislation. This IAB opinion seems to leave us with two options: 1. only the international law applies, but the NTIA has refused it, since it would mean a multilateral agreement and States specific involvement (i.e. a part of the WCIT) 2. code is the law. In such a case the code is to be developped along some ethic to attain some esthetic. I know two of them: - WSIS: the information society (hence its communications) are to be people centered. - RFC 6852: the target is the huge bounty and innovation proceeding from competition.and markets economics. At 23:36 04/08/2014, Andrew Sullivan wrote: >Hi, > >On Mon, Aug 04, 2014 at 04:59:22PM -0400, Barry Shein wrote: > > > > If I were a network appliance manufacturer either I adhere to > > published standards/registries or should my finances suffer due to > > this my investors would have good reason to sue and likely win > > something, perhaps removal of officers or even financial remuneration. > >Yes. But I don't think we're talking about single actors in the >hypothetical cases we were talking about. That appears to be what >you're describing above, and it's certainly not what I meant. > >Let's return to the example posited earlier: some US court orders >ICANN to reallocate an address (contrary to some policy). The only >way ICANN can actually do that is to withdraw the entire block it >allocated to the RIR in question. Note that, as a practical matter, >the address would probably be allocated outside ARIN's service area, >because if it weren't, the order would presumably be against ARIN >instead. > >I believe that, under those circumstances, there is a significant >probability that the RIRs would decide to ignore the then-current >implementer of the IANA address policies, and that LIRs and ISPs and >so on would by and large follow the RIRs (or, I guess we might say in >this case, the NRO) in the new policies, despite what IANA had to say >on the matter. > >This would be, without any doubt, an extremely bad outcome for >everyone, in that there'd be a period of global confusion (and >whatever block of addresses was ordered transferred would be a total >mess). But it seems to me that the end result would almost certainly >be that people would stop using the IANA co-ordination mechanism, >because it had become corruped by an external power beyond the control >of participants. People would come up with a different answer, and >work out how to co-ordinate it, or else we'd lose the Internet. > >There is the possibility, of course, that the same US court would >order US ISPs and so on to use the US-based IANA and everyone else >would ditch it. This would also be very bad, in that there'd be the >US-model Internet and the everywhere-else model. It would also be >entertaining (in the way disaster movies are) to see such a rule >enforced, but I can imagine someone attempting to do it anyway. > >Now, I'm aware that others think that we need some mechanism that will >guarantee these sorts of disaster can't happen. I have argued that I >think that desire can't actually be satisfied (I'm not going to >rehearse that argument, because I said I wouldn't). > >Best regards, > >A I thank every help in order to best understand this.position of the IAB representative on this list. jfc --=====================_87936281==.ALT Content-Type: text/html; charset="us-ascii" Dear all,

I am familiar with the mathematical theory of catastrophes, physical SOC (self-ordering criticality), precision computation and probalities. However, IANAL and I am unable to evaluate the pertinence of this IAB led legal debate.

Is there a lawyer on this ICANN list who could help us in explaining what is the case? the IAB position? What Andrew does not want to explain? and the resulting risks for the users?

I must accept that I am lost with the undecidability of the words I have put in bold characters. All I grasp is that, should an US Judge respect the US law, it might happen, under conditions I am unable to identify, that the whole internet might collapse.

This seems to lead to the idea that the internet architecture should be updated and become US law-proof. And by the same token law-proof to any national legislation. This IAB opinion seems to leave us with two options:

1. only the international law applies, but the NTIA  has refused it, since it would mean a multilateral agreement and States specific involvement (i.e. a part of the WCIT)

2. code is the law. In such a case the code is to be developped along some ethic to attain some esthetic. I know two of them:
    - WSIS: the information society (hence its communications) are to be people centered.
    - RFC 6852: the target is the huge bounty and innovation proceeding from competition.and markets economics.


At 23:36 04/08/2014, Andrew Sullivan wrote:
Hi,

On Mon, Aug 04, 2014 at 04:59:22PM -0400, Barry Shein wrote:
>
> If I were a network appliance manufacturer either I adhere to
> published standards/registries or should my finances suffer due to
> this my investors would have good reason to sue and likely win
> something, perhaps removal of officers or even financial remuneration.

Yes.  But I don't think we're talking about single actors in the
hypothetical cases we were talking about.  That appears to be what
you're describing above, and it's certainly not what I meant.

Let's return to the example posited earlier: some US court orders
ICANN to reallocate an address (contrary to some policy).  The only
way ICANN can actually do that is to withdraw the entire block it
allocated to the RIR in question.  Note that, as a practical matter,
the address would probably be allocated outside ARIN's service area,
because if it weren't, the order would presumably be against ARIN
instead.

I believe that, under those circumstances, there is a significant
probability that the RIRs would decide to ignore the then-current
implementer of the IANA address policies, and that LIRs and ISPs and
so on would by and large follow the RIRs (or, I guess we might say in
this case, the NRO) in the new policies, despite what IANA had to say
on the matter. 

This would be, without any doubt, an extremely bad outcome for
everyone, in that there'd be a period of global confusion (and
whatever block of addresses was ordered transferred would be a total
mess).  But it seems to me that the end result would almost certainly
be that people would stop using the IANA co-ordination mechanism,
because it had become corruped by an external power beyond the control
of participants.  People would come up with a different answer, and
work out how to co-ordinate it, or else we'd lose the Internet.

There is the possibility, of course, that the same US court would
order US ISPs and so on to use the US-based IANA and everyone else
would ditch it.  This would also be very bad, in that there'd be the
US-model Internet and the everywhere-else model.  It would also be
entertaining (in the way disaster movies are) to see such a rule
enforced, but I can imagine someone attempting to do it anyway.

Now, I'm aware that others think that we need some mechanism that will
guarantee these sorts of disaster can't happen.  I have argued that I
think that desire can't actually be satisfied (I'm not going to
rehearse that argument, because I said I wouldn't).

Best regards,

A


I thank every help in order to best understand this.position of the IAB representative on this list.
jfc
--=====================_87936281==.ALT-- From nobody Mon Aug 4 16:38:48 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64FD1A058E for ; Mon, 4 Aug 2014 16:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXbNUrdVUwQn for ; Mon, 4 Aug 2014 16:38:42 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1F91A0880 for ; Mon, 4 Aug 2014 16:38:41 -0700 (PDT) Received: from mx1.yitter.info (c-76-118-173-172.hsd1.nh.comcast.net [76.118.173.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C2F638A031; Mon, 4 Aug 2014 23:38:39 +0000 (UTC) Date: Mon, 4 Aug 2014 19:38:35 -0400 From: Andrew Sullivan To: JFC Morfin Message-ID: <20140804233834.GA80342@mx1.yitter.info> References: <20140804141507.GB34733@mx1.yitter.info> <20140804153525.GH34733@mx1.yitter.info> <53DFB351.2060801@meetinghouse.net> <20140804164819.GQ34733@mx1.yitter.info> <21471.62506.316620.467114@world.std.com> <20140804213613.GZ34733@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/xKM3yMSPvqISRDIOZ9BL13vJ7-8 Cc: IAB , ianatransition@icann.org, "iucg@ietf.org" Subject: Re: [iucg] [ianatransition] Disaster scenarios (was Re: Jurisdiction) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 23:38:47 -0000 Dear colleagues, I must correct a misrepresentation from M. Morfin. On Tue, Aug 05, 2014 at 01:14:42AM +0200, JFC Morfin wrote: > pertinence of this IAB led legal debate. […] > what is the case? the IAB position? […] > to any national legislation. This IAB opinion seems to leave us with I do not speak for the IAB, and M. Morfin is familiar enough with IETF procedures to know that perfectly well. If the IAB had a position, it would produce it as an IAB statement, or as an IAB-track RFC. Given his frequent citation of various RFCs, I cannot tell whether M. Morfin has unexpectedly forgotten how the IAB works, or whether he intends to misrepresent the state of affairs in order to lead others astray. I am, it is true, a sitting member of the IAB. I do not speak for the IAB, however, and I don't think I have represented myself as speaking for it. (I'm also an employee, and don't speak for my employer; a Canadian, but don't speak for other Canadians; a US citizen, but don't speak for other USians; and so on.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Aug 5 00:32:09 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6B1B28D7 for ; Tue, 5 Aug 2014 00:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcIGxfb1Sq2w for ; Tue, 5 Aug 2014 00:32:04 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E707D1B2884 for ; Tue, 5 Aug 2014 00:32:03 -0700 (PDT) Received: from 21.104.14.81.rev.sfr.net ([81.14.104.21]:13803 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XEZE2-0002R7-3m; Tue, 05 Aug 2014 00:32:02 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Aug 2014 09:31:50 +0200 To: Andrew Sullivan ,JFC Morfin From: JFC Morfin In-Reply-To: <20140804233834.GA80342@mx1.yitter.info> References: <20140804141507.GB34733@mx1.yitter.info> <20140804153525.GH34733@mx1.yitter.info> <53DFB351.2060801@meetinghouse.net> <20140804164819.GQ34733@mx1.yitter.info> <21471.62506.316620.467114@world.std.com> <20140804213613.GZ34733@mx1.yitter.info> <20140804233834.GA80342@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/11UqjofN9PiS3G2JIB5F0Ada-XA Cc: IAB , ianatransition@icann.org, "iucg@ietf.org" Subject: Re: [iucg] [ianatransition] Disaster scenarios (was Re: Jurisdiction) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 07:32:07 -0000 Dear Andrew, At 01:38 05/08/2014, Andrew Sullivan wrote: >I must correct a misrepresentation from M. Morfin. I do thank you for this clarification. I must say it was necessary, because it was not a misrepresentation but the courteous representation of an incertitude about an ambiguity. When other members of directly involved bodies, eg. John Curan from ARIN, express their opinions (seldom their beliefs), they are careful at indicating they express their personal opinion or to include an "(off hat)" header. One obviously can forget from time to time to mention it, as I happen to confuse the caps I may wear or share - Jay Daley imaginatively keeps adding new ones every day :-), very exciting. However, when this is constant, very active, with an agenda which may interfere with the IAB charter, and without any IAB other member challenging these positions, one could reasonably consider that you float some IAB ideas, or test them, or try to indirectly influence your fellow members in obtaining some external support. I am glad to hear that this is not the case. jfc >I do not speak for the IAB, and M. Morfin is familiar enough with IETF >procedures to know that perfectly well. If the IAB had a position, it >would produce it as an IAB statement, or as an IAB-track RFC. Given >his frequent citation of various RFCs, I cannot tell whether M. Morfin >has unexpectedly forgotten how the IAB works, or whether he intends to >misrepresent the state of affairs in order to lead others astray. > >I am, it is true, a sitting member of the IAB. I do not speak for the >IAB, however, and I don't think I have represented myself as speaking >for it. (I'm also an employee, and don't speak for my employer; a >Canadian, but don't speak for other Canadians; a US citizen, but don't >speak for other USians; and so on.) > >Best regards, > >A > >-- >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >ianatransition mailing list >ianatransition@icann.org >https://mm.icann.org/mailman/listinfo/ianatransition From nobody Wed Aug 6 05:01:47 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C495A1A007A for ; Wed, 6 Aug 2014 05:01:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): To: Patrik F\344ltstr\366m ; Wed, 6 Aug 2014 05:01:44 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D171B2991 for ; Wed, 6 Aug 2014 05:01:44 -0700 (PDT) Received: from 21.104.14.81.rev.sfr.net ([81.14.104.21]:59650 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XEzuX-0000w6-Vt; Wed, 06 Aug 2014 05:01:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Aug 2014 14:01:29 +0200 To: Patrik Fltstrm ,Mark Davis ☕️ From: JFC Morfin In-Reply-To: <219A83FB-B0C4-4B58-93A9-84A976B9147E@frobbit.se> References: <219A83FB-B0C4-4B58-93A9-84A976B9147E@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/jA-l_zBniPoSLumyDJo_lbg76OE Cc: Marc Blanchet , IDNA update work , "iucg@ietf.org" , gerard lang Subject: Re: [iucg] Unicode 7.0.0, (combining) Hamza Above, and normalization for comparison X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 12:01:46 -0000 At 07:03 06/08/2014, Patrik Fltstrm wrote: >To be honest, I do not think it matters where it is discussed. I suggest we keep it discussed here. The reason why is the ICANN response to the plaintiffs in the .ir, etc. case. "the DNS provides a human interface to the internet protocol addressing system". This seems to be a good definition to commonly sustain as it is technically true, easy to understand, and makes a clear distinction between the human and the non-human issues. The most complex issue of the human confusability of the ISO 10646 code points calls for a visual to binary anti-phishing algorithm. Such an algorithm should be added to the idna table allowing registries to accept xn-- registrations or not, based upon the domain names already registered. To start the debate on this issue I would suggest a possibilty for such an algorithm: a mathematical proximity confusability discrimination between character 32x32 rasterizations (i.e. 1024 bits structured strings). I note that this also implies a common font of reference: I do not think this is a problem as it is on the human side and that conflicts will be subject to courts: what counts is the font local law will consider. Up to each ccTLD to provide that information and to have it added to ISO 3106, which already includes the administrative languages we should get renamed anyway as standardization languages coupled with the accepted script(s). Initial question: 1. what is the URL of the complete Unicode code point table value/description? 2. I found rasterisations made for different scripts but not for all. jfc From nobody Thu Aug 7 09:09:56 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E1F1B2E21 for ; Thu, 7 Aug 2014 09:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ZLoNxlAXtK for ; Thu, 7 Aug 2014 09:09:52 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A081B2E1F for ; Thu, 7 Aug 2014 09:09:52 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XFQGA-000N31-0O; Thu, 07 Aug 2014 12:09:46 -0400 Date: Thu, 07 Aug 2014 12:09:40 -0400 From: John C Klensin To: JFC Morfin , =?UTF-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= Message-ID: In-Reply-To: <20140806124932.E9AA77C3B37@mork.alvestrand.no> References: <219A83FB-B0C4-4B58-93A9-84A976B9147E@frobbit.se> <20140806124932.E9AA77C3B37@mork.alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/LKJQa2LKz7bcVl8ogXMND9v3F_A Cc: Marc Blanchet , IDNA update work , iucg@ietf.org, gerard lang Subject: Re: [iucg] Unicode 7.0.0, (combining) Hamza Above, and normalization for comparison X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:09:55 -0000 --On Wednesday, August 06, 2014 14:01 +0200 JFC Morfin wrote: > At 07:03 06/08/2014, Patrik F=C3=A4ltstr=C3=B6m wrote: >> To be honest, I do not think it matters where it is = discussed. >=20 > I suggest we keep it discussed here. The reason why is the > ICANN response to the plaintiffs in the .ir, etc. case. "the > DNS provides a human interface to the internet protocol > addressing system". This seems to be a good definition to > commonly sustain as it is technically true, easy to > understand, and makes a clear distinction between the human > and the non-human issues. >... Jefsey, I am not sure I understand what you are talking about but, if I do, it is about an almost completely different topic. =20 The actual issue here is extremely narrow and not associated with subjective (or computable via a distance function) visual conformability at all. The issue also applies to a very small (compared to the total Unicode repertoire) number of characters. It also involves the relationship between characters/ code points within a single script, while most conversations about confusability have related to characters (more specifically, code point sequences) within a given script. In the hope that we can at least all be talking about the same thing, let me try to summarize the issue with the hope that Mark and I can at least agree about the summary. At the risk of being harsh, while I think more informed discussion of the issues would be helpful, getting to an informed discussion requires some serious effort to understand the Unicode Standard, its construction, and its specific treatment of Arabic. The explanation below may be helpful to those who have at least a large fraction of that understanding; those who don't have that much would be, IMO, well-advised to do some serious reading before trying to participate. In some situations, the Hamza combining character is used with a base character as a pronunciation indicator. I'm told that, for the "BEH" base character and a few others, the most common such use is when Arabic (language) words are written in a Perso-Arabic context or similar writing system environments. Hamza is less often used this was for writing contemporary Arabic language in an Arabic language context, but that usage has changed over time. That usage as a pronunciation indicator has been supported in Unicode for years and years by a combining sequence using the base character and Hamza Above (a combining character). In the lead-up to Unicode 7.0.0, the Unicode Consortium apparently got a request to include some characters that are needed for a North African language that is sometimes written in Arabic script. While it looks just like the BEH WITH HAMZA ABOVE combining sequence (and Unicode even decided to give it that name), it is really a conceptually separate character. =20 I think there is no disagreement up to that point, including about the abstract form of the combining sequence looking "just like" the newly-assigned character. Again, this is within the same script and there are no issues about what is confusingly similar and what is not. There are several (I think equivalent) versions of where the disagreement sets in, but let me try what seems today to be the most clear. Section 2.2 of The Unicode Standard seems to be quite clear that coding in the standard is independent of language, and similar considerations (see, in particular, the subsection titled "Unification"). Some of us who read that believe that a new code point for this letter should not be assigned at all and that, if it is, it should be subject to other rules that decompose it back into the combining sequence. However, section 2.2 makes clear that there are multiple considerations or "design principles" (it lists ten of them), that it may not be possible to apply them all and get a consistent result in a particular case, and that it is necessary to strike a balance. Presumably on the basis of that balance, and with the precedent of at least three other characters in the Arabic script that are also distinct characters for some languages but combining sequences (if used at all) for others, a new code point, U+08A1, was assigned without a decomposition back to the existing combining sequence. Mark (and others associated with the decision) cite the language issues, the precedents in the other Arabic characters, and so on. Those of us who aren't enthused about the new character at all but who are really concerned about two code point sequences that, once language identification or considerations are removed, yield the identical characters are very concerned that normalization doesn't create an equality relationship. =20 IMO, that can't be "resolved" or consensus reached because the criteria for making the decision are different and lead to different results. There are still parts of the criteria that Unicode is applying that confuse me (with frequent examples about use of Latin script among European languages and even some Latin characters being used to denote rather different phonemes in Hanyu Pinjin than they denote in Western Europe as examples of the confusion). I'd like to be wrong. But, if I'm not, then we have a mechanism in IDNA for dealing with newly-added Unicode code points that are problematic for IDNA. It seems to me that there is little question that this new character (and at least its three predecessors) are problematic for IDNA (Mark may disagree, but I don't think he has said that yet). The question then becomes whether the damage that would be done by just accepting the Unicode decision and allowing U+08A1 to be PVALID would be greater or less than the potential damage from excluding it or writing special rules, rules that might, in some ways, parallel the discussion of Hamza in the "Arabic" section of The Unicode Standard. Again, more general discussion about confusable characters, especially between scripts, are relevant, but not to this thread and discussion and maybe not in/to this WG or the IETF. As an aside, if you dig back through the literature in optical (or equivalent) character recognition in the pre-Kurzweil period, you will find quite a bit about abstract character properties and distance functions that might explain why the latter never worked very well even with a character repertoire limited to a single language. Some things have clearly changed in more than a half-century, but a lot has not. best, john From nobody Thu Aug 7 10:02:23 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80121B2E9E for ; Thu, 7 Aug 2014 10:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.145 X-Spam-Level: *** X-Spam-Status: No, score=3.145 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2ZvekHBpdkO for ; Thu, 7 Aug 2014 10:02:20 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8351B2E9C for ; Thu, 7 Aug 2014 10:02:20 -0700 (PDT) Received: from 21.104.14.81.rev.sfr.net ([81.14.104.21]:19945 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XFR51-0001XZ-9u for iucg@ietf.org; Thu, 07 Aug 2014 10:02:19 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Aug 2014 19:02:09 +0200 To: "iucg@ietf.org" From: Jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/QE3mOApA-W9VGDzcJtzubOXCwaI Subject: [iucg] Internet algorithmic governance X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 17:02:22 -0000 Dear all, in the past months the IUCG has been victim of hacking at the incitation of pro-ICANN aficiniados. In order to keep the situation cool I did not react and gave time to time. It now seems that the NTIA request (http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions) to ICANN is going to a dead end. The reason why is that the ICANN community does not seem to consider the NTIA request that only concerns the replacement of the NTIA's role in the DNS class "IN" ICANN/NTIA, while the ICANN debate revolves on the IANA transition. This creates an important risk of conflict and unstability on the DNS and IANA, at a time RFC 6852 has acknowledged standardization fragmentation of the internet and its unity trough a common architecture, a common standardization paradigm based upon a supposed common economic interest of its different markets and global communities. The technical suggestions proposed by the members of the ICANN communities are essentially "IANALs'" unconstitutional blahblahblah (how the NTIA could trick the US law). More seriously the only solution seems to be for the entire IANA like matters to be engineered as law/fool-proof through an "algorithmic governance" stewardship, i.e. - one commonly accessible (Libre) cartographic tool of the network topology, spaces, and standards of any SDO, community or manufacturer - a system of servers running this process in parallel and mutually checking their findings. This system will be organized and managed by MYCANN, http://mycann.org/ - making these findings available through a "netiana" open protocol and readers. This way the legal/political/economic/cultural responsibility lays with the authors of the data, not with their online "echo". If the polycratic or state digitglobal community wants to filters or broadcast some information, this will be made possible. Such a system operational interest is in proportion to the number of its users. Its architectural interest is immediate as it provides an alternative to be tested and considered in other propositions. jfc From nobody Thu Aug 7 11:07:49 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F3F1A033E for ; Thu, 7 Aug 2014 11:07:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: ...nsin@jck.com>, Mark Davis \342\230\225\357\270\217 ; Thu, 7 Aug 2014 11:07:43 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7C91A02EC for ; Thu, 7 Aug 2014 11:07:43 -0700 (PDT) Received: from 21.104.14.81.rev.sfr.net ([81.14.104.21]:22447 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XFS68-0008TI-6f; Thu, 07 Aug 2014 11:07:32 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Aug 2014 20:07:21 +0200 To: John C Klensin ,Mark Davis ☕️ From: Jefsey In-Reply-To: References: <219A83FB-B0C4-4B58-93A9-84A976B9147E@frobbit.se> <20140806124932.E9AA77C3B37@mork.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/mefFPgIneZ_L7PVPMjP3NdmsAsg Cc: Marc Blanchet , IDNA update work , iucg@ietf.org, gerard lang Subject: Re: [iucg] Unicode 7.0.0, (combining) Hamza Above, and normalization for comparison X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 18:07:45 -0000 At 18:09 07/08/2014, John C Klensin wrote: >Jefsey, > >I am not sure I understand what you are talking about but, if I >do, it is about an almost completely different topic. John, as you may remember I am not interested in Unicode per se. I am interested in the open pragmatic use of the digisphere through whatever is available and people want to use. This calls for external (fringe to fringe) innovations not to be constrained by any internal (end to end) MUST. As far as I undedrstand, the issue being raised concerns orthotypography in a specific language? This has been ruled out of the IDNA2008 scope. Because it was ruled out the Unicode scope. Now, what may have to be clarified is what a user calls confusable. For users, "confusables" are different codepoint sequences that look the same (whatever the reason). If the Hamza added sequences are not creating internet use confusion, we are not concerned. If they are, we are concerned. However, we MUST not decide for others: we only are to give them the possibility to decide by themselves. A digital name supports a semantic address through group of visual signs. Whatever the underlying code, version, etc. For the time being the IETF has chosen a single underlying typographic code to support the digital names' signs. That code does not consider orthotypography (i.e. semantic constraints that are language dependant). So the IETF has chosed that its end to end protocol are not concerned by orthotypographic issues. Tomorrow we can chose an additional code to Unicode: we need the use of these two codes to be transparent to our own use, independently from any orthotypographic issue. This is the metric of our choice. 1. TLD Managers must be able to use their own add-ons to support or not orthotypographic aspects in their zone. How do you know if you will not create conflicts today with Hamza, or in "equivalent" other cases? 2. If you consider Hamza you must consider French majucules. Or am I wrong? Best. jfc >At 19:37 07/08/2014, John C Klensin wrote: >p.s. RFC 5895 was never intended to be standards track. Talking >about "denying" that status to it is misleading at be Short memories. Anyway, the point is that without Paul's and Pete's solution I would never have given up the orthotypographic requirement and IDNA would have been technically and politically blocked. I consider that RFC 5895 is one of the most fundamental architectural RFCs of the internet as it illustrates how the internet architecture survives external diversity, by subsidiarity at the fringe. This is where French majuscules can be treated (layer six experimentation). From nobody Thu Aug 7 13:29:43 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4F1A00D7 for ; Thu, 7 Aug 2014 13:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKdGcTc_onkO for ; Thu, 7 Aug 2014 13:29:27 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E7F1B28FF for ; Thu, 7 Aug 2014 13:29:27 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XFUJI-000NQG-VM; Thu, 07 Aug 2014 16:29:16 -0400 Date: Thu, 07 Aug 2014 16:29:11 -0400 From: John C Klensin To: Jefsey , =?UTF-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= Message-ID: References: <219A83FB-B0C4-4B58-93A9-84A976B9147E@frobbit.se> <20140806124932.E9AA77C3B37@mork.alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/rFSVxcFIFfUGqnyDErLmjFpG-to Cc: Marc Blanchet , IDNA update work , iucg@ietf.org, gerard lang Subject: [iucg] Non-Unicode interfaces to IDNs (was: Re: Unicode 7.0.0, (combining) Hamza Above, and normalization for comparison) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:29:35 -0000 --On Thursday, August 07, 2014 20:07 +0200 Jefsey wrote: > At 18:09 07/08/2014, John C Klensin wrote: >> Jefsey, >>=20 >> I am not sure I understand what you are talking about but, if >> I do, it is about an almost completely different topic. >=20 > John, >=20 > as you may remember I am not interested in Unicode per se. I > am interested in the open pragmatic use of the digisphere > through whatever is available and people want to use. This > calls for external (fringe to fringe) innovations not to be > constrained by any internal (end to end) MUST. As far as I > undedrstand, the issue being raised concerns orthotypography > in a specific language? Actually, perhaps the opposite because one view of the problem is a desire to keep the IDN uses of Unicode = language-independent. > This has been ruled out of the IDNA2008 scope. Because it was > ruled out the Unicode scope. Yes. And that makes it out of scope for this list. not just the Unicode 7.0.0 topic thread. =20 For whatever it is worth, the Internet is rapidly moving in a direction in which there will be two kinds of Web browsers: those that work (more or less exclusively) with Unicode encoded in UTF-8 and those that don't work with contemporary tools and facilities. That set of issues is obviously much broader than IDNs. If you feel a need to support or rely on non-Unicode interfaces you should probably be standing in front that that juggernaut, not trying to fine-tune IDNA edge cases. > Now, what may have to be clarified is what a user calls > confusable. For users, "confusables" are different codepoint > sequences that look the same (whatever the reason). If the > Hamza added sequences are not creating internet use confusion, > we are not concerned. If they are, we are concerned. = However, > we MUST not decide for others: we only are to give them the > possibility to decide by themselves. Then you are discussing yet another problem. People who survey the written forms of languages indicate that the language in which the particular character in question is written (variously known as Fula, Fulan, Peul, and other names) is almost always written in this century in Latin script. I haven't even tried to do the research but a guess from my recollections about the history of the area is that Latin script started to predominate about the time of the beginning of French presence in Northern Africa. The Unicode discussion (and various online articles that may or may not be independent) say that the language is still written in Arabic script by "Islamists" (a category whose definition one can guess at but cannot be certain of its meaning in this context). The first question is whether that community is likely to be registering and using domain names that use this particular character. I have no way to guess the answer to that question but want to stress that this character is a non-issue for anyone who reads and writes the Fula language exclusively in Latin characters (and may be less of an issue from those who don't read or write, and maybe haven't heard of, that language). The second part is more complicated. Even in the Unicode context as of Version 6.3 and earlier, one can create something that looks just like this character by using BEH and Combining Hamza Above. That is clearly inconvenient and annoying, in the same sense that it would be inconvenient and annoying to have to figure out a way to enter U+0063 and then U+0327 any time you wanted to write "=C3=A7" (U+00E7) (I'm assuming a = French-relevant example will work better for you than the usual Swedish one). =20 That brings us to the crux of this rather subtle problem. If you (or the users you are concerned about) think of "=C3=A7" as = a special and unique latter, rather than as a decorated "c", then, following the Fula example that leads to U+08A1, then that letter should not compare equal, even after normalization, to the U+0063 U+0327 combination and, unless the latter is meaningful in some language that does not consider the combination a letter, the combination should not be allowed at all... any more than we would expect "w" to compare equal to the sequence "vv" or "uu". But, if both U+00E7 and the combining sequence are allowed (as is the case today) and both are normalized using the same method, the results will compare equal... not because they look alike, but because they are the same character. Moreover, the IDNA requirement that all A-labels be in NFC form (which doesn't affect your ordinary text) effectively makes it impossible to incorporate the combining sequence into the DNS, so no potential for two representations of the same character that do not compare equal. = However, because of the distinction that was explained earlier, and perhaps because Arabic script is subject to different rules in practice than Latin script, the intent (or at least the effect of letting the existing rules work without introducing an exception) is that the DNS be able to accommodate both ARABIC BEH WITH HAMZA ABOVE as a single, atomic, character coded as U+08A1 and ARABIC BEH with HAMZA ABOVE as a two-character combining sequence with identical appearance and without the two comparing equal after normalization. =20 _That_ is the present issue. =20 Now, in a world in which one were not using Unicode but instead used, e.g., national language code pages, both the French and Fula cases above are entirely non-issues. In ISO 8859-1 and its descendants, "=C3=A7" appears as a single character, there = is no combining cedella, and it makes no difference whether that ISO 8859-1 character is mapped to Unicode by using the single code point or the combining sequence as long as one is consistent about it. Similarly, if one created a seven or eight bit code page for Fula written in extended Arabic script, the combining Hamza Above would probably not be included, the single code point probably would, and it would make no difference how the character was mapped to Unicode as long as one was consistent about it. The only problem with the above paragraph is that it is questionable whether continued use of ISO 8859-1 is viable today much less whether there would be international acceptance of new code pages. Whether it is viable today or not, it is clear that it is getting rapidly less plausible no matter how much you (or others) might wish for it. > A digital name supports a semantic address through group of > visual signs. Whatever the underlying code, version, etc. For > the time being the IETF has chosen a single underlying > typographic code to support the digital names' signs. This may be a vocabulary issue, but I would associate the term "typographic code" with the combination of some sort of reference to a character repertoire (a coded character set, encoding, and code point would be one such reference, but definitely not the only possibility) with a reference to a type style or type family or member thereof (or, less precisely, a "font"). The IETF has _never_ made such a choice. > That > code does not consider orthotypography (i.e. semantic > constraints that are language dependant). So the IETF has > chosed that its end to end protocol are not concerned by > orthotypographic issues. Tomorrow we can chose an additional > code to Unicode: we need the use of these two codes to be > transparent to our own use, independently from any > orthotypographic issue. This is the metric of our choice. I think that, in practice, the window on your making and using that choice is closing rapidly if it has not closed already. See above. The only constraint existing IETF work is going to impose on you is that there be an orderly and consistent mapping between whatever you decide to use and the Unicode repertoire. If there is not, you will find that you are introducing your own form of confusion, one that will be very hard for you users to understand. However, if you want to create or adopt a language-specific or even typography-specific coding, don't let me discourage you from trying as long as you don't expect most people on this list (or even me) to discuss it with you. > 1. TLD Managers must be able to use their own add-ons to > support or not orthotypographic aspects in their zone. How do > you know if you will not create conflicts today with Hamza, or > in "equivalent" other cases? Such TLD managers would face at least two problems: One would be getting equivalent plug-ins into all of the browsers that potential users of the TLD (or URIs that include it) might use or reference. Otherwise, they would expose users to wildly inconsistent behavior, which is generally not a good idea. Reducing the chance of that sort of confusion is one of many things driving the "UTF-8 only" movement. The second is that the TLD manager has very little control over the TLD environment. If the plug-ins merely change the appearance of characters to make them a little more attractive, that might be a non-problem. But, if they create distinctions that don't exist elsewhere or map some characters into others, there is a lot of potential for very bad things to happen. In particular, the propagation of such plugins would create a wonderful opportunity for people with malicious intent because, at least conceptually, any plug in that can alter the form of a domain name or URI can alter it all the way to something completely different. > 2. If you consider Hamza you must consider French majucules. > Or am I wrong? You are mostly wrong because the issue with French majuscules is that, if you had a CCS that distinguished them from conventional upper and lower case letters, information would be lost in mapping that CCS to Unicode, causing the "Consistency" condition mentioned above to fail. There is no loss of information in this Hamza case because the mappings to and from Unicode are trivial (because the discussion is entirely about Unicode) and, as discussed above, any specialized code page would behave in a consistent and predicable way. Interestingly --and part of the challenge the Unicoce Consortium faces-- if normalization brought U+08A1 together with the combining sequence but the "separate character" argument continued to hold, the normalization process would lose the information about whether the original was that "separate character" or the combining sequence. But that situation is much like the counterfactual c-with-cedilla case mentioned above, not anything to do with majuscules. And I suspect this list has now had enough of this discussion. best, john From nobody Sat Aug 16 00:51:42 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A701A86F1 for ; Sat, 16 Aug 2014 00:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.532 X-Spam-Level: **** X-Spam-Status: No, score=4.532 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BbvWynDRsEW for ; Sat, 16 Aug 2014 00:51:40 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287301A86F0 for ; Sat, 16 Aug 2014 00:51:40 -0700 (PDT) Received: from 56.74.14.81.rev.sfr.net ([81.14.74.56]:57595 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XIYm2-0004R7-Vk; Sat, 16 Aug 2014 00:51:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 16 Aug 2014 09:47:25 +0200 To: Nnenna Nwakanma From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_192341651==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/eyaOoYov_grmzGr6V0Xlhax2ASw Cc: "discuss@1net.org" , "iucg@ietf.org" Subject: Re: [iucg] [discuss] NetMundial Initiative X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 07:51:41 -0000 --=====================_192341651==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:14 15/08/2014, Nnenna Nwakanma wrote: >I woke up early this morning and read Anne Jellema (CEO of Web >Foundation)'s blog post. She titled it "Fall of Internet Governance?" > >I found it interesting, especially from the civil society point of view. Nnenna, all this shows that the CS tears and cries strategy does not pay back. If there are Human Digital Rights attached to a system we build ourselves with our own machines, why don't we respect and enforce them ourselves first, and make this autumn the fall of our Internet Governance. The MYCANN project plans to go in that direction. Who else? The internet is us, not the US. jfc (http://mycann.org. The road map plans to technically gather and support the EZoP HomeRoot, SuperIANA and Happy-IP project together in order to give everyone their VGN. This is a CS/Libre/IUCG inititative. --=====================_192341651==.ALT Content-Type: text/html; charset="us-ascii" At 08:14 15/08/2014, Nnenna Nwakanma wrote:
I woke up early this morning and read Anne Jellema (CEO of Web Foundation)'s blog post. She titled it "Fall of Internet Governance?"

I found it interesting, especially from the civil society point of view.

Nnenna,

all this shows that the CS tears and cries strategy does not pay back. If there are Human Digital Rights attached to a system we build ourselves with our own machines, why don't we respect and enforce them ourselves first, and make this autumn the fall of our Internet Governance. The MYCANN project plans to go in that direction. Who else? The internet is us, not the US.

jfc

(http://mycann.org. The road map plans to technically gather and support the EZoP  HomeRoot, SuperIANA and Happy-IP project together in order to give everyone their VGN. This is a CS/Libre/IUCG inititative. --=====================_192341651==.ALT--