Subject: RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

From: [email-masked] (Noel Chiappa)
Date: Fri, 16 Jun 2006 17:51:00 -0400 (EDT)

> From: "Hallam-Baker, Phillip" <[email-masked]>

    > Why go to all that trouble to create infrastructure to support an
    > obsolete document format when we can get all the infrastructure
    > required to support a modern, open format

Because those of us who've been around for a while have been repeatedly
screwed when something that was, at one time, the latest and greatest
"modern, open format" turns out, N years later, to no longer be supported.

	Noel

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 18 Jun 2006 09:22:14 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 

> There is a slight difference here: the earth hasn't seen any 
> successful demolishion attempts in the last 4.5 billion 
> years, while nearly any word processing document format from 
> the 1990s can't be read properly. In many cases the text 
> itself can be retrieved but there is almost always loss of 
> some or even all formatting. I gather that the current 
> version of Word can't read documents made by all previous 
> versions of itself successfully.

Name one format that was intended for use as an archival document format that is unreadable.

> I'm convinced that the success of the TCP/IP and web families 
> of standards has a great deal to do with the fact that the 
> standards documents involved are freely and easily available.

The Web standards were always on the Web in HTML.

> > The output of the IETF is simply not that critical for this 
> level of 
> > concern to be warranted. RFCs are exactly that, requests 
> for comment.
> 
> Go ask the people at the company you work for how important 
> they think their GTLD servers are, and how critical RFCs 791, 
> 768 and 1035 (to name a few old ones) are for their continued 
> operation.

Another bad example. The company standard for internal documents is Microsoft Word and Powerpoint.

I was under the impression that the divergence between the DNS standards and reality was sufficiently great that any documentation has to be the starting point for regression testing and QA rather than gospel. Certainly this is the case in the PKI world.

> > The real standards are and will always be set by running code.
> 
> This is so absurd that I don't even know what to say.
> 
> > Without continued maintenance the value of standards is 
> quickly lost 
> > in any case. RFC 822 has long since ceased to be the Internet email 
> > standard, it is of historic interest only. The same is 
> close to being 
> > the case for RFC 2822 as well.
> 
> That's nice. But I doubt you're going to be able to read that 
> email message exchanged through the latest version of the 
> SMTP protocol without some support for RFC 894 along the way.
> 
> > The underlying fallacy here is that the documents are holy 
> scriptures, 
> > they are not, they are merely an engineering tool to effect an 
> > engineering outcome.
> 
> > Talk about what may happen in fifty or a hundred years time 
> is simply 
> > an ego trip. Its like those folk who in the dotcom boom took out 
> > million dollar key man insurance. It had nothing to do with 
> the damage 
> > that might be done to the company if they died unexpectedly 
> it was a 
> > pure ego trip from start to finish.
> 
> It's the other way around. Time and time again, when an 
> engineer thought "well, by that time surely the system will 
> be replaced" this turned out to be a mistake. Is Y2K really 
> that long ago that we don't remember that lesson?
> 
> By the way: I happened to see a documentary on sky scrapers 
> on the BBC the other night. I was surprised to see that the 
> Woolworth building in New York (built in 1913) still has the 
> original elevator machinary in operation. It would suck to 
> have to replace a bunch of elevators because you don't have 
> the documentation to prove that they're still up to code...
> 
>