Re: [Ltru] Re: Last Call: language root file size (long)
At 06:11 29/08/2005, Doug Ewell wrote: JFC (Jefsey) Morfin 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. Dear Doug, I read very carefully your mail. I apologise if you felt personally concerned. None more than myself can understand that. You may realise that I am even accused to have defended my own consulting practice (you are an employee, I am an independent, sharing in non-profit I often also subsidise) because I started losing clients because a member used mails with his corporate name. My own involvement is in this area dates of 25 years and I accepted much to defend the users needs. This lead to many experimentations. The potential is huge for the users (to get back for everyone to what I did in 1985 for countries). All this is directly endangered by the Draft. 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. I refer to the piratical capacity to freely develop what they want. Open to all, but also open to innovation. 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. I do not speak of "free". I actually want to talk of "open standard" but I am not sure there is a consensus on the meaning? I do not really consider commercial money, but commercial dominance. Of Open Culture. This is in particular described in http://nicso.org/equilang.tm equal lingual opportunity. The draft contains NO restrictions against open-source or non-profit implementation (I would think they would be strongly encouraged). The problem is that the nature of the market makes that Draft favorable to market dominant. And the threat on open source is important. This is not the place to discuss this analysis. It was made by Gov officials and international analysts I trust. There is nothing in the ABNF that prevents open-source development based on the proposed BCP. The problem is not the ABNF, it is the pretension to exclusive. Because the ABNF does not address _all_ the situations. Status quo by nature favors commercial dominants. Status quo is opposed to innovation. There are no IP constraints on any of the technology used in its development. Can you warranty that? Unfortunately the experience does not say that 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. I have documented enough the dot-root experiment which is at the basis of our effort. The daily information we publish on the network. We are currently blocked by the lack of data (we wait for stability of ISO 639-3 and ISO 639-6 availability). The work engaged is of magnitude and is based upon underlying effort. We have a plan and try to stick to it at our expense. The cost the WG-ltru and the threat it represents on us is significant (hence my delegation as an interface). We try to be free to stay independent in advising Govs and international entities. The arguments that RFC 3066 is widely ignored Never said that !!! I say it is loosely enforced. And that the target of the Draft is to use it much more. 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. I am _defending_it_ if you really like it !!! I just want it _not_to_want_to_be_exclusive_ and to warn people about its dangers. You are throwing away the model: in wanting to oppose others, you will lead a generalised approach to develop which will a
Re: [Ltru] Re: Last Call: language root file size (long)
I wrote: > 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. Should have been: "variant" subtags and "grandfathered" tags There is no such thing in the draft as a grandfathered subtag. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Re: Last Call: language root file size (long)
JFC (Jefsey) Morfin 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 image
