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

[Martin Duerst <[e-mail]>]

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:
>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: [e-mail]
>>From: "JFC (Jefsey) Morfin" <[e-mail]>
>>Subject: Last call: BCP 47 second part.
>>List-Id: IETF-Discussion <ietf.ietf.org>
>>List-Unsubscribe: 
><https://www1.ietf.org/mailman/listinfo/ietf>,<mailto:[e-mail]?subject=unsubscribe>
>>List-Post: <mailto:[e-mail]>
>>List-Help: <mailto:[e-mail]?subject=help>
>>List-Subscribe: 
><https://www1.ietf.org/mailman/listinfo/ietf>,<mailto:[e-mail]?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. 


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

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
>>
>>
>>
>>_______________________________________________
>>Ietf mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]     
>
>
>_______________________________________________
>Ltru mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ltru


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


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