[hrpc] Technical remarks on draft-doria-hrpc-proposal-00

Stephane Bortzmeyer <bortzmeyer@nic.fr> Fri, 14 November 2014 05:35 UTC

Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from <bortzmeyer@nic.fr>) id 1Xp9Xj-0004y2-La for hrpc@article19.io; Fri, 14 Nov 2014 06:35:35 +0100
Received: from aetius.bortzmeyer.org ([217.70.190.232] helo=mail.bortzmeyer.org) by mx2.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <bortzmeyer@nic.fr>) id 1Xp9Xj-0007Ty-2l for hrpc@article19.io; Fri, 14 Nov 2014 06:35:35 +0100
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 513263C0A6; Fri, 14 Nov 2014 06:35:34 +0100 (CET)
Received: by tyrion (Postfix, from userid 1000) id 03BE9F01428; Thu, 13 Nov 2014 21:35:08 -0800 (PST)
Date: Thu, 13 Nov 2014 19:35:08 -1000
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: hrpc@article19.io
Message-ID: <20141114053508.GA25277@laperouse.bortzmeyer.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Transport: UUCP rules
X-Operating-System: Ubuntu 14.04 (trusty)
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Level: /
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2
X-Spam-Score: 0.8
X-Virus-Scanned: by Greenhost Virus Scanner
X-Scan-Signature: f0eed3f1d89bc5fb772880ef8d54351a
Subject: [hrpc] Technical remarks on draft-doria-hrpc-proposal-00
X-BeenThere: hrpc@article19.io
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Human Rights Protocol Consideration Discussion list <hrpc.article19.io>
List-Unsubscribe: <https://lists.ghserv.net/mailman/options/hrpc>, <mailto:hrpc-request@article19.io?subject=unsubscribe>
List-Archive: <http://lists.ghserv.net/pipermail/hrpc>
List-Post: <mailto:hrpc@article19.io>
List-Help: <mailto:hrpc-request@article19.io?subject=help>
List-Subscribe: <https://lists.ghserv.net/mailman/listinfo/hrpc>, <mailto:hrpc-request@article19.io?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 05:35:36 -0000

[Most of the remarks here have been done AFK at the Security Area Open
Meeting during IETF 91 in Honululu. I repeat them here because
sometimes oral remarks, like UDP packets, are lost in transit.]

I first suggest that this work inside IETF/IRTF is certainly welcome
and useful but we should also clearly state in the draft that we
recognize that, today, the problem is, most of the time, not in the
protocols (IETF/IRTF activity) but in software, architecture and
business. For instance, to have full access to email (access being a
HR), whatever your native language, fully internationalised email
addresses are certainly necessary. All the standards exist (RFC 6530
and its friends) but their deployment is very limited (except in
Asia). So, there is certainly work to do, but it is not IETF/IRTF
work, it is implementation and deployment.

Section 2.1 of the draft could use some corrections. (By the way,
there is no section 2.2: what was the idea?)

2.1.3 is titled "HTML" why it should be "HTTP". But there is more
important. The draft observes rightly that "Websites made it extremely
easy for individuals to publish their ideas, opinions and thoughts."
But it does not imply that it comes from specific properties of
HTTP. Said otherwise, if we replaced HTTP with FTP or Gopher, what
would be different, from the point of view of HR? IMHO, this is the
sort of things to put in the draft, identify precised characteristics
of protocols that "solidify, enable or threaten human rights". For
HTTP, I would say there are none in most of the RFCs mentioned, but
that proposals like the expired draft
draft-tbray-http-legally-restricted-status certainly are interesting
for the HR.

2.1.5 grossly exaggerates the role of IDN, which are only a very small
component in the internationalisation of the Internet. Even for
"having their own URLs", they are only a part of the story (an URL is
not made of just a domain name). This reminds me of the governance
circus, where a disproportionate amount of effort was put in the IDN
debate. It would be more interesting to identify the points where
protocols are not yet internationalised enough. A good example is the
work of the PRECIS working group <http://tools.ietf.org/wg/precis/>,
for internationalised identifiers.

I would also would like IPv6 to be mentioned: the lack of IPv4
addresses severely limit access for people (with CGN and stuff like
that, you can be a passive consumer but hosting content, for instance,
is much more complicated) and I do not find too far-fetched to say
that the deployment of IPv6 is partly a HR issue.