Subject: wildcards in extended ranges (was RE: [Ltru] draft-06 comments: choice of range)

From: "Addison Phillips" <[email-masked]>
Date: Fri, 18 Nov 2005 14:05:56 -0800

(I'm going to reply to things individually to keep the mail threads manageable.)

> >Agreed, although I tend to think we should go the other direction and say
> MUST.
> >
> >
> If we say must, then we are really saying that any input range x-y-z-w
> acts like x-*-y-*-z-*-w, whenever something could go between. Since we
> say the algorithms work in the absence of parsing the language tag, that
> means putting them in all the time. Seems like a bit much, but I'll mull
> it over.

It doesn't say that the algorithms work in the absence of parsing the language tags. It says they work in absence of the registry. Extended language ranges require length/content based parsing of both the range and the tag in order to work. Otherwise you can't tell what a "*" is supposed to match (unless you require all of the fields to be filled in).

Ideally, extended range filtering and scored filtering with a threshold of "0" should produce the same sets, or at least I think they should. Having written an extended range filter and just finished a scored filter, I haven't tested it extensively yet.

However, I do note that I had to parse both range and tag to make extended work and would need to even if missing items are not "*"... I have to know which subtags I have in order to match any "*" values that *do* occur. The only time my implementation goes to the registry, though, is for the list of grandfathered items.

So, yes, we are saying x-*-y-*-z-*-w.

Let's take some examples. If I have a range "en-US", should it match "en-Latn-US" or not? Basic ranges do NOT match those tags. Extended ranges, as currently written, DO match those tags.

If I have de-*-1901, does it match "de-Latn-1901"? "de-DE-1901"? What does a single * mean?

The current text says "MAY" for missing elements, allowing the first example to match or not at an implementation level. But I think it would be better if we chose one or the other.

My 2 cents.

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: Fri, 18 Nov 2005 17:28:30 -0800

>It doesn't say that the algorithms work in the absence of parsing the language tags. It says they work in absence of the registry. Extended language ranges require length/content based parsing of bo…
You're right. My lapse.

>So, yes, we are saying x-*-y-*-z-*-w.
I'm ok with that, let's just make it slightly clearer in the text.

>The current text says "MAY" for missing elements, allowing the first example to match or not at an implementation level. But I think it would be better if we chose one or the other.
My opinion is that we are describing a process. Within *that* 
description, they should be MUSTs. At the end we say of each process we 
say the allowed ways that a protocol can add specifications. That makes 
it very clear to users what they can expect out of a protocol *if it 
doesn't add any additional specifications*.

So, I'm ok with MUST as long as we have the escape clause at the end.

---

From: Martin Duerst <[email-masked]>
Date: Sun, 20 Nov 2005 16:15:12 +0900

>>The current text says "MAY" for missing elements, allowing the first 
example to match or not at an implementation level. But I think it would be 
better if we chose one or the other.
 >My opinion is that we are describing a process. Within *that* 
description, they should be MUSTs. At the end we say of each process we say 
the allowed ways that a protocol can add specifications. That makes it very 
clear to users what they can expect out of a protocol *if it doesn't add 
any additional specifications*.
 >So, I'm ok with MUST as long as we have the escape clause at the end.

Not only in this specific context, but in general, I very much agree.
Earlier versions of our draft just left too many MAYs and SHOULDs
that confused protocol designers and implementers (who don't necessarily
understand all the details).

Regards,    Martin.