Subject: [rfc-i] Fwd: [TLS] On the difficulty of technical Mandarin (SM3 related)

From: Kyle Rose <[email-masked]>
Date: Mon, 19 Aug 2019 12:26:20 -0400

Try #2.

Moving tls to bcc, and adding rfc-interest. (This is the kind of discussion
that is likely to ignite a dumpster fire, and it's not specific to TLS
work.)

On Mon, Aug 19, 2019 at 11:05 AM Watson Ladd <[email-masked]> wrote:

> I see no reason why English alone should be accepted for standards
> documents we reference. French and German pose few difficulties, and one
> can always learn Russian.
>
> What I don't know is how difficult Mandarin is at a level to read a
> standards document. I expect the mechanics of using the dictionary to
> dominate.
>
> I'm concerned about the traceability of unofficial Englidh PDFs on some
> website: could the Chinese body responsible host them instead?
>
> I fully expect this to be a more general IETF problem.
>

For purely practical reasons, within a knowledge domain it makes sense to
have a single language in which normative documents are written, with
fluency in that language an implicit requirement of direct participation.
Otherwise, the number of people who will be able to contribute to IETF work
(writing or reviewing) will be very small, limiting the throughput, shared
knowledge base, and overall utility of the SDO.

For historical reasons, that single language is English. This isn't
something unique to the IETF, either: for a variety of reasons too numerous
to cover here, English has become the default shared language in a
multilingual world when actual work needs to get done between people with
different native tongues. The IETF exists in this reality: fair or not,
there's really no other practical choice.

Informational documents and upstream references are maybe a different story
as they are not required to implement IETF protocols, but I suspect similar
issues would crop up even there, given how important many informational
documents are.

Kyle
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Kyle Rose <[email-masked]>
Date: Mon, 19 Aug 2019 14:35:00 -0400

(Fixed rfc-interest address.)

On Mon, Aug 19, 2019 at 1:47 PM Watson Ladd <[email-masked]> wrote:

> On Mon, Aug 19, 2019, 9:24 AM Kyle Rose <[email-masked]> wrote:
>
> Certainly: I'm not saying our docs should be in other languages. But an
> upstream reference that is an unofficial translation has other issues with
> accuracy.
>
> Dumping an unofficially translated pdf on github and using that as a
> reference isn't so great, and that seems to be the solution we're going
> with for SM ciphers. It would be great if there was an official canonical
> English version of the referenced spec but what do we do when there isn't?
>

 It depends on how critical the document is to interoperability of
standards.

For normative references, I would argue the authoritative version of an
outside spec must be in English. Otherwise, we open ourselves up to
inconsistencies, ambiguities, and mistranslations. In the case of an ISO
doc associated with the spec, that ISO doc is for our purposes the
authoritative normative reference, not the original document from which it
was produced. If there isn't an authoritative English version of a spec
that we can point to, it must not be used in an IETF standard.

For informational references, it's less clear. While they are not normative
for specs, they might be essentially normative for operations (think: BCP
38) and so the effects of mistranslation and ambiguity could nonetheless be
substantial. This might need to be judged on a case-by-case basis.

With respect to the particular issue raised on the TLS mailing list, IMO
the mere existence of a Mandarin spec for the SM cipher, independently
verified to exist and describe the cipher in question, is sufficient to
reach the bar required by the IANA registry "specification required". This
is one of those cases in which an English translation is unnecessary to
protect the rest of the ecosystem: SM is not an IETF standard and will not
be "recommended" by IANA, so the ability of IETF participants to understand
and develop interoperating implementations is not an issue. They just want
a code point. The bar for that is intentionally set pretty low.

Kyle

---

From: Ronald Tse <[email-masked]>
Date: Tue, 20 Aug 2019 02:22:16 +0000

(Kyle, thanks for forwarding this to the rfc-i list!)

This discussion is of specific interest to me for two reasons.

As one of the editors of the newly revised ISO 690 (Guidelines for citation references), I believe it is important to allow readers to locate the authoritative specification in its original language, as well as to the translated specification in the operating language.

i.e. In the case of IETF, accepting non-English references (supplemented by an English translation of the reference) aids locatability. An additional reference to a translation of the referenced document aids understanding.

One of the new features of RFC XML v3 is Unicode support; previous demonstrations showed non-English characters works.

As one the editors of the SM3 Internet-Draft (https://tools.ietf.org/html/draft-sca-cfrg-sm3-02), this document is the closest to the authoritative translation of SM3. The two editors from the Chinese Academy of Sciences were specifically commissioned by the authority of SM3 to produce an official translation. Again, this is an informational translation.

Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Aug 20, 2019, at 2:35 AM, Kyle Rose <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Aug 19, 2019 at 1:47 PM Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Aug 19, 2019, 9:24 AM Kyle Rose <[email-masked]<mailto:[email-masked]>> wrote:
For purely practical reasons, within a knowledge domain it makes sense to have a single language in which normative documents are written, with fluency in that language an implicit requirement of direct participation. Otherwise, the number of people who will be able to contribute to IETF work (writing or reviewing) will be very small, limiting the throughput, shared knowledge base, and overall utility of the SDO.

Certainly: I'm not saying our docs should be in other languages. But an upstream reference that is an unofficial translation has other issues with accuracy.

Dumping an unofficially translated pdf on github and using that as a reference isn't so great, and that seems to be the solution we're going with for SM ciphers. It would be great if there was an official canonical English version of the referenced spec but what do we do when there isn't?

 It depends on how critical the document is to interoperability of standards.

For normative references, I would argue the authoritative version of an outside spec must be in English. Otherwise, we open ourselves up to inconsistencies, ambiguities, and mistranslations. In the case of an ISO doc associated with the spec, that ISO doc is for our purposes the authoritative normative reference, not the original document from which it was produced. If there isn't an authoritative English version of a spec that we can point to, it must not be used in an IETF standard.

For informational references, it's less clear. While they are not normative for specs, they might be essentially normative for operations (think: BCP 38) and so the effects of mistranslation and ambiguity could nonetheless be substantial. This might need to be judged on a case-by-case basis.

With respect to the particular issue raised on the TLS mailing list, IMO the mere existence of a Mandarin spec for the SM cipher, independently verified to exist and describe the cipher in question, is sufficient to reach the bar required by the IANA registry "specification required". This is one of those cases in which an English translation is unnecessary to protect the rest of the ecosystem: SM is not an IETF standard and will not be "recommended" by IANA, so the ability of IETF participants to understand and develop interoperating implementations is not an issue. They just want a code point. The bar for that is intentionally set pretty low.

Kyle

_______________________________________________
rfc-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.rfc-editor.org/mailman/listinfo/rfc-interest