ietf-nntp Language codes in NNTP

Martin J. Dürst mduerst at ifi.unizh.ch
Wed Oct 22 04:21:32 PDT 1997


On Tue, 21 Oct 1997, Brian Hernacki wrote:

> Petter Nilsen wrote:
> > > > o a language specification/negotiation extension
> > 
> > > While having the charset well known is great, it still doesn't help the
> > > Japanese user who gets error messages popping up in English. What I'd
> > > like to see is something akin to IMAP's LANGUAGE extension. This allows
> > > client and server to negotiate a non-default language to use for things
> > > like error messages, newsgroup descriptions, etc. Thoughts?
> > 
> > Ok, this sounds fine, but what _language_ should the LANGUAGE command take the
> > parameter in?  Native language introduces some charset problems..
> 
> The protocol need not be exposed to the users. A client UI could show
> the user "nihongo" (in kanji) in a language selection list but send
> "japanese" across the wire a parameter to the LANGUAGE command.
> 
> I believe some official list in ascii (UTF8) of common language names.
> Isn't this what IMAP does?

The official source for language denotation in protocols is RFC 1766.
This is not only used in every IETF stuff (email, HTTP, IMAP, ACAP,...)
I know that needs language denotation, but also in many other places
(HTML, XML,...). It is based on the relevant ISO standard for language
codes and country codes, but it is also extensible through IANA
registrations. The syntax is hyphen-separated tokens of case-insensitive
ASCII letters, somethingl like
	(a-zA-Z)* ["-" (a-zA-Z)*]*
with some length limitations and special rules, i.e. prefix x- for
unregistered stuff, prefix i- for iana-registered stuff, two
characters prefix for the two-character ISO codes, three-character
prefix reserved for three-character codes of a (very slowly!) upcomming
ISO standard revision.

Regards,	Martin.




More information about the ietf-nntp mailing list