Subject: RE: [Ltru] draft-06 of matching prototype...

From: "Addison Phillips" <[email-masked]>
Date: Tue, 15 Nov 2005 10:40:15 -0800

> 
> I really like the restructuring. Interesting how much value it is just
> to introduce terminology like 'filtering'; it will make the situation
> much clearer to users.
[Addison Phillips] 

I thought it worked out pretty well.
> 
> What I think it also makes clear is that we shouldn't be including
> 3.2.2. Extended Range Lookup. A lookup has to give a precise, single
> answer whenever there are a number of possible matches. The formulation
> that the draft gives does not distinguish in priority among matching
> items. 
[Addison Phillips] 

I agree, although I would take a different approach.

For HTTP in particular, the Accept-Language header might be used for both filtering and lookup applications. It would be useful I think to specify a mapping from Extended to Basic Language Ranges in the (sole) Lookup scheme.

I think the mapping works thusly:

1. If the Extended Language Range starts with "*", then the Basic Language Range is "*".

2. Otherwise, remove any "*" subtags and their associated trailing "-" if it exists.

Thus a request for:

  "*-US" => "*"
  "en-*-US" => "en-US"
  "sr-*-CS" => "sr-CS"
  "sl-*-*-nedis" => "sl-nedis"
  "de-*-1901" => "de-1901"
  "de-*" => "de"

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture.
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Mark Davis <[email-masked]>
Date: Tue, 15 Nov 2005 12:06:43 -0800

We could consider that, but...

If I lookup "*" and "fr" and "en" are available, which gets returned? 
Can't have that kind of indeterminacy in lookup in the spec. So if we 
want to take that approach, then I suggest the following mapping:

1. Remove all trailing "-*" strings.
2. Remove "-*" for the script if there is Suppress Script
3. If the tag has any remaining "*", then it cannot be mapped. If the 
range was part of a priority list, then ignore it for lookup. If there 
are no values left, then the lookup fails (or returns the default value).

An implementation may (MAY?) chose not to do #3 if it has a mechanism 
for prioritizing lookups.

[Add note in Security section that such behavior that causes differences 
between implementations may be open to security problems.]

Mark