ietf
[Top] [All Lists]

Re: [Ltru] Re: Last Call: language root file size (long)

2005-08-28 21:15:33
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf