Subject: [Ltru] Re: Last call: BCP 47 second part.

From: Martin Duerst <[email-masked]>
Date: Wed, 21 Jun 2006 23:15:28 +0900

Dear LTRU members (cc IETF mailing list),

Here are my comments on how I (as a technical contributor)
propose to address the Last Call comments made below.
I hope others have some comments, too.

At 23:56 06/06/18, JFC (Jefsey) Morfin wrote:
>Dear IESG Members,
>
>1.  The proposed Draft is not about matching (it is absurd to say that my Italian can "match" your Japanese in order for us to understand each other better). It is about using pattern matching techniques in order to filter lists against a langtag with two results (max one answer, no max) and in two cases (well formed langtag or not). However, the wording is such that without examples it is difficult to understand the specifications of the pattern matching function that is being used - and therefore the possible applications and the purpose of the Draft.  The algorithm of this function is undocumented and there is no obligation to document it, what may lead to blocking conflicts if two filters may have to interoperate. This proposition is NOT scalable and does not intent to be scalable.

The matching draft of course makes sure that "ja" and "it" do not
match. Nothing absurd happening there. Also, what the draft actually
describes is matching language tags against language ranges; there
are three matching variants, two for filtering and one for lookup.

Some of the matching procedures indeed have to be read carefully.
But the WG made every attempt to describe them carefully, going
through several iterations. And we provide examples, too.

The main applications envisioned by the draft are described in the draft,
they are things such as selection of documents (e.g. when searching)
or document pieces (e.g. for styling) in the case of filtering and
finding the best match to return documents or document fragments
in the case of lookup (the prototypical example being HTTP language
negotiation).

As for conflicting filters, there is no requirement that two filters
(e.g. in two different protocols) produce exactly the same result.
Different protocols may have different needs. That's why the draft
leaves some specifics for a particular protocol to be decided.

As a result, I do not see anything in comment 1. that would need
addressing in the current draft.

>2. Either RFC 3066 Bis is well written (what I think we achieved if strictly limited to the Internationalized ASCII Internet) and well applied (what I can see that it is not the case: the review mechanism does not respect RFC 3066 Bis) and the filtering is already built-in, and the functional strategies are to be specific to applications and protocols. Or that Draft, which does not seek to first ensure that langtags respect RFC 3066 Bis (i.e. being well formed or corrected in order to become well formed), is a negation of RFC 3066 Bis. I think that authors had filtering in mind (it was the apex of the first unique document) and did not realise that the work achieved in cleaning the first part made its correction by the second part not necessary anymore. That is if the whole purpose was not a non documented use of the filtering (users mass profiling). If it was not the whole document can be written as "make sure langtags are well formed and feed them on the pattern
 matching function of your application/protocol to obtain the results it needs along your language management strategy".

The commenter seems to claim that draft-ietf-ltru-matching conflicts with
draft-ietf-ltru-registry (here called RFC 3066bis) because the later
defines well-formed tags while the former does not require well-formed
tags. The reason for not requiring checking for well-formed tags when
matching was discussed extensively in the WG. There is a very clear reason:
requiring this would require to check the IANA language subtag registry,
potentially for every matching operation, which was considered operationally
infeasible. It would also be an unnecessary performance punishment for
those who actually use well-formed tags. In general, non-wellformed
tags or ranges will simply not match anything, which is just fine.

The commenter is correct in that there is no absolute need for this draft;
each protocol or format could come up with it's own way of matching
language tags. After all, RFC 3066bis defines how these tags are built,
and (to a certain extent) what they mean. However, I consider the current
draft valuable because it helps protocol/format designers, who in general
are not experts on language tags and language matching, to choose the
right kind of matching scheme. Also, one matching scheme was already
described in RFC 3066, and so it would be difficult to obsolete
RFC 3066 without this draft.

I therefore don't see any change that would be needed in the current
draft to address comment 2.

>3. "*" restrictions in the pattern matching function can hardly be understood without several examples. They add usage limitations to the RFC 3066 Bis format, where they should be documented ュ or the Draft cannot be part of BCP 47. This certainly belongs to the language constraining strategy of the WG-LTRU affinity group and to the interests a co-Chair recently documented. But this is unacceptable to most users, even if it is certainly favourable to a national strategy and to the members of a given consortium. I therefore submit that the IESG Members who are citizens of that nation, or members, or employees of the members of that commercial consortium have a COI.

There are no restrictions on the use of "*" in language ranges.
There is a very specific treatment of "*" wildcard components in
language ranges for extended filtering. The actual algorithm in
the draft is described carefully, and an explanation for why it is
the way it is is given. This matching algorithm does not add
any usage limitations to RFC 3066bis. On the contrary, it was
carefully designed to work well together with RFC 3066bis.

I do not know of any concrete example where the matching behavior
would be unacceptable. Any claims that it is "unacceptable to
most users", are therefore, in my view, just made up out of thin air.

Also, I have no idea what is meant by "language-constraining strategy".
If anybody wanted to restrict the use of certain languages in certain
parts of the Internet, they could easily already have done that based
on RFC 3066, or could do based on RFC 3066bis, or even just based on
statistical analysis of the actual content transmitted (with techniques
such as trigrams). And certainly nobody who actually wanted to do such
a thing would ask for an RFC or other kind of standard to try to
legitimate such restrictions, nor would I hope anybody would condone
such behavior just because it would make use of an RFC.

As a result, I don't think that anything needs to be done to address
comments 3.

>4. All the above  means that the Draft is useful in at least two circumstances:
>   - if the langtags are not well formed or do not respect the principles of ISO 639-4 and/or RFC 3066 Bis.
>   - if the langtags are used for other purposes that are undocumented at the WG-LTRU Charter.
>These circumstances should be documented.

ISO 639-4 is still being worked on. The possibility of using non-wellformed
tags is not something the draft is designed to do; it is just a consequence
of not requiring checking for well-formedness (to avoid operational problems).
The draft explicitly says that there is no need to check for well-formedness,
so I don't see what would need to be documented further.

The draft, like most IETF work, mentions possible uses of the technology,
in particular as examples to explain design decisions or choices of options
for the users (in the case of the draft, the direct users are protocols
and formats). Any attempt to describe any and all possible uses for a
technology invariably fail, and so shouldn't be attempted in the first
place.

I therefore don't see any change that would be necessary based on
comment 4.

>5. The security section should mention that this Daft encourages the disrespect of the RFC 3066 Bis format and further assists dangerous projects that the IETF has refused to mention in RFC 3066 Bis, such as lingual, cultural, racial, and religious profiling through retro-meta-spam ("I know who you are through which langtags you are not aware that you respond to"), two-tier Internet based upon the lingual characteristics of the users and their supposed market value, lack of conformance to ISO 11179, which may lead the IETF, stakeholders, and users to inadequate, costly, and delaying strategies or to conflicts with the Multilingual Internet - as in the sad DoS against the leading economic language ("en-EU") - or to legal access bans by democratic or privacy oriented countries. All of this lends itself to incentives for an Internet fragmentation.

As explained above, there is no disrespect for RFC 3066 bis formats, just operational
considerations. Also, the draft does not assist any of the 'dangerous projects' mentioned
above; any of these projects are, if some entity is determined to do them and
has the necessary access, easily possible with various other means.

The problem that RFC 3066bis does not allow en-EU is a problem of RFC 3066bis,
and may have to be addressed in a future revision, but does not affect the
matching draft now in last call.

Again, I don't see anything here that would need to be changed in the
current draft to address this comment.

>6. As far as I understand, two Draft compliant filters may result in different responses for the same filtering list and document. My concern is the interoperability of the proposed BCP 47 with Multilingual Internet registries, tags, etc. This interoperability is not ensured ュ and there is no prospect to see it insured as it is purposely ignored by authors. This represents no incentive for developers.

The three matching schemes described in the draft all come with a small number
of options. In this sense, it is e.g. possible that two different protocols,
having choosen different options, will lead to different results. An example
would be an HTTP server serving a document in a different language than a
corresponding FTP server (assuming somebody added language negotiation to
FTP) for requests with the same language priority list. But as such a setup
is highly fictional, and the two servers are configured separately anyway,
having different results simply because of different configuration (rather
than different language matching), or tweaking the configuration to make
the results match, are both possible. So this kind of interoperability is
not of importance in practice.

Also, it is difficult to try to ensure interoperability with something
called 'Multilingual Internet registries' when such a thing does neither
exist on paper nor in practice.

So there is nothing in comment 6 that would require any changes
in the current draft.

>7. The acknowledgement section mostly quote those who contributed to the pre-WG-LTRU document (the three WG-LTRU Draft existed prior to the creation of the WG which never studied and tried to conform to its Charter). This is the privilege of authors to quote who supported them best. However, in this case the document was considerably cleaned through the tough life of the WG. Also, most of the names being quoted are widely known as belonging to a non-IETF affinity group, what enforces the external understanding that BCP 47 documents are actually not IETF documents. This will most probably limit their consideration. After one year of tough debates I can testify these, good or not, three documents are IETF documents for the Internationalized ASCII Internet. I listed the names I consider missing in a Last C all mail.
>
>Authors either did not read it or are keeping harassing me, since they continue asking for an input. I quote my mail: "every contribution can be a key stone in the final construct. That people like Michael Everson, Ned Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel Suignard, and Tex Texin are not quotted seems odd. Others like Scott Hollenbeck and Sam Hartman really helped. What about Karen Broome, M.T. Carrasco Benitez, N. Piercei? Inputs or help from Brian Carpenter, Ted Hardie, Dylan N. Pierce are real.". I do not ask my name to be listed there since I know "it is not [the] interest [of some in the list] to be associated with [my own] name".
>
>Or would that mean that the IETF does not really back this deliverable? The question here is: does the IETF wants to influence the world (RFC 3935), document the Internationalised ASCII Internet, or serve the Multilingual Internet development. Many would like to know.

The claim that the acknowledgement section mostly quotes those who contributed to
the pre-WG documents is in stark contrast with the description of the editors about
how they have formed that list of names. Most if not all the people mentioned above
are acknowledged by reference, pointing to acknowledgement sections in related
documents. In my function as co-chair, I have asked if anybody feels left out
both on the WG list and on the IETF list; I have not received anything from
anybody.

As a technical contributor, I don't think there is any need for any change here.

>All the best.
>jfc
>
>PS. Having transparency in mind I copy the IETF main list. This LC ends tomorrow. I do not intent to address the comments. But I will certainly consider them in the appeal I suspect to be unfortunately necessary (NB. Before their first day decision to keep with a twice IETF LC failed document, I proposed the WG-LTRU Chairs to co-write the Drafts so we could finish the work in a few months. I obviously  eventually get step by step all what I wanted - in the documents or in the real world: but what a waste of time and effort). Cheers.

I remember well that specially at the start of the WG, the WG co-chairs
repeatedly asked for actual textual contributions. These were few and far
between, and were usually rejected by the WG after some discussion.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

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

---

From: John Cowan <[email-masked]>
Date: Wed, 21 Jun 2006 20:33:46 -0400

> I hope others have some comments, too.

Meta-comment:  Well done (which is what Jefsey will be, too).

-- 
John Cowan   [email-masked]    http://ccil.org/~cowan
I come from under the hill, and under the hills and over the hills my paths
led. And through the air. I am he that walks unseen.  I am the clue-finder,
the web-cutter, the stinging fly. I was chosen for the lucky number.  --Bilbo

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 21 Jun 2006 18:39:34 -0700

I fully agree with Martin. Nice job.

Mark

On 6/21/06, Martin Duerst <[email-masked]> wrote:
> >1.  The proposed Draft is not about matching (it is absurd to say that my
> Italian can "match" your Japanese in order for us to understand each other
> better). It is about using pattern matching techniques in order to filter
> lists against a langtag with two results (max one answer, no max) and in two
> cases (well formed langtag or not). However, the wording is such that
> without examples it is difficult to understand the specifications of the
> pattern matching function that is being used - and therefore the possible
> applications and the purpose of the Draft.  The algorithm of this function
> is undocumented and there is no obligation to document it, what may lead to
> blocking conflicts if two filters may have to interoperate. This proposition
> is NOT scalable and does not intent to be scalable.
>
> >2. Either RFC 3066 Bis is well written (what I think we achieved if
> strictly limited to the Internationalized ASCII Internet) and well applied
> (what I can see that it is not the case: the review mechanism does not
> respect RFC 3066 Bis) and the filtering is already built-in, and the
> functional strategies are to be specific to applications and protocols. Or
> that Draft, which does not seek to first ensure that langtags respect RFC
> 3066 Bis (i.e. being well formed or corrected in order to become well
> formed), is a negation of RFC 3066 Bis. I think that authors had filtering
> in mind (it was the apex of the first unique document) and did not realise
> that the work achieved in cleaning the first part made its correction by the
> second part not necessary anymore. That is if the whole purpose was not a
> non documented use of the filtering (users mass profiling). If it was not
> the whole document can be written as "make sure langtags are well formed and
> feed them on the pattern
> matching function of your application/protocol to obtain the results it
> needs along your language management strategy".
>
> >3. "*" restrictions in the pattern matching function can hardly be
> understood without several examples. They add usage limitations to the RFC
> 3066 Bis format, where they should be documented ュ or the Draft cannot be
> part of BCP 47. This certainly belongs to the language constraining strategy
> of the WG-LTRU affinity group and to the interests a co-Chair recently
> documented. But this is unacceptable to most users, even if it is certainly
> favourable to a national strategy and to the members of a given consortium.
> I therefore submit that the IESG Members who are citizens of that nation, or
> members, or employees of the members of that commercial consortium have a
> COI.
>
> >5. The security section should mention that this Daft encourages the
> disrespect of the RFC 3066 Bis format and further assists dangerous projects
> that the IETF has refused to mention in RFC 3066 Bis, such as lingual,
> cultural, racial, and religious profiling through retro-meta-spam ("I know
> who you are through which langtags you are not aware that you respond to"),
> two-tier Internet based upon the lingual characteristics of the users and
> their supposed market value, lack of conformance to ISO 11179, which may
> lead the IETF, stakeholders, and users to inadequate, costly, and delaying
> strategies or to conflicts with the Multilingual Internet - as in the sad
> DoS against the leading economic language ("en-EU") - or to legal access
> bans by democratic or privacy oriented countries. All of this lends itself
> to incentives for an Internet fragmentation.
>
> >6. As far as I understand, two Draft compliant filters may result in
> different responses for the same filtering list and document. My concern is
> the interoperability of the proposed BCP 47 with Multilingual Internet
> registries, tags, etc. This interoperability is not ensured ュ and there is
> no prospect to see it insured as it is purposely ignored by authors. This
> represents no incentive for developers.
>
> >7. The acknowledgement section mostly quote those who contributed to the
> pre-WG-LTRU document (the three WG-LTRU Draft existed prior to the creation
> of the WG which never studied and tried to conform to its Charter). This is
> the privilege of authors to quote who supported them best. However, in this
> case the document was considerably cleaned through the tough life of the WG.
> Also, most of the names being quoted are widely known as belonging to a
> non-IETF affinity group, what enforces the external understanding that BCP
> 47 documents are actually not IETF documents. This will most probably limit
> their consideration. After one year of tough debates I can testify these,
> good or not, three documents are IETF documents for the Internationalized
> ASCII Internet. I listed the names I consider missing in a Last C all mail.
> >
> >Authors either did not read it or are keeping harassing me, since they
> continue asking for an input. I quote my mail: "every contribution can be a
> key stone in the final construct. That people like Michael Everson, Ned
> Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel Suignard, and Tex
> Texin are not quotted seems odd. Others like Scott Hollenbeck and Sam
> Hartman really helped. What about Karen Broome, M.T. Carrasco Benitez, N.
> Piercei? Inputs or help from Brian Carpenter, Ted Hardie, Dylan N. Pierce
> are real.". I do not ask my name to be listed there since I know "it is not
> [the] interest [of some in the list] to be associated with [my own] name".
> >
> >Or would that mean that the IETF does not really back this deliverable?
> The question here is: does the IETF wants to influence the world (RFC 3935),
> document the Internationalised ASCII Internet, or serve the Multilingual
> Internet development. Many would like to know.
>
> >PS. Having transparency in mind I copy the IETF main list. This LC ends
> tomorrow. I do not intent to address the comments. But I will certainly
> consider them in the appeal I suspect to be unfortunately necessary (NB.
> Before their first day decision to keep with a twice IETF LC failed
> document, I proposed the WG-LTRU Chairs to co-write the Drafts so we could
> finish the work in a few months. I obviously  eventually get step by step
> all what I wanted - in the documents or in the real world: but what a waste
> of time and effort). Cheers.
>