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

From: Martin Duerst <[email-masked]>
Date: Mon, 19 Jun 2006 15:28:17 +0900

Dear LTRU mailing list,

This series of Last Call comments on the matching draft came
through on the main IETF list. I'm forwarding it here for
further discussion.

Regards,    Martin.

>Date: Sun, 18 Jun 2006 16:56:00 +0200
>To: [email-masked]
>From: "JFC (Jefsey) Morfin" <[email-masked]>
>Subject: Last call: BCP 47 second part.
>List-Id: IETF-Discussion <ietf.ietf.org>
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,<mailto:[email-masked]?subject=unsubscribe>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,<mailto:[email-masked]?subject=subscribe>

>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.
>
>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.
>
>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.
>
>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.
>
>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.
>
>
>jfc
>
>
>
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

#-#-#  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: Martin Duerst <[email-masked]>
Date: Thu, 22 Jun 2006 17:12:17 +0900

As a co-chair, I have tried to make the comments mentioned
in the mail below into issues. Because most of the comments
are a mix of different issues, and many issues appear in
repeated comments, there is no one-to-one correspondence.

Also, there are some (parts of) comments that are addressed
directly to the IESG, are un-understandable, or are otherwise
not issues that the WG has to look into and address if necessary.
These are marked as such if necessary.

As usual, the list of Last Call Comments can be found at
http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. If you think
that anything in the issues list is wrong, please don't
hesitate to point it out.

At 15:28 06/06/19, Martin Duerst wrote:
>>List-Unsubscribe: 
><https://www1.ietf.org/mailman/listinfo/ietf>,<mailto:[email-masked]?subject=unsubscribe>
>>List-Subscribe: 
><https://www1.ietf.org/mailman/listinfo/ietf>,<mailto:[email-masked]?subject=subscribe>
>
>>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).

Made this issue 53: Topic/purpose of draft not (completely) described

>However, the wording is such that 
>without examples it is difficult to understand the specifications of the 
>pattern matching function that is being used

This became issue 54: not enough examples for matching algorithms

>- and therefore the possible 
>applications and the purpose of the Draft.

back to issue 53

>The algorithm of this function 
>is undocumented and there is no obligation to document it,

made this issue 55: algorithm is undocumented

>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.

made this issue 56: scalability/interoperability problem

>>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.

Created issue 57: matching draft does not respect registry draft
(no requirement for well-formedness)

>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".

Created issue 58: No need to describe specific matching schemes

>>3. "*" restrictions in the pattern matching function can hardly be 
>understood without several examples.

back to issue 54

>They add usage limitations to the RFC 
>3066 Bis format,

added issue 59: wildcards add usage limitations to registry draft

>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.

Potential/purported conflicts of interest for IESG Members are
not a topic for the WG. 

>>These circumstances should be documented.

subsumed under issue 53

>>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.

Created issue 60: security section should mention potential
for language-based censuring,...

>>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.

subsumed under issue 56

>>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.

This is already issue 52.

Regards,    Martin.

>>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.
>>
>>
>>jfc
>>
>>
>>

---

From: Martin Duerst <[email-masked]>
Date: Sat, 24 Jun 2006 11:35:28 +0900

John Cowan and Mark Davis have agreed with my assessment
(as a technical contributor) in
http://www1.ietf.org/mail-archive/web/ltru/current/msg05013.html
about how to (not!) deal with the issues below. I have not seen
any other comments. I have therefore (as a co-chair/shepherd)
marked the issues as 'rejected' or 'irrelevant' (the later for
issues where it's not clear how the issue could have possibly
been addressed).

All the issues from the IETF Last Call are now closed,
(see http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/)
so that we should be able to move ahead soon.

Regards,    Martin.

---

From: "Addison Phillips" <[email-masked]>
Date: Fri, 23 Jun 2006 19:58:46 -0700

FWIW, +1 for me as well.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.  

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]] 
> Sent: vendredi 23 juin 2006 19:35
> To: LTRU Working Group
> Subject: Re: [Ltru] Fwd: Last call: BCP 47 second part.
> 
> >>>   - 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.