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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf