Subject: Language support for scope enumeration

From: Dave Thaler <[email-masked]>
Date: Wed, 7 Oct 1998 17:11:08 -0400 (EDT)

One of the topics Mark, Pavlin, and I discussed during this week's
meeting on the MBone was that of language support for scope names.

We propose to do the following in MZAP:

* Replace the "scope name" in the MZAP spec with a list of 
  (language tag, scope name) pairs.  Language tags are described
  in RFC 1766.
* Each scope may have at most one name per language
  (multiples signal a config error).
* MAAS's will thus see all scope names.
* MZAP message may also label a specific (language tag, scope name) 
  pair as the "default name" to display if none matches your 
  desired language.  Since you have the actual language tag, 
  you can tell how to render the default name.
* Only one language (per scope) can be tagged as the default name.  
  (Multiples could signal a config error, such as if one router says 
  English is default and another one says French is default).

This would allow the abstract API and MDHCP to support language 
localization (which is required for them to get through the IESG 
acc. to Alvestrand and RFC 2277).  Presumably the enumerate scopes 
call would take a language tag as an input parameter and the MAAS 
would use that to decide which names to pass back.

Munil and Ross have each said that the above sounds reasonable.  
Any other comments from the list?

-Dave

---

From: Steve Hanna <[email-masked]>
Date: Fri, 9 Oct 1998 16:40:32 -0400 (EDT)

> >> > Do we want to *require* a language tag for each scope name? 
> >> 
> >> In the discussion between Pavlin, Mark, and I, one of them
> >> stated that sometimes you cannot render a name unless you know
> >> the language, and hence requiring a language tag may be 
> >> required.
> >
> >Since we are using Unicode, I expect that this situation would arise rarely. 
> >Does anyone have a specific example?
> 
> My recollection is that this is an issue with some far eastern
> languages.  I'm not an expert on this, but I heard that although
> Chinese and Japanese share Kanji and the unicode for them, you can't
> decide how to render them correctly unless you know which language
> it's in.

Then you would need to have a language tag for scope names that include those 
characters.

> I guess another example would be if you wanted to put the name through
> a text-to-speech system such as the one Jeremy Hall uses.  Different
> languages that are all using the same western european characters
> pronounce those characters differently.  You need to know which
> language it is to even get close to the correct pronunication (let
> alone accents :-).

Then his system wouldn't work very well if there wasn't a language tag.

I definitely would like all scope names to have a language tag. I'm just 
concerned that administrators may not do this or may not do it properly.
If nobody else is concerned about this, I won't worry about it.

However, we should be prepared to deal with systems that send malformed language 
tags (zero length, invalid characters, etc.). This is just another example of 
misconfiguration, I guess.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Thu, 22 Oct 1998 16:07:41 -0400 (EDT)

I apologize for taking so long to continue this discussion.

> > Assume you have a scope with two names: 
> > ("en-US", "Harbor") and ("en-UK", "Harbour"). If the client requests names 
> > with 
> > the language tag "en", which one do you return? If you say "the default," 
> > what if the default has language tag "fr"?
> > 
> > What if the scope has one name: ("en", "Harbor") and the client requested 
> > "en-UK"? If you say "the default," what if the default has language tag 
"fr"? 
> 
> I'm sure (from your previous comments) you might classify the following
> as "fancy language tag matching code".  In my opinion, however,
> it's simpler and more powerful in terms of misconfiguration detection 
> ability to specify two rules for MAAS's:
>    A request for "foo-bar" matches "foo" if "foo-bar" does not exist.
>    A request for "foo" may match any "foo-bar" (pick one arbitrarily)
> I'm not adamant about the above, but it appears to me to provide the
> best advantage-to-disadvantage tradeoff.

RFC 1766 section 2.1 says:

   Applications should always treat language tags as a single token; the
   division into main tag and subtags is an administrative mechanism,
   not a navigation aid.

I suggest that we provide two options: fetching all names for a zone or fetching 
a single name for each zone. In the latter case, the client would provide a 
language tag string. The MAAS would match this against all names for a given 
zone using a simple case-insensitive ASCII string comparison. The first one that 
matches would be returned. If none match, the default would be returned.

This should provide a simple solution for the common case, while allowing 
clients with special needs to handle them.

Are there any objections?

-Steve