Last call: BCP 47 second part.

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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf