JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote: > I am sorry to impose that kind of response - and a large number of > mails. But this shows the problem to protect an open R&D capacity > against a chapel, which as some good points. And a non-profit R&D > against people sharing in a commercial competing consortium. Since most of M. Morfin's messages make at least passing mention of this supposed conflict between "open" and "commercial" interests -- the forces of good vs. the forces of evil, as it were -- I suppose some explanations about my own motives are in order. I do not have any commercial or financial stake in the success of the language-tag drafts. I am a software developer, working for a company that produces an internationalized software product, for (frankly) rather small values of "internationalized." Since we are working with the .NET platform, most of us have at least some familiarity with what the documentation calls "culture names," which are based on RFC 3066 but make use of some non-standard extensions. In addition to regular development, I am responsible for maintaining what we call "code lists," which are basically resource files shared between systems that otherwise know little about each other. I got involved in the language-tag project at its early stages, partly to avoid repeating some of the misconceptions I had had years earlier about RFC 3066. I had been keeping track of changes to ISO 639 and 3166 for many years anyway, so when the concept of a comprehensive language subtag registry came up, I mocked up my own "example" registry that matched the description in the draft. That "example" eventually became the proposed initial registry. I have developed, on my own time and with no company assistance, a small utility program that generates and validates language tags according to the current draft. It contains a database that is compiled programmatically from the text registry (into a DLL). It is flexible in the sense that the database can be updated independently from the main program. It understands the concept of extended-language subtags, although none are defined in the current draft. The IETF may wish to consider this "running code," or a "working implementation," for purposes of evaluating the drafts, and if IETF members are interested in examining it to help with serious evaluation of the drafts -- not just to find reasons to tear it down -- I can make it freely available. (I have not released it yet, of course, because the RFCs on which it is based are only I-Ds.) Very importantly, this program is **NOT** a commercial endeavor. It could conceivably be made into one, or it culd be offered as freeware or shareware (although I have no specific plans to do either), but it could just as easily be converted to an "open source" project of the type often mentioned by M. Morfin. The point is that there is NO dichotomy between "free" (or "open" or "non-profit") and "commercial" (or "corporate") when it comes to the current drafts. The draft contains NO restrictions against open-source or non-profit implementation (I would think they would be strongly encouraged). There is nothing in the ABNF that prevents open-source development based on the proposed BCP. There are no IP constraints on any of the technology used in its development. Any existing protocols that make use of language tags, and stand to benefit from the proposed update, will benefit equally regardless of whether they are commercial or not. M. Morfin has argued that there are prevalent "running code" implementations that use his expanded language-tag syntax, which is not compatible with the syntax in the present draft. However, to date I have not seen any pointers to such an implementation, nor any evidence of the "prevalence" of this alternative syntax. Obviously any developer can write code that *does not conform* to a given standard, or proposed standard, but that says nothing about the standard itself, or about whether the non-conformant code or the syntax it does follow is somehow better. The arguments that RFC 3066 is widely ignored are specious as well; there are numerous examples of protocols that adhere to the RFC 3066 model. The fact that non-conformant implementations (like the culture identifiers) exist is not a justification for throwing away the model. To cite an example from another thread, we acknowledge that some mail software implements "Reply-To" poorly, but that does not mean the whole notion of "Reply-To" should be thrown away as irrelevant, or "not supported by open R&D solutions." I apologize for the length of this particular point, but I feel it is important. Not everyone who supports the draft does so out of commercial greed, and even those who happen to work for Big Commercial Behemoths might have higher motives. Some people just like the feel of an "open software vs. closed software" struggle, á la Richard Stallman or Eric Raymond -- note M. Morfin's reference to a "chapel," evoking images of Raymond's "The Cathedral and the Bazaar" -- but the truth is that this image simply doesn't apply to the LTRU draft. >> What I said, as anyone can see from reading the quote above, is that >> a 740-page I-D might be unwieldy enough that the IETF might consider >> a different procedural mechanism for delivering the information to >> IANA. > > Correct. > I do not see the need of all the innuendo above to repeat what I > quoted. It was quoted as though it proved "some of the problems resulting from the expected size of the language tag registry and the capacity of the langtag solution to fulfill the WG-ltru Charter." It does nothing of the sort. Whether IETF or IANA wants to deal with a 740-page I-D is entirely up to them. >> Since the charter neither refers nor alludes to ISO 639-6, there is >> no conflict with the charter if WG members disagree in regard to the >> *eventual* expansion of the scope of language tags to involve ISO >> 639-6. > > This repeated allusion to the Charter neither refering nor alluding > to ISO 639-6 is to be compared with the text of the Charter > (http://ietf.org/html.charters/ltru-charter.html) which says "It is > also expected to provide mechanisms to support the evolution of the > underlying ISO standards, in particular ISO 639-3". Peter Constable has already addressed the meaning of "the underlying ISO standards." ISO 639-6 is not an underlying ISO standard for purposes of this draft. (It's not even a standard, in fact, not even a CD yet.) For that matter, ISO 6709 is also not an underlying ISO standard for purposes of this draft, so the draft does not permit tags of the form "fr+484816+0020708" either. > This kind of problem may be related to the refusal of the WG to start > from/analyse the Charter requirments? I understand the charter requirements just fine. Almost all of the WG does. > I do not know if I share concerns with Doug. I do share the concerns > of Doug. The concern quoted above was that a 740-page I-D might be unwieldy. I acknowledge that M. Morfin might share that concern. Happily, it is a concern for the next draft, not this one. >> I hereby disassociate myself with any statements made by M. Morfin >> concerning the drafts produced by the LTRU WG. I hope that is clear >> enough for IETF members. > > Since I said I supported his Draft .... "Disassociate" does not mean "disagree." It means I do not speak so as to bolster his point. >>> 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) >>> to 650 K (100 K zipped). This information, updates and additions >>> MUST be available to each of the on-line application of the devices >>> of billions of users. The Draft does not explain how. >> >> The WG decided this was an IANA implementation issue, and out of >> scope. > > Correct. This is exactly what I say. I suppose if we want to pursue this issue of huge daily updates and bandwidth consumption, we should start by asking how many implementations currently perform daily updates on the existing IANA Language Tag Registry, a resource which (of course) is necessary to implement RFC 3066 fully. > Doug said in another mail "I just think the two figures (7,600 and > 20,000) could be seen as representing a fundamental disagreement." > This is a legitimate concern at a time a LC is to engage the whole > IETF in a direction where you think this is unclear. I would not > qualify that of ust "talk". This is something loyalty calls you to > say, even if it is to explain why there is no fundamental > disagreement. 1. The charter does not refer to ISO 639-6, which will eventually encode 20,000 "languages and dialects." 2. The charter does refer to ISO 639-3, which will encode 7,600 languages, but only for future planning, for "evolution." 3. The proposed initial registry contains subtags based only on the existing standards: ISO 639-1 and 639-2, ISO 3166-1, ISO 15924, and United Nations M.49, as well as "variant" and "grandfathered" subtags based on the RFC 3066 registry. 4. Normative references to a not-yet-completed standard are bad, for the same reason that normative references to an I-D are bad. > NB. As a user, the langtag solution does not provide as much > possibilities, simplicity, flexibility than solutions using ISO 639-6 > (with the possible use of ISO 639-1/2/3 when necessary. This is IETF > not ISO. THERE IS NO ISO 639-6. There will be, some day, but such a standard does NOT exist now. Good heavens, the data is not even publicly available yet! Of course the language tag solution is not going to be based on a vapor standard. > I have documented enough (too much :-)) during these last days that I > support (one can read my mails of end of December 2004) the Draft > with the provision it is not exclusive and serves the Internet > community rather than exclude its R&D and innovation capacity. The purpose of language tags is interoperability. This purpose is not served if every organization invents its own extensions. The sections of the draft that deal with private-use tags and subtags are heavily laden with caveats to explain this. > Happily I support my Unicode co-Member Doug's own Draft and I thanked > him for the work he consciensiously achieved over the months > maintaining the base he now proposes as a Draft! (even if I doubt a > 740 pages I-D can be of real use in the future). I acknowledge M. Morfin's support for draft-initial, and thank him for his restraint in this message. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf