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

Kyle Rose krose at krose.org
Mon Aug 19 11:35:00 PDT 2019


(Fixed rfc-interest address.)

On Mon, Aug 19, 2019 at 1:47 PM Watson Ladd <watsonbladd at gmail.com> wrote:

> On Mon, Aug 19, 2019, 9:24 AM Kyle Rose <krose at krose.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20190819/0a6e9f38/attachment.html>


More information about the rfc-interest mailing list