Subject: [hrpc] [PATCH 1/2] correct internationalization and refer to localization

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 7 Dec 2015 16:33:35 -0500

---
 draft-glossary.md | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/draft-glossary.md b/draft-glossary.md
index 1879473..cc05fc2 100644
--- a/draft-glossary.md
+++ b/draft-glossary.md
@@ -242,8 +242,13 @@ Inter-operable
 Internet Standards as an Arena for Conflict
 : Pursuant to the principle of constant change, since the function and scope of the Internet evolves, so does the role of the IETF in developing standards. Internet standards are adopted on the basis of a series of criteria, including high technical quality, support by community consensus, and their overall benefit to the Internet. The latter calls for an assessment of the interests of all affected parties and the specifications’ impact on the Internet’s users. In this respect, the effective exercise of the human rights of the Internet users is a relevant consideration that needs to be  appreciated in the standardization process insofar as it is directly linked to the reliability and core values of the Internet. {{RFC1958}} {{RFC0226}} {{RFC3724}}
 
-Internationalization (i13n)
-: The practice of the adaptation and facilitation of protocols, standards, and implementation to different languages and scripts.
+Internationalization (i18n)
+: The practice of making protocols, standards, and implementations usable in different languages and scripts.  (see Localization)
+
+Localization (l10n)
+: The practice of translating an implementation to make it functional
+      in a specific language or for users in a specific locale (see
+      Internationalization)
 
 Open standards
 : Conform  {{RFC2606}}: Various national and international standards bodies, such as ANSI,
-- 
2.6.2

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 7 Dec 2015 16:33:36 -0500

---
 draft-methodology.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-methodology.md b/draft-methodology.md
index 14c6bf0..f6e1c75 100644
--- a/draft-methodology.md
+++ b/draft-methodology.md
@@ -763,7 +763,7 @@ The XMPP specification dictates that clients are identified with a resource (<no
 
 #### Surveillance of Communication
 
-The XMPP protocol specifies the standard by which communication of channels may be encrypted, but it does not provide visibility to clients of whether their communications are encrypted on each link. In particular, even when both clients ensure that they have an encrypted connection to their XMPP server to ensure that their local network is unable to read or disrupt the messages they send, the protocol does not provide visibility into the encryption status between the two servers. As such, clients may be subject to selective disruption of communications by an intermediate network which disrupts communications based on keywords found through Deep Packet Inspection. While many operators have commited to only establishing encrypted links from their servers in recognition of this vulnerability, it remains impossible for users to audit this behavior and is not required by the protocol {{xmppmanifesto}}.
+The XMPP protocol specifies the standard by which communication of channels may be encrypted, but it does not provide visibility to clients of whether their communications are encrypted on each link. In particular, even when both clients ensure that they have an encrypted connection to their XMPP server to ensure that their local network is unable to read or disrupt the messages they send, the protocol does not provide visibility into the encryption status between the two servers. As such, clients may be subject to selective disruption of communications by an intermediate network which disrupts communications based on keywords found through Deep Packet Inspection. While many operators have commited to only establishing encrypted links from their servers in recognition of this vulnerability, it remains impossible for users to audit this behavior and encrypted connections are not required by the protocol itself {{xmppmanifesto}}.
 
 In particular, section 13.14 of the protocol specification {{RFC6120}} explicitly acknowledges the existence of a downgrade attack where an adversary controlling an intermediate network can force the inter domain federation between servers to revert to a non-encrypted protocol were selective messages can then be disrupted.
 
-- 
2.6.2

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 8 Dec 2015 20:56:59 +0100

Thanks dkg,

Both patches look good to me, I integrated the changes in both drafts
on github:

https://github.com/nllz/IRTF-HRPC/commit/8a37f95ee1b457e37b665e47fda9473
463cb6908

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                   678B 08B5 A0F2 636D 68E9

On 12/07/2015 10:33 PM, Daniel Kahn Gillmor wrote:
> --- draft-methodology.md | 2 +- 1 file changed, 1 insertion(+), 1
> deletion(-)
> 
> diff --git a/draft-methodology.md b/draft-methodology.md index
> 14c6bf0..f6e1c75 100644 --- a/draft-methodology.md +++
> b/draft-methodology.md @@ -763,7 +763,7 @@ The XMPP specification
> dictates that clients are identified with a resource (<no
> 
> -The XMPP protocol specifies the standard by which communication of
> channels may be encrypted, but it does not provide visibility to
> clients of whether their communications are encrypted on each link.
> In particular, even when both clients ensure that they have an
> encrypted connection to their XMPP server to ensure that their
> local network is unable to read or disrupt the messages they send,
> the protocol does not provide visibility into the encryption status
> between the two servers. As such, clients may be subject to
> selective disruption of communications by an intermediate network
> which disrupts communications based on keywords found through Deep
> Packet Inspection. While many operators have commited to only
> establishing encrypted links from their servers in recognition of
> this vulnerability, it remains impossible for users to audit this
> behavior and is not required by the protocol {{xmppmanifesto}}. 
> +The XMPP protocol specifies the standard by which communication of
> channels may be encrypted, but it does not provide visibility to
> clients of whether their communications are encrypted on each link.
> In particular, even when both clients ensure that they have an
> encrypted connection to their XMPP server to ensure that their
> local network is unable to read or disrupt the messages they send,
> the protocol does not provide visibility into the encryption status
> between the two servers. As such, clients may be subject to
> selective disruption of communications by an intermediate network
> which disrupts communications based on keywords found through Deep
> Packet Inspection. While many operators have commited to only
> establishing encrypted links from their servers in recognition of
> this vulnerability, it remains impossible for users to audit this
> behavior and encrypted connections are not required by the protocol
> itself {{xmppmanifesto}}.
> 
> In particular, section 13.14 of the protocol specification
> {{RFC6120}} explicitly acknowledges the existence of a downgrade
> attack where an adversary controlling an intermediate network can
> force the inter domain federation between servers to revert to a
> non-encrypted protocol were selective messages can then be
> disrupted.
> 
>