Subject: Re: [Ltru] editor's copy of matching updated...

From: r&d afrac <[email-masked]>
Date: Sat, 20 Aug 2005 02:36:40 +0200

Dear Addison,
I do not understand the meaning of the sentence in the introduction: 
" Given a set of language identifiers, such as those defined in 
[ID.ietf-ltru-registry], various mechanisms can be envisioned for 
performing language negotiation and tag matching.".

Either a language tags uses subtags registered in the IANA registry 
(except "x-") and obey to the ABNF (and the "such" seems a 
contradiction) or I do not see how you can envision mechanisms on a 
language identification system you do not know?

Or may be could you give an example of what could be another set of 
identifier which would not be defined in your Draft and could use the 
mecahisms you describe?

I have other remarks, but your response to this one may obviously change them.
jfc

On 19:44 19/08/2005, Addison Phillips said:
>Content-class: urn:content-classes:message
>Content-Type: text/plain;
>         charset="UTF-8"
>
>I still need to fix up the references (to match what was done in the 
>other drafts), do idnits, and run the ABNF checker, but I've posted 
>a copy of draft-04 of matching on inter-locale. Once I've done the 
>housekeeping I'll submit the update and produce a diff.
>
>http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.txt
>http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.html
>http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.xml
>
>Notable changes:
>
>- Updated the ABNF for extended language ranges as per Kent's 
>messages. Note that I added extensions to the ABNF this time.
>
>- Added a note to explicitly state that multiple stars can collapse 
>in Section 2.2.
>
>- Minor wordsmithing.
>
>- Expanded Section 2.2.3 (Scored Matching) significantly. I added 
>examples of different quadruples and cleaned up the text. I added 
>textual rules for handling grandfathered tags and to exclude extensions.
>
>- Updated the references to draft-registry and draft-initial.
>
>For the editors,
>
>Addison
>
>Addison P. Phillips
>Globalization Architect, Quest Software
>http://www.quest.com
>
>Chair, W3C Internationalization Core Working Group
>http://www.w3.org/International
>
>Internationalization is not a feature.
>It is an architecture.
>
>
>_______________________________________________
>Ltru mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: Martin Duerst <[email-masked]>
Date: Mon, 22 Aug 2005 16:05:20 +0900

[please use new subject for new issue, thanks!]

At 09:36 05/08/20, r&d afrac wrote:
 >Dear Addison,
 >I do not understand the meaning of the sentence in the introduction: " 
Given a set of language identifiers, such as those defined in 
[ID.ietf-ltru-registry], various mechanisms can be envisioned for 
performing language negotiation and tag matching.".
 >Either a language tags uses subtags registered in the IANA registry 
(except "x-") and obey to the ABNF (and the "such" seems a contradiction) 
or I do not see how you can envision mechanisms on a language 
identification system you do not know?

I think there are some very general kinds of matching that can apply
independent of the syntax. E.g. various completely different tagging
syntaxes may allow matching of a list of languages (e.g. the list of
languages somebody speaks or reads) against a particular language,
or they may have one way or another to deal with subset relationships.
Of course it may be possible to envision language tagging syntaxes where
even these kinds of matching don't make sense.

I think the above sentence does not say that the mechanisms described
later in the document can be applied to arbitrary syntaxes. It's just
a general statement in the introduction to motivate that there are more
than one way of matching, as described later in the draft.
A direct rewording that makes this clearer would be something like:

"For any kind of language identifiers, including those defined by
RFC3066bis, there is easily more than one of matching. Thus, this
document defines a set of ways of matching for the language tags
defined in RFC3066bis."

However, I'm not sure it is necessary to start with that much generality,
if the language tags of RFC2066bis need more than one way of matching,
that's enough motivation.

Regards,    Martin.

---

From: r&d afrac <[email-masked]>
Date: Mon, 22 Aug 2005 12:12:36 +0200

At 09:05 22/08/2005, Martin Duerst wrote:
> >I do not understand the meaning of the sentence in the 
> introduction: " Given a set of language identifiers, such as those 
> defined in [ID.ietf-ltru-registry], various mechanisms can be 
> envisioned for performing language negotiation and tag matching.".
> >
> >Either a language tags uses subtags registered in the IANA 
> registry (except "x-") and obey to the ABNF (and the "such" seems a 

Dear Martin,
I am afraid there is a confusion here. What Addison talks about is of 
a set of "language identifiers" (I do not know what it is compared 
with language tags) "such as those defined in" his Draft. I 
understand that his Draft describes the structure, content, 
construction, and  semantics of language tags" to be used on the 
Internet (BCP) when a language is to be indicated. This results in a 
strict ABNF and a registry of subtags.

I do not know the extent of what you name "syntax" when referred to 
this? The only understanding I have is: a different syntax means a 
different ABNF.

But I am confused because a different syntax does not affect the 
semantic, and a different syntax should not hamper the matching as 
you note it. The only reason why such a matching would not make 
senses would be when a different language tagging would support a 
different semantic. In saying that this is possible (I suppose in 
support of the Addison's text, therefore I suppose "practically, 
technically possible under the current Draft") I feel you say (and 
Addison says in using "such") what I say while supporting a document 
which (this is the way I understand it) forbids it.

> >Or may be could you give an example of what could be another set 
> of identifier which would not be defined in your Draft and could 
> use the mecahisms you describe?
>

I do not understand what you want to say here. A different syntax 
means a different ABNF. The "such" does not refer to mechanisms 
(there is no mechanism defined in the RFC 3066bis Draft), it refers 
to "language identifiers" what should mean ABNF plus registry.

But it is true that there should be several mechanisms defined (or 
simply exemplified) as some could be very specialised. Just one to 
give a practical example: I am a news agency and I survey RSS feeds 
to build a calendar. I am interested in pages where the date is 
expressed in a way my program and I can read it, among a list of 
languages I have someone more or less understand. I will therefore 
filter langtags in reference to the locale information on date 
format. This is a typical OPES job.

>document defines a set of ways of matching for the language tags

Full agreement. This clarifies the legitimacy of other types of 
language identifiers. ABNF + registry.

>if the language tags of RFC3066bis need more than one way of matching,

IMO it really does because:
- it clarifies a text which I find - and probably many will - find confuse.
- I would then have no objection to the text.
- the wording could be slightly extended to underline what you point 
out: this kind of matching may make sense in other language tagging 
systems which uses the same subtags.

Regards.
jfc