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

["Addison Phillips" <[e-mail]>]

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:[e-mail]] 
> Sent: vendredi 23 juin 2006 19:35
> To: LTRU Working Group
> Subject: Re: [Ltru] Fwd: Last call: BCP 47 second part.
> 
> 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.
> 
> At 17:12 06/06/22, Martin Duerst wrote:
> >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:ietf-r
> [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:ietf-r
> [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
> 
> 
> #-#-#  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
> 
> 


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