Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Wed, 06 Jul 2005 19:20:37 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A14F61B4D for ; Wed, 6 Jul 2005 19:20:37 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20165-02 for ; Wed, 6 Jul 2005 19:20:33 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id C728061B43 for ; Wed, 6 Jul 2005 19:20:32 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDZN-0006E5-2b; Wed, 06 Jul 2005 13:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqA1p-0006Gr-MR for ltru@megatron.ietf.org; Wed, 06 Jul 2005 09:33:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21128 for ; Wed, 6 Jul 2005 09:32:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqAE9-0004dH-Io for ltru@ietf.org; Wed, 06 Jul 2005 09:46:14 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dq9mz-0002KA-1D for ltru@ietf.org; Wed, 06 Jul 2005 06:18:09 -0700 Message-Id: <6.2.1.2.2.20050706151619.0462a8e0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 06 Jul 2005 15:17:01 +0200 To: ltru@ietf.org From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-Mailman-Approved-At: Wed, 06 Jul 2005 13:20:19 -0400 Cc: Subject: [Ltru] does the Draft gives all the guidelines required by the Registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org X-Virus-Scanned: amavisd-new at alvestrand.no This WG has to reorganise a IANA registry (since for the time being the RFC 3066 IANA Registry is considered). Here is the most recent registration in that Registry. I will try to underline some of the complexity and confusion it contains by lack of RFC guidance, so everyone may check that the current Draft addresses these lacks and provides the guidelines and forms necessary to the language tags reviewers . This quick review will probably be useful for those on this list who work on an ISO 11179 metamodel for languages. >LANGUAGE TAG REGISTRATION FORM >Name of requester : Karen Broome >E-mail address of requester: karen_broome@spe.sony.com This information is of no interest to the users. It gives Karen Broome and possibly Sony a stewardship on the American Spanish some could seriously object. From this who is the es-419 steward in 2105? >Tag to be registered : es-419 >English name of language : Latin American Spanish Do we have a definition of language? Can the concept of "Latin American Spanish" be accepted as a language or as a metalanguage or as a variant or a language family, etc. according to this definition? Obviously references to ISO 639-4 will help but are not available yet. >Native name of language (transcribed into ASCII): espanol de America >Latina, espanol latinoamericano This information misses the French name of the language. >Reference to published description of the language (book or article): > >Lipski, John M. 1994. Latin American Spanish. Addison Wesley >Publishing Company. >Martin, Patrice. 2005. "The Quest for El Dorado: A Single Spanish for >All." Multilingual Computing & Technology. Vol. 12, No. 6 This kind of quote are of interest to some, but may also be contentious. I am not sure there are guidlines enough to avoid the contention. I also wander why such an information would be provided for this langtag while it is not for other. There should be only one metamodel for a concept in order to avoid conflicts. This part is alse a partial attempt to transform the es-419 concept into a value (registration by reference, instead of registration by declaration). I am not sure that this value is explicit enough and can not be considered as a registration by real documentation . It can be explicit for a linguist. I am not sure it is explicit for all the users. Have some rules been given that a computer or a non linguist could use to distinguish es-419 from es? >Any other relevant information : Same remark as above. >It is a common business practice to localize content into a neutral >version of Latin American Spanish to serve all or most Spanish-speaking >regions in Latin America. This code is intended to identify this neutral >variant of Latin American Spanish and distinguish it from Castilian found >in Europe. This is a standadisation text. "all or" does not fit (it seems however in line with the lack of clarity of RFC 3066 which the advantage of RFC 3066 as it can accept much). This rises the question of the American Spanish: what are the differences. What is the New Mexico Spanish? >This tag is intended for use on content that has been tailored for Spanish >audiences throughout Latin America. "use on content": I do not understand the full meaning. I expected identify, describe ...? "audience": is this a generic enough name? Is the Registry to consider the mode or the language? The use of "audience" seems to imply that the tag is to characterise "out" streams (IETF takes care of network protocols). > It is not a collection for all Latin American Spanish varieties; it > merely indicates that the author made choices in vocabulary, grammar, > spelling, etc. that would make the content reasonably acceptable to speakers Here we have a confusion. The text both speaks of author (source of content) and of speakers (other sources of content). I suppose that he wants to say "readers". This kind of confusion would be removed if instead of having to comment the tag, the examiner was provided a form giving him strict guidlines (identical for every tag). > of most or all Latin American Spanish varieties. (This tag does not > imply any further details regarding what those choices may have been, however.) This seems odd in a standardisation comment as it says that two people may legitimately have two orthogonal understandings of es-419. >This tag is intended primarily for cataloguing of localized content and >resources, rather than for specifying language preference on retrieval. This insist on the "out" or "sending" definition of a langtag. I have no problem with that, except that through "Latin America" the specification is through an "audience", i.e. through the expectation of a population? Or does that means that the langtag is to identify the way an authors responds to the expectations of a local population expressed in its own way to speak. I have no objection to that (it corresponds to a relational definition), but the definition should be explicit somewhere and scalable. Scalable means that the definition should be generalised and its technical implications (relation modes, non human interlocutors, etc.) should be addressed, so the examiner and the user of the registration form has a protocol defnition/documentation tool; >Ideally, a system should be able to deliver content labelled with this tag >in response to requests for any specific Latin American Spanish variety, >including but not limited to the following: the "not limited" seems to create a confusion with the "419" from the UN list. Unless it is a way to characterise the speaking audiences considering themselves attached to an es-419 community. I have no problem with that since it would be an IETF consistent definition attaching a language to an indentified network. But the notion should be generalised and its implications measured since they are certainly one of the basic elements of CRCs (Context and Reference Centres). But then we fall into the alanysis of Referents and Context issues which are the keys to the "not limited" vs. not "universal". In Internet architecture this means lingual classes. >es-AR, es-BO, es-CL, es-CO, es-CR, es-CU, es-DO, es-EC, es-FK, es-GT, >es-HN, es-MX, es-NI, es-PA, es-PE, es-PR, es-PY, es-SV, es-UY, es-VE. > >Of course, systems can also be implemented to offer this tag as a >user-preference option, Good. So we also have the langtag as a "in" descriptor. But here we have a partial decription: we have user preference but ignore if we can use it as a user capacity description. Can we use the langtag for language negociation and relation tuning towards best person to person interintelligibility. Also we have no hint about the kind of relation: is that a one to one, one to many, many to many? Is the negociation between pairs (senders or receivers) also possible in using the tag? > and a server should deliver content labelled with this tag when > requested for the same. Why? Does the Draft mention that SHOULD. What is the fall back possibility if it cannot. Up to now we are in a fluid human to human environment (also imposed by the current Draft). All the sudden we are on a machine to human (web site), machine to machine (web service), machine to underfined (mail, broadcast) environement. >On the other hand, it is not valid to assume that a request for "es-419" >can be serviced by returning content labelled as es-AR, or es-BO, es-CL, etc. Accepted. But is this the proper place to see this explicited? Should it not be part of warnings printed in the Draft defined form. Which other warnings should be provided to the user? >It would be appropriate to deliver content labelled with this tag in >response to the more generic request, "es" (cf. section 2.5 of RFC 3066). The wording seems extermely confusing. Why to use a specific es-419 if the wording is appropriate? At least priorities should be given and described: es-419 before es seems OK, but is as-AR to be delivered before or after es? I do not think these are minor questions. I am sure they belong to the Charter. I am not sure they belong to the Draft. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru