Subject: [Ltru] Shelf life of data (was: Re: Question)

From: "Doug Ewell" <[email-masked]>
Date: Sat, 26 Mar 2005 09:22:49 -0800

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> Retro compatibility is offered for a long nowhere. Try to use your
> 1930 telephone set, I am not sure it will work. Try to publish an
> Internet 1990 terminology. Try to use the root servers file of 1995,
> it will may be still work partly. Try to use DOS on your PC, it works
> very well, but you are missing a lot of things.

People have been quoting RFC 822, which is 23 years old, on this list.
Even though it has been updated by RFC 2822, obviously many of the basic
philosophies and terminology still apply.

> Objection to a decade obsolecense cycle?

It's much too general to apply blindly.  Some standards and technologies
are obsolete within a year or two; others are good for decades.  ASCII
is 42 years old (or 38, depending on what you mean by "ASCII"), and yet
many people still consider it the lowest common denominator necessary to
ensure reliable communications.

There's nothing magic about 10 years.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 26 Mar 2005 22:11:12 +0100

>philosophies and terminology still apply.

I do not fully understand how the point applies here. What we decided in 
1984 and which still makes the today namespace was in line with fundamental 
principles (root name concept). It will certainly last for ever as intrisic 
to a name space.

>There's nothing magic about 10 years.

Nothing. In real life you need to take decisions. When you need something 
to be applied, you need a good mnemonic. It also turns out from experience 
that a decade seems to be the absolecense cycle of the technology itself.

Take care. Happy Easter.
jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 26 Mar 2005 15:18:47 -0800

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

>> People have been quoting RFC 822, which is 23 years old, on this
>> list.  Even though it has been updated by RFC 2822, obviously many of
>> the basic philosophies and terminology still apply.
>
> I do not fully understand how the point applies here. What we decided
> in 1984 and which still makes the today namespace was in line with
> fundamental principles (root name concept). It will certainly last for
> ever as intrisic to a name space.

Your point was that a good many things from the past no longer function,
or function only partly, in today's world.  My point was that some
things from the past still function just fine.  We are both right.

> Nothing. In real life you need to take decisions. When you need
> something to be applied, you need a good mnemonic. It also turns out
> from experience that a decade seems to be the absolecense cycle of the
> technology itself.

It depends on the technology.  Some technologies, like laser video
disks, take much less than a decade to become obsolescent.  Some last
much, much longer.  Ten years is not carved in stone.

-Doug Ewell
 Fullerton, California

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 26 Mar 2005 17:01:10 -0800

Mark brings up an interesting point that I hadn't examined carefully
before, and which is actually leading me to change my mind and start
supporting a "Date A."

First we need to separate the question of "what goal we want to
accomplish in allowing or disallowing certain codes" from the question
of "how do we achieve that goal."

I think most people would agree that we want to maintain compatibility
with all previous RFC 1766 and 3066 tags.  Specifically, there should be
no tag that was valid under the rules of RFC 1766 or 3066 that is no
longer valid under RFC 3066bis.  Then the question becomes, what *were*
the rules of RFC 1766 and 3066?

RFC 1766 says:

"All 2-letter tags are interpreted according to ISO standard 639, 'Code
for the representation of names of languages' [ISO 639]."

The reference in square brackets is to ISO 639:1988.  The text mentions
that a Registration Authority exists, and gives its address and
telephone number, but does not make any provision for adopting the RA's
changes.  It does list six codes that "have been added in 1989,"
including three that "replaced" other codes, but says nothing about
whether the "replaced" codes were still allowable in tags, or whether
new codes subsequently approved by the RA would also be allowable.

RFC 3066 corrected this omission as follows:

"All 2-letter subtags are interpreted according to assignments found in
ISO standard 639, 'Code for the representation of names of languages'
[ISO 639], or assignments subsequently made by the ISO 639 part 1
maintenance agency or governing standardization bodies."

Again the reference is to ISO 639:1988, but this time it is clearly
stated that added and changed codes can also be used in language tags.
Again, no mention is made of whether old codes were still allowable, but
it would be awkward to conclude that a code change should require all
existing data using the old code to be retagged.

The situation is the same for ISO 3166.  RFC 1766 cites the 1988 version
of ISO 3166, and only allows for codes in that version, whereas RFC 3066
expressly allows codes "subsequently assigned by the ISO 3166
maintenance agency or governing standardization bodies."

A strict interpretation of all this would be that the codes allowed by
RFC 1766 and 3066 are those listed in the 1988 versions of ISO 639 and
3166, plus the six codes listed in RFC 1766 as having been "added in
1989," PLUS all codes added to either standard since 2001, when RFC 3066
with its allowance for "assignments subsequently made" was published.

A more realistic interpretation, which probably captures the true
situation, would be that the set of allowable codes consists of all
codes in ISO 639:1988 and ISO 3166:1988, plus all codes assigned since
those standards were published -- 1988, not 1995 or 2001.  This covers
not only the six language codes explicitly listed in RFC 1766, but also
the assumption that was probably always made since the release of RFC
1766, and finally codified in RFC 3066: that updates were allowed.

What does this mean for the registry?  ISO 639:1988 was the original
version of that standard, so this "looser interpretation" doesn't remove
any language subtags.  ISO 3166:1988 was the third edition of that
standard (originally published in 1974).  Restricting the region subtags
to those published in the 1988 version or later would exclude the
following 15 code elements:

BQ  British Antarctic Territory
CT  Canton and Enderbury Islands
DY  Benin (Dahomey)
FQ  French Southern and Antarctic Territories
HV  Burkina Faso (Upper Volta)
JT  Johnston Island
MI  Midway Islands
NH  Vanuatu (New Hebrides)
NQ  Dronning Maud Land
PC  Pacific Islands Trust Territory
PU  U.S. Miscellaneous Pacific Islands
PZ  Panama Canal Zone
RH  Zimbabwe (Southern Rhodesia)
VD  North Vietnam
WK  Wake Island

but would NOT exclude the following 9 code elements, which were
withdrawn after 1988:

BU  Myanmar (Burma)
DD  East Germany
FX  Metropolitan France
NT  Neutral Zone
SU  Union of Soviet Socialist Republics
TP  Timor-Leste (East Timor, originally Portuguese Timor)
YD  People's Democratic Republic of Yemen
YU  Serbia and Montenegro (Yugoslavia)
ZR  Congo, The Democratic Republic of the (Zaire)

Does this make sense?  If the goal is to make sure all RFC 1766 and 3066
language tags are still valid, and if we can agree that codes withdrawn
before 1988 were never valid in tags, then we can disallow these codes
in RFC 3066bis as well.  We can "give back" the 15 codes to ISO 3166/MA,
so to speak, so that if they are reassigned it doesn't hurt us.

Note that we haven't done any one-by-one "cherry-picking" as to whether
a given code is useless or lame or anything.  For example, "ar-NT" is
still just as pointless a tag as ever, but we don't use that as a reason
to disallow it.

In John Cowan's terms, then, "Date A" would be 1988-01-01.  (Actually,
it doesn't matter what date in 1988 is chosen, since no codes were
withdrawn during that year.)  And "Date B" would be either 2005-01-01,
or the date of each new draft, or the date of final publication, or
whatever.  It won't matter if we can get the MAs to play nice and not
reassign any codes until then.

I propose this solution, and politely request WG feedback.

-Doug Ewell
 Fullerton, California

---

From: John Cowan <[email-masked]>
Date: Sat, 26 Mar 2005 21:37:46 -0500

> reassign any codes until then.

This version of my solution is also fine with me.

-- 
Business before pleasure, if not too bloomering long before.
        --Nicholas van Rijn
                John Cowan <[email-masked]>
                        http://www.ccil.org/~cowan  http://www.reutershealth.com

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 27 Mar 2005 04:56:42 +0200

On 01:18 27/03/2005, Doug Ewell said:
> > It also turns out from experience that a decade seems to be the 
> absolecense cycle of the
> > technology itself.
>
>It depends on the technology.

:-) we are IETF.
I meant international network technology. Since 1977: Tymnet, OSI, 
Internet, coming NGN.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Mar 2005 20:05:40 +0200

> There's nothing magic about 10 years.

For our purposes the last 10 years would allow us to get rid
of the A-list country codes (after 1988, before RfC 1766):

BU, DD, FX, NT, SU, TP, YD, YU, ZR.

If the next registry draft allows to use ISO 3166-3 as a source
for canonical values, we could fix DDDE and YDYE (no canonical
value for DD and YD at the moment).

We would still have the odd situation, that tags for DD and YD
are possible, but tags for the old DE and YE are impossible -
these country codes are now implicitly the new DE (incl. DD)
and the new YE (incl. YD).

To fix this oddity we could add a "union rule":

| If two or more regions form a union, and if that union
| inherits the country code of one of its former parts, then
| the former UN number of this region is added as deprecated
| subtag with a corresponding canonical value.

Example - I'm too lazy to check the UN numers and invent them
here, before the union of YD+YE and DD+DE resp.:

YD  101
YE  102
DD  201
DE  202

After the unions:

102     YE # deprecated 
YD  101 YE # deprecated (3166-3 YDYE) 
YE  100    # see also 102
202     DE # deprecated
DD  201 DE # deprecated (3166-3 DDDE)
DE  200    # see also 202

At the moment the consensus is apparently some "frozen 3166-1"
concept, and not my "whatever 3166-1 says is fine but unstable"
idea.  In that case we'd need better rules for "unions" (and
probably also for "splits") when the new region inherits an
old country code.  Otherwise we'd implicitly "lose" regions
as shown above.

You're all very sure that my proposal to use UN numbers for
stability isn't okay ?  All these weird cases of "unions",
"splits", "lost regions", etc. don't exist for UN numbers.

                          Bye, Frank

---

From: [email-masked]
Date: Sat, 26 Mar 2005 10:32:51 -0800 (PST)

> > 1930 telephone set, I am not sure it will work.

Bad example. I have in fact done exactly this, and 1930s era phones are fully
funcitonal today on a POTS line. (Of course they won't work on a digital
conection, but that's to be expected.) Rotary dial phones were introduced
around 1920, and even the phones without dials popular before that will let you
listen and talk. (Ringing is another, more complex story.)

This poster illustrates this aspect of telephone history rather nicely:

  http://www.sandman.com/images/telstory.jpg

> > Try to publish an

> philosophies and terminology still apply.

Exactly right. And more to the point, lots of other RFCs published at or around
the same time are nothing but historical artefacts. And at various points along
the way if you'd taken a survey you would have found a lot of people believed
RFC 822 would join them in short order, having been replaced by X.400.

> ensure reliable communications.

And furthermore, we aren't good at predicting what will survive and what will
be lost. Planned obsolescence is therefore a bad idea for standards, since
things often don't go according to plan.

> There's nothing magic about 10 years.

Absolutely.

				Ned

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 28 Mar 2005 13:26:33 +0200

This calls for a few comments to understand what we are discussing.

>   http://www.sandman.com/images/telstory.jpg

In a nutshell it does not work, but under constraints rebuilding/protecting 
the 1930 environment it still works. I hope you can listen and talk, any 
one having tapped a line knows that. You certainly know how to dial without 
a rotary too I presume. You just document that the system you have is 
obsolete, i.e. out of use, of old design.

>RFC 822 would join them in short order, having been replaced by X.400.

Many of us would have liked it to become osolete :-) and we will keep spam 
as long as it is not :-))))
I prefer STD 013 as an example.

>things often don't go according to plan.

In our case we do not predict. We consider two things:

- the cycles of code reasignment of the ISO standard we consider and their 
interference
- the user behaviors we want to foster.

I am afraid you confuse the obsolecence of the "things" and the decided 
duration of validity of the data. The obsolecense of the validity of an 
entry has nothing to do wit the standard, the process, the application. The 
shortest the obsolescnence the greater the accuracy. In DNS this cycle is 
named TTL and can be from 0 to anything. Usually is one day to one week. If 
you want to be accurate (Dynamic DNS you can put id down to the minute or 
less).

The difference between those two notions are very important to address the 
questions risen by the charter.
jfc