You can not have two authoritative texts. Yes I understand that it may
happen (probably already did) that RFC text is translation from original
written in another language. The reason it got translated however is so
that it could be checked on and commented by IETF community and so that
it could go through IETF process for publication and the reason English
is used is that IETF participants that review documents read English.
That English text then becomes authoritative because it had gone through
entire review process where as text in another language would not have
been commented on (its not only substance but sometimes actual words
in text that is important in standard documents). The original in another
language after publication can then be considered author's own personal
translation to that language, which is although very helpful for those
speaking that language, could not be considered authoritative because
text has not gone through full IETF review.
The best that could be made with your ideas is possibly to ask rfc-editor
to maintain list & links to unofficial translations for RFCs when existence
of such translations is reported to them as well as info on unofficial
text of the RFC in some other format (i.e. XML). I think in such a case
RFC editor should maintain only a link to external site (author or
translator's own site) to emphasize the unofficial nature of such texts,
but doing it as "caching copy" (like google does for pages) maybe ok too
just so its available if link can not be reached, All this would require
effort (for programming and for maintenance) and probably needs certain
amount of agreement and desire from IETF participants to make it happen.
And as far as extra links for diagrams (for those with other languages)
if somebody creates a translation, his text can obviously use different
link for language-specific diagram (and so can XML source or HTML text
of the document to the picture that can be used in place of ASCII art)
and to me it seems the right way to go about it.
On Wed, 23 Nov 2005, JFC (Jefsey) Morfin wrote:
At 12:19 23/11/2005, Stephane Bortzmeyer wrote:
On Mon, Nov 21, 2005 at 09:54:27AM +0100,
Julien.Maisonneuve@xxxxxxxxxxx <Julien.Maisonneuve@xxxxxxxxxxx> wrote
a message of 25 lines which said:
> The IETF is probably the ONLY meaningful organisation in the world
> that insists on using ascii-only specifications. Any rationalization
> of that practise should try to explain why we are so exceptional
So, saying "Everybody do it that way, we should, too" is ignoring many
IETF idiosyncrasies.
Full agreement.
3) IETF attendance is quite open (here, IETF is really exceptional). So,
its members are a wide and diverse community and it is difficult to find a
format which is both better than ASCII and widely available.
This is here where however we have a real practical problem. Only standards
and procedures written in English can be authoritative and Drafts needs to
be designed using the ASCII charsets. This is acceptable when only English
speaking engineers and reading users are concerned. This represents less
than 1/4 of the world population. As long as the IETF addressed pure
Internet technology, it was unlikely this would be a problem - and after all
an ASCII technology can legitimately only documented in ASCII. This is not
anymore the case with the increase of societal aspects in the digital
ecosystem convergence and with multilingual issues.
The BCP 49 update the IESG has approved, and I oppose in its current form
for that reason, creates and is unable to address that difficulty. As a BCP
it is supposed to document practices which - by essence - can be
increasingly authoritatively multilaterally documented in the concerned
languages (the translation is not from an authoritative English text to
another language, but from another language authoritative text to ASCII
English). RFC 3066 bis engages the IETF in having to be unilaterally
authoritative in areas where it has no internal expertise (and therefore no
cross-expertise), no adequate tools and procedures and no proper resources
(IANA is not multilingual - or even internationalized).
This is why after more drastic initial suggestions, I found the sole (IMHO)
possible consensual technical proposition: it is to simply include in RFC
3066 bis a hook (two lines of additional texte) to the RFC 4151 format
(URI-tags). This way, ASCII (and proposed RFC 3066 constrained format) stays
authoritative by default, but an external tagging system or procedure
(whatever the script) can be authoritatively referred to in an RFC, an XML
page or through a library entry, in using ASCII characters. Obviously,
upgrading RFC 4151 towards full IRI-tags support would be better. This
approach does not address everything, but it addresses most (including
protection of the users against simple racial/cultural/religious profiling
meta-spam [searches in Google through language tags the author might ignore
(RFC 3066 bis Security considerations) em] and language identification
encryption).
Otherwise, after being quite open, as you mention it, the IETF will become
exceptional in our world of increasingly protected and respected cultural
diversity, as being culturally/societally exclusive and the authoritative
reference (language IANA registry) of that exclusion. I doubt this is the
intent, however this is/would be the practice.
jfc
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf