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

Ronald Tse tse at ribose.com
Mon Aug 19 19:22:16 PDT 2019


(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 <krose at krose.org<mailto:krose at krose.org>> wrote:

(Fixed rfc-interest address.)

On Mon, Aug 19, 2019 at 1:47 PM Watson Ladd <watsonbladd at gmail.com<mailto:watsonbladd at gmail.com>> wrote:
On Mon, Aug 19, 2019, 9:24 AM Kyle Rose <krose at krose.org<mailto: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

_______________________________________________
rfc-interest mailing list
rfc-interest at rfc-editor.org<mailto:rfc-interest at rfc-editor.org>
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20190820/0d8ba1ef/attachment-0001.html>


More information about the rfc-interest mailing list