Subject: RE: [newtrk] List of Old Standards to be retired

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 17 Dec 2004 05:36:18 -0800

> [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> 
> > A new implementation for tn5250 is about as likely as a new 
> > implementation for NTP.
> 
> Well, I wouldn't be too sure. There are thousands of heritage 
> mainframe systems in the world, and a common tactic is to 
> give them a nice Web front end by screen-scraping the 3270 or 
> 5250 presentation and reformatting it for HTML presentation. 
> I can assure you there are certainly *recent* tn3270 and 
> tn5250 implementations as a result.

And people will no doubt make good money doing so. But that does not mean
that the entire enterprise from start to finish is not obsolete.

Further maintenance of such a specification is clearly impossible for
exactly the reason you give.  

	Phill
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Dec 2004 23:57:24 -0500

> that the entire enterprise from start to finish is not obsolete.

Obsolescence is relative.  Ancient technology can be remarkably useful, 
even if it's not as broadly applicable as it once was.

you might think that using open fire as a heat source is obsolete, but 
don't let that stop you from building a fire if you find yourself 
stranded in some remote place in the winter.

labeling a specification "Historic" shouldn't be a judgment about the 
technology, so much as a judgment about the utility of the 
specification.  i.e. is it still current, in the sense that it still 
describes the way the protocol should be implemented?  is it still 
useful to somebody who wants his implementation to interoperate (with 
peer implementations, and/or with the rest of the net)?

if the applicability of a specification changes, we need to write a new 
applicability statement.

to continue the fire analogy - let's say we had a spec that described 
how to build a fire safely -

if we at some point realized that our spec was no longer useful 
(perhaps because there were better instructions elsewhere), or that it 
was causing harm  (perhaps we failed to point out some necessary 
precautions that should be taken in building a fire) then we should 
reclassify the old fire-building specification as historic, and 
consider whether to issue a revised version or to refer readers to 
someone else's specification.

OTOH, if conditions changed so that fire was less widely applicable 
than before, but the specification was still reflecting the best known 
way to build a fire, we should write a new applicability statement for 
the fire-building specification, but not change the status of the 
specification itself.

the fire specification does not become obsolete just because someone 
invents electric heat.

Keith

.