Re: Language tags (Re: Statistics on reusing request)

> > If there's even the slightest chance that multiple three letter code schemes
> > will exist in the future then the S-nnn approach seems like the way to go to
> > me.

> The I-S-nnn approach is fully consistent with the current RFC
> 1766. Is a revision of the RFC justified, only to save 2 bytes?

It isn't clear to me that this is actually allowed under the rules RFC1766 sets
up for IANA registrations. There is nothing in there that seems to allow for
registration of an entire block to an agency outside of IANA. And even if there
were, the registration would still have to go through the registration process,
at which time exactly the same set of issues are going to have to be evaluated
and discussed. You gain nothing here except the time it takes to revise an RFC.

And what's more, you lose a lot more than two bytes. You lose completeness
of specification. A registration of this sort doesn't have to appear in an
RFC, so when someone wonders what I-S-drofnats or whatever is they will have
to:

(1) Dig up the current RFC. Find the pointer in it to the current registration
    policy.
(2) Dig up the registration policy. Find the pointer in it to the registered
    names table.
(3) Look through the table and find the pointer to the allocated subspace.
(4) Find the entry in the allocated subspace.

This seems like a lot more work than it should be. Why not simply have an RFC
that contains a pointer to the definitive table? Its not like all the
indirection buys you anything.

> > In summary, the only thing here that "sounds empty" to me is the notion that
> > its acceptable to have two different sets of language tags in different IETF
> > work items and that its acceptable avoid revising documents that need revision.
> > Glenn may have an excellent case for putting the SIL codes in RFC1766. He may
> > even have a case for putting the SIL codes in without an "S-" introducer and
> > putting the introducer on the son-of-639 codes should they ever appear. If so,
> > he needs to bring this up with the WG that produced the content-language
> > !? specification -- the MAILEXT WG, I believe.

> Does the MAILEXT WG still exist? The latest minutes seems to be
> mailext-minutes-95apr.txt, which says:

> : The working group should conclude its work by the Stockholm IETF. (Note:
> : the Area Directors would like to see the group conclude its work prior
> : to the IETF.)

Working groups exist by definition until the standards-track documents they are
working on reach the status of Standard or are removed from the standards
track. Groups "conclude their work" all the time, only to be revived to handle
the transition from proposed to draft or draft to standard.

Its also possible for documents to move along without WG reactivation. However,
in the case of a poprosal to make a substantive change to a specification (and
I don't see how you can view this in any other way), it seems inevitable that
the group will have to reactivate to consider it.

> How can one in general find out which IETF WGs are not yet
> disbanded? Is there any always up-to-date database covering WGs?
> Is dissolution of WGs always announced on the ietf-announce
> list, with some unique substring in the Subject header?

As far as I know the concept of "disbanding" a group doesn't exist. The mailing
list always continues to operate. Most groups eventually reach a state of
permanent dormancy that they never escape from, and are eventually  rendered
completely irrelevant by other work items that replace the specifications they
originally produced.

				ned

Received on Friday, 3 November 1995 17:43:55 UTC