- From: Ned Freed <NED@innosoft.com>
- Date: Fri, 03 Nov 1995 09:36:58 -0800 (PST)
- To: Glenn Adams <glenn@stonehand.com>
- Cc: Harald.T.Alvestrand@uninett.no, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I apologize for continuing this discussion on the HTTP list. It really needs to move to the MAILEXT list ASAP. > I don't say that these argue against SIL codes, just that we have > to know what we are doing, and make sure we change the standard > in the right place. > Well, I don't know how pertinent it is to know about agendas here. We > could certainly question ISO in this regard also. It seems to me that > SIL's agenda here is quite irrelevant and that it is the end product of > their agenda that is useful. Namely, the language list and identifiers > list itself. If we should make any judgements, it should be along the > lines of comprehensiveness, which nobody can fault SIL for. I think you're missing the point Harald is trying to make here. The question isn't one of whether or not the codes are technically accurate, fairly assigned, or anything like that. The question is one of how stable the list is and what methods are used to update it. And this agenda *is* pertinent. In fact its absolutely crucial. You've provided the list in the form of a URL that appears to be attached to your site. Suppose we issue a document tomorrow containing the URL and you go out of business the day after that? The URL is no longer valid and the list can no longer be obtained. I suppose someone could call SIL and find a new location, assuming one exists, but that's really not acceptable. Suppose there's an academic revolt amongst the linguists at SIL and the list is radically revised. (You know as well as I do that such things do happen in academia from time to time.) The document is then updated with the new list and many old codes either vanish or are assigned to different things. Chaos insues. In order to use the list as a standard we need some assurance that these sorts of things will not happen. We normally get that assurance by citing specific, published entities. You may not like the ISO (I have a number of problems with them myself), but their process insures that a citation to a given document will always remain valid. Similarly, publication as an RFC provides a stable reference and also insures that updates will be made according to IETF guidelines. And these are not the only ways such assurances can be provided -- they simply examples of how it has been done in the past. The simplest thing to do would be to publish the current list as an RFC. Updates from the SIL would be possible and probably encouraged, but would be subject to some review by the IETF to insure compatibility is maintained. (I see absolutely no point in reviewing things as to technical linguistic accuracy in the IETF. The IETF lacks the expertise to make such judgements. On the other hand, the IETF does have the competence to assess compatibility issues according to the installed base, which is something the SIL does not have.) Just because its the simplest thing to do doesn't make it the best thing, however. Other approaches are possible. This list may well have appeared in a book or journal somewhere. If so, that could always be cited, and the citation could be updated by updating RFC1766 as necessary. > I'd like to improve 1766 to make it more comprehensive. You couldn't > help it that 639 is so limited. So I'm really not faulting 1766. It > seems it is important to recognize its limitations based on 639's limits > and move on from there. Given that the SIL list is available and a new > list from ISO is not forthcoming (its been stuck as a CD for over 5 > years now with little activity), I think that we should move ahead and > use the SIL list. > If would be pleased to assist in improving 1766 so it can be a single, > comprehensive language tag standard. Something I also want. Good. Then let's get going on it in the MAILEXT WG. Ned
Received on Friday, 3 November 1995 09:58:06 UTC