Subject: Examples of translated RFCs

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Dec 2005 09:33:31 +0100

Check this site out:

<http://rfc-jp.nic.ad.jp/>

I *think* it has at least a handful of RFCs translated into Japanese, but 
my Japanese skills aren't great enough to know if I found the ones that are 
there.

There's also <http://www.rfc-editor.org/language.html>, with links to 
Spanish and French translation indexes.

Others will have to say if the result has been useful to someone or not; if 
I read the tea leaves correctly, none have translated more than 100 RFCs.

                  Harald

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 06 Dec 2005 10:11:25 +0100

At 09:33 06/12/2005, Harald Tveit Alvestrand wrote:
>I *think* it has at least a handful of RFCs translated into 
>Japanese, but my Japanese skills aren't great enough to know if I 
>found the ones that are there.
>
>There's also <http://www.rfc-editor.org/language.html>, with links 
>to Spanish and French translation indexes.
>
>Others will have to say if the result has been useful to someone or 
>not; if I read the tea leaves correctly, none have translated more 
>than 100 RFCs.

Harald,
there is not a big need of translating RFC from English to other 
languages at the present time, people interested in RFC having some 
English, except for teaching purposes. As using the smallest charset 
RFC have limited translation problems (except when being political 
and an English term meeting cultural context translation problems). 
Also, RFCs describe the ASCII English Internet and many times need to 
be in English. The W3C document 
http://www.w3.org/International/questions/qa-i18n and ICANN efforts 
in the IDN area show the Internet community current low level of 
analysis in term of multilingualisation/multiculturalisation. The 
pending response to my IESG appeal will say how/where the IESG wants 
to see this analysis and support be carried.

So , IMHO, the IETF urgency is today the other way around: 
incorporating into RFC standards, practices or tables authoritatively 
written or thought in another language than English, or in English 
using normative non-ASCII art drafts or using term in a meaning 
foreign to the IETF.

This way we see the language is not the main issue of the current 
debate. The issue is the authoritative quote in community A a 
community B's, or of a searcher C's, normative document - while 
community A presents its documents in a different way - whithout 
affecting its normative capacity. This problem occurs when 
referencing in an RFC an ISO document as normative. The first issues 
being to write its URL properly if it includes non-ASCII characters, 
to properly name the authors and the references, to properly quote 
its copyright mentions and not to violate any law.
jfc

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 06 Dec 2005 20:41:21 +0900

JFC (Jefsey) Morfin wrote:

>> I *think* it has at least a handful of RFCs translated into Japanese, 
>> but my Japanese skills aren't great enough to know if I found the ones 
>> that are there.
>>
> English, except for teaching purposes.

Wrong.

There are a lot of needs and many RFCs and even many IDs translated
into Japanese.

See not only a JPNIC site but also volunteer ones, say:

	http://www.imasy.or.jp/~masaka/rfc-jp/

However, to honor RFC and ID authers, there is no point to include
their names in European or other international characters, because
most readers of Japanes-translated RFCs can't recognize them.

Though some people with Euro-local insights can't distinguish
inter-europeanization and internationalization, many people
can't recognize Euro-local non-ASCII latin characters. Very
few people, if any, recognize all the characters in the world.
 
So, the names in translated RFCs should remain in ASCII or be
transliterated into Japanese local characters. In either case,
we don't need Unicode. Note that major charsets used in Japan
are ISO-2022-JP, EUC-JP, Shift JIS but definitely not any variant
of Unicode.

So, for localized RFCs, that is, translated RFCs, local character
sets, which are often super set of ASCII, are just enough.

							Masataka Ohta

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 06 Dec 2005 14:36:22 +0100

>There are a lot of needs and many RFCs and even many IDs translated

I apologise if hurt your Japanese interest, I would certainly defend 
has I known them.

I trusted the count made by Harald and the reports made by 
participants to this thread. However since I have no Japanase I have 
some difficulty to evaluate the real need/offering: on the site you 
quote there are some brokin links and the RFC numbers _seems_ to be low.

May be will you want to consider the IANA request: "If you are a 
host, or are aware of an RFC foreign language site, please send us 
e-mail with the appropriate URLs."? This would avoid this kind of 
mistake in the future. And may be help a complete directory of the 
translated documents.

Thank you!
jfc

>are ISO-2022-JP, EUC-JP, Shift JIS but definitely not any variant

PS. If everyone has the same need and solution, at the end of the day 
we need ISO 10646. What permits us to scale and print every where?.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Dec 2005 06:06:51 +0900

JFC (Jefsey) Morfin wrote:

> I apologise if hurt your Japanese interest,

There is no need of apologize.
 
> May be will you want to consider the IANA request: "If you are a host, 
> or are aware of an RFC foreign language site, please send us e-mail with 
> the appropriate URLs."? This would avoid this kind of mistake in the 
> future. And may be help a complete directory of the translated documents.

I have forwarded it to local ML. But, is it really IANA and not rfc-editor?
 
> PS. If everyone has the same need and solution, at the end of the day we 
> need ISO 10646.

In most cases, all you need is local variants of ISO 646.

In Japan, we also need a multibyte character set and clever ways to
combine ISO 646 and multibyte characters. Many days have passed since
we got them and we are still using them.

> What permits us to scale and print every where?.

Then, ISO 2022 is a lot more than enough.

On the other hand, with ISO 10646, I can't print Japanese characters
in China.

						Masataka Ohta

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 6 Dec 2005 22:11:11 -0800

Masataka Ohta <mohta at necom830 dot hpcl dot titech dot ac dot jp> 

> On the other hand, with ISO 10646, I can't print Japanese characters

This is the same tired argument you have been advancing at least since 
RFC 1815, ten years ago, and it is no more true now than it was then --  
even less so, in fact, since most computers sold all over the world now 
come with at least one perfectly good Unicode-based font with 
Chinese-style glyphs and another with Japanese-style glyphs.

I understand you are not happy that Unicode and ISO 10646 chose to unify 
Chinese hanzi and Japanese kanji, but it is simply not accurate to say 
that you cannot print Japanese characters in China using ISO 10646.  At 
worst, you are printing them in a culturally non-preferred font style.

Considering the amazing stylistic varieties of kanji seen in Japanese 
advertising and pop culture, and the world-famous Japanese calligraphic 
tradition, I think you do your countrymen a disservice by claiming that 
they are incapable of reading kanji printed in a Chinese-style font.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Dec 2005 15:56:56 +0900

Doug Ewell wrote:

> Masataka Ohta <mohta at necom830 dot hpcl dot titech dot ac dot jp> wrote:

"at"? "dot"?

> since most computers sold all over the world now 

Now, you admit that the problem does exist.

I can't print Japanese characters in China where Chinese-style
glyphs are used by default.

I can, of course, override the default by, for example, bringing
my own computer, my own software or my own configuration. But it
is not the point.

With both Chinese and Japanese glyphs are available, ISO 2022 works
perfectly fine with corresponding Chinese and Japanese character
sets. On the other hand, language tags are useless from the beginning
to distinguish characters. One can represent some content in Japanese
language by ASCII, Japanese characters or Chinese characters.

> I think you do your countrymen a disservice by claiming that they are
> incapable of reading kanji printed in a Chinese-style font.

Red herring.

Just as most native users of Latin alphabet can read Greek alphabet,
most Japanese can read Chinese glyphs, which is not the point at all.

You should admit that ISO 10646 useless for internationalization.

						Masataka Ohta

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 6 Dec 2005 23:46:09 -0800

>> Masataka Ohta <mohta at necom830 dot hpcl dot titech dot ac dot jp>

I tried to obfuscate your e-mail address from bots that search the 
Web-based archives.  I do this to everyone.  Sorry if it was confusing.

> Now, you admit that the problem does exist.

I admit there are stylistic differences between the way the *same 
characters* are written in the Chinese and Japanese traditions.  Anyone 
who knows about East Asian writing knows that.  I do not admit there is 
a problem with unifying them in a character-based (not glyph-based) 
encoding.

> glyphs are used by default.

No, you can't print Japanese *glyphs* in that situation.  Characters and 
glyphs are not the same thing.

> language by ASCII, Japanese characters or Chinese characters.

If you (or your software) can use the distinction between ISO 2022-JP 
and Big-5, or EUC-TW, or CNS 11643, or whatever to determine whether to 
display Japanese or Chinese glyphs, you (or your software) can do the 
same by using the distinction between "ja" and "zh".  If you can use ISO 
2022 controls to switch between "the Japanese repertoire" and "the 
Chinese repertoire," you can do the same with language tags.  This is a 
question of style, not legibility.

If you are saying—I'm not sure about this—that the same ISO 10646 code 
point needs to be displayed in both the Japanese and Chinese glyphic 
traditions in the same Japanese-langauge text, and that only ISO 2022 is 
adequate to indicate which glyphs to display, then I ask: how is this 
problem solved in handwritten text?

> most Japanese can read Chinese glyphs, which is not the point at all.

Actually I think you are being too kind to most native users of the 
Latin alphabet.  They can certainly read Greek Α, because the Latin A is 
derived from it.  They might get terribly confused by Greek Η and Ρ and 
Χ, which are not equivalent to the Latin letters they resemble—unless, 
of course, they are familiar with the use of Greek letters in 
professional or fraternal organizations, which is its own red herring.

Most scholars of writing systems disagree with your premise that Chinese 
hanzi and Japanese kanji are two separate writing systems in the same 
way that Latin and Greek are separate.  Latin and Greek are not simply 
glyph variants of one another.

> You should admit that ISO 10646 useless for internationalization.

I do not.  ISO 10646 is a cornerstone of modern software 
internationalization.

I imagine this is off-topic for IETF.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Dec 2005 17:44:51 +0900

> No, you can't print Japanese *glyphs* in that situation.

That's bad enough.

Remember that the "I-D file formats and internationalization"
thread was initiated by Robert Sayre with the following statement:

: Unicode support is a different matter. I find the current IETF policy
: to be incredibly bigoted. Many RFCs and I-Ds are currently forced to
: misspell the names of authors and contributors, which doesn't seem
: like correct attribution to me.

> Characters and glyphs are not the same thing.

Tweaking definitions on "Characters" does not change the
reality. PERIOD.

						Masataka Ohta

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Dec 2005 10:25:16 +0100

Masataka Ohta wrote:
 
> most native users of Latin alphabet can read Greek alphabet

I don't think so, s/Latin/Cyril/ maybe ?  Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 07 Dec 2005 11:25:20 +0100

Doug,
you say you imagine the following exchange is "off-topic for IETF". 
Please reread the RFC 3066 bis, and your own accompanying proposed 
registry accepted by the IESG after the Tunis deal. And reread RFC 
3935. _You_ trapped the IETF in pretending it is competent in matter 
of language identification, language tagging, script issues, national 
lingual policies, etc. to the point to take the world leadership (and 
the RFC 3935 accompanying responsibilities) with the mission to 
influence people to design, use and manage the Internet in that area.

And now you come and say this is off-topic?

Obviously it WAS off-topic. But you made it a core topic for the 
IETF. Saying it is off-topic now will not address it. I was 
interested in knowing how you are going to assume it. Now we start 
understanding.

Masataka Ohta does not discuss an ISO matter. He discusses an IETF 
langtag issue. I fully agree the IETF does not count the expertise 
and cross-expertise, and most probably the interest, necessary to 
seriously discuss IETF langtags. Nevertheless every IETF langtag 
issue is now going to escalate to this mailing list, the IESG and 
ulitmately to the IAB as the self-assumed world's authority on the matter.

I used the appeal now in limbo to make the IESG clarify their (your) 
contradictory position. I feel that a community having a problem to 
decide between ASCII Courier and ASCII PDF/A for its own use may not 
be very excited about deciding for the world how to best support 
kanji and hanzi, etc.

jfc

At 08:46 07/12/2005, Doug Ewell wrote:
>characters* are written in the Chinese and Japanese 
>traditions.  Anyone who knows about East Asian writing knows 
>that.  I do not admit there is a problem with unifying them in a 
>character-based (not glyph-based) encoding.
>
>No, you can't print Japanese *glyphs* in that situation.  Characters 
>and glyphs are not the same thing.
>
>If you (or your software) can use the distinction between ISO 
>2022-JP and Big-5, or EUC-TW, or CNS 11643, or whatever to determine 
>whether to display Japanese or Chinese glyphs, you (or your 
>software) can do the same by using the distinction between "ja" and 
>"zh".  If you can use ISO 2022 controls to switch between "the 
>Japanese repertoire" and "the Chinese repertoire," you can do the 
>same with language tags.  This is a question of style, not legibility.
>
>If you are saying—I'm not sure about this—that the same Ie ISO 10646 
>code point needs to be displayed in both the Japanese and Chinese 
>glyphic traditions in the same Japanese-langauge text, and that only 
>ISO 2022 is adequate to indicate which glyphs to display, then I 
>ask: how is this problem solved in handwritten text?
>
>Latin alphabet.  They can certainly read Greek Î', because the Latin 
>A is derived from it.  They might get terribly confused by Greek Î— 
>and Î¡ and Î§, which are not equivalent to the Latin letters they 
>resembleâ€"unless, of course, they are familiar with the use of 
>Greek letters in professional or fraternal organizations, which is 
>its own red herring.
>
>Most scholars of writing systems disagree with your premise that 
>Chinese hanzi and Japanese kanji are two separate writing systems in 
>the same way that Latin and Greek are separate.  Latin and Greek are 
>not simply glyph variants of one another.
>
>I do not.  ISO 10646 is a cornerstone of modern software internationalization.
>

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Dec 2005 13:22:49 +0100

JFC (Jefsey) Morfin wrote:

> _You_ trapped the IETF
[...]
Hogwash

> He discusses an IETF langtag issue.

Not that I'm aware of.  3066bis language tags allow scripts
like Hani, maybe this even helps for his purposes.

> I fully agree the IETF does not count the expertise and
> cross-expertise, and most probably the interest, necessary
> to seriously discuss IETF langtags.

So you still agree with yourself that Harald, Martin, Mark,
Addison, Ned, and others are no experts wrt language tags.

> the appeal now in limbo

For now it's rejected, http://ietf.org/IESG/APPEALS/?C=M&O=D

---

From: Erik Huizer <[email-masked]>
Date: Tue, 06 Dec 2005 23:55:39 +0100

i had RFC-1984 translated into French just after it appeared. served me 
well for several discussions in France at the time in which I was involved 
(as an IAB member at the time).

No normative references, but translating it to get the point accross with 
some politicians helped.

Erik

--On dinsdag 6 december 2005 9:33 +0100 Harald Tveit Alvestrand 
<[email-masked]> wrote:

> my Japanese skills aren't great enough to know if I found the ones that
> are there.
>
> Others will have to say if the result has been useful to someone or not;
> if I read the tea leaves correctly, none have translated more than 100
> RFCs.
>
>                   Harald
>
>

---

From: Tim Bray <[email-masked]>
Date: Wed, 07 Dec 2005 11:55:45 -0800

> You should admit that ISO 10646 useless for internationalization.

Hogwash.

Which is to say, for the benefit of those who have not had to  
internalize the complicated world of standardization and  
internationalization: Mr. Ohta's point of view represents the  
position of a tiny minority; huge swathes of widely-deployed  
standards and technology rely totally on 10646/Unicode, and they tend  
to work well, and they tend to deliver high-quality experiences to  
their users, including Japanese users. -Tim

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 08 Dec 2005 05:50:56 +0900

Tim Bray wrote:

So, you gave up on technical points. OK.

> internationalization: Mr. Ohta's point of view represents the  position 
> of a tiny minority; huge swathes of widely-deployed  standards and 
> technology rely totally on 10646/Unicode, and they tend  to work well, 
> and they tend to deliver high-quality experiences to  their users, 
> including Japanese users. -Tim

I know. Read RFC1815. I wrote it to demonstrate Unicode usable for
some local purpose, though it is unrelated to internationalization.

As a random collection of local characters, Unicode, in theory, works
in any such local environment including Japanese one.

However, people with established existing local schemes, including
Japanese, keep using them, because Unicode is no better and the
existing local schemes are more efficient.

There is no point to some form of local version of Unicode, as we
must specify which local version we are using. RFC1815 gives
examples of such local versions.

						Masataka Ohta

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 07 Dec 2005 19:52:28 +0100

At 13:22 07/12/2005, Frank Ellermann wrote:
>Not that I'm aware of.

Why not to ask him?

>3066bis language tags allow scripts like Hani, maybe this even helps 
>for his purposes.

Subjective affirmations mared the language area. Now IETF assumes 
responsability, more documentation by local experts is advisable?

>So you still agree with yourself that Harald, Martin, Mark, Addison, 
>Ned, and others are no experts wrt language tags.

I am no expert. I am a user calling for an expertise I can trust and 
rely upon. I did not find it yet. I only found a Unicode organized 
party defending a structured unilateral proposition partly addressing 
the sole case they are interested in. And deliberately refusing to 
even consider my other user's needs and relations with their competition.

>For now it's rejected, http://ietf.org/IESG/APPEALS/?C=M&O=D

Get your facts together. You confuse cases. The denial of appeal 
Brian Carpenter just announced confirms my point above. It confirms 
that "the problem is the user". I did not want to "win", but to 
obtain the clarification detailed in the text you can now read.

The consequences are substantial for the future of the Internet. So, 
I will appeal to the IAB to get a final guidance. If it is confirmed 
I will be sure I can carry our initial plans without being accused of 
creating a new "alt-root" situation over an "alt-IANA" language registry.

jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 8 Dec 2005 06:55:22 -0800

> influence people to design, use and manage the Internet in that area.

It has already been explained countless times, for those who care to 
read and understand, that neither RFC 3066bis nor its predecessors RFC 
3066 and 1766 establishes the IETF as a linguistic authority.  It 
establishes a mechanism by which the language in which content is 
expressed can be identified.

> langtag issue.

Ohta and I are never going to agree on this Han unification issue, but 
at least I suspect he understands that it is not "an IETF langtag 
issue."  It is nothing of the sort.  It is a dispute over the design of 
ISO 10646.

You know, not everything that anyone ever says can be twisted into an 
argument against RFC 3066bis.

> So, I will appeal to the IAB to get a final guidance.

What a dismal life you must lead, if your only joy is in tearing down 
the work of others.

Anyone who wants to know what RFC 3066bis is really about is invited to 
read it themselves: 
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt

I will not waste further keystrokes on this.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 09 Dec 2005 00:45:45 +0900

> issue."  It is nothing of the sort.  It is a dispute over the design of 

What a poor understanding on the internatinalization.

RFC 3066 is incorrect to state (despite my counter arguments with
counter examples):

   The issue of deciding upon the rendering of a character set based on
   the language tag is not addressed in this memo; however, it is
   thought impossible to make such a decision correctly for all cases
   unless means of switching language in the middle of a text are
   defined (for example, a rendering engine that decides font based on
   Japanese or Chinese language may produce suboptimal output when a
   mixed Japanese-Chinese text is encountered)

The reality is that tags for content language is orthogonal to charset.

Japanese language can be expressed in ASCII as follows:

	Kore ha nihongo no bun desu.

English language can be expressed Japanese characters.

Just like that, Japanese language can be expressed in Chinese
characters, Chinese language can be expressed in Japanese characters.

So, language tag does not help "to make such a decision correctly"
at all, even if "means of switching language in the middle of a text
are defined"

It is a plain fact of life not affected by IETF, though Harald has
been ignoring only to make text processing complex for any good
purpose.

> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt

It is as bad as 3066.

						Masataka Ohta

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Dec 2005 16:50:58 +0100

>>> He discusses an IETF langtag issue.

Good idea, what did he answer when you asked him before you
claimed that "he discusses an IETF langtag" issue ?  

What I read here was his known position that using the same
codepoints for Kanji and other scripts in Unicode is wrong.

> Get your facts together.

No problem, they announced it 11-15, and decided it at the
begin of 64th IETF meeting, now more than a month ago:

<http://permalink.gmane.org/gmane.ietf.announce/9881>
<http://permalink.gmane.org/gmane.ietf.announce/9882>
<http://permalink.gmane.org/gmane.ietf.ltru/4070>
<http://permalink.gmane.org/gmane.ietf.ltru/4047>
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=41630>

> You confuse cases.

Your various RfC 3934 cases and appeals are rather boring from
my POV, your RfC 3912 case is not yet "last called".

> The denial of appeal Brian Carpenter just announced

s/just/11-15/  I watch their "appeals" directory almost daily
(for procedural reasons unrelated to you and language tags).

> I did not want to "win", but to obtain the clarification
> detailed in the text you can now read.
s/now/11-15/
 
> I will appeal to the IAB to get a final guidance.

Bookmark <http://www.iab.org/appeals/>.  Bye, Frank