RE: Baby Steps (was RE: Alternative formats for IDs)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John,

	I believe - for the record - that Post-Script is also
allowed.

--
Eric 

--> -----Original Message-----
--> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] 
--> On Behalf Of John C Klensin
--> Sent: Thursday, January 05, 2006 11:28 AM
--> To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf@xxxxxxxx
--> Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
--> 
--> 
--> 
--> --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
--> \\(Jerry\\)" <gash@xxxxxxx> wrote:
--> 
--> > Happy New Year to all!
--> > 
--> > Many thanks to Yaakov for his excellent handling of the list
--> > discussion.  I'm not very surprised with the way it has gone.
--> > Déjà vu all over again :-)
--> > 
--> > The challenge is to focus the discussion to try to reach
--> > consensus on moving forward with a process change, i.e., we
--> > need to take baby steps to make progress.
--> > 
--> > I'd suggest we try to reach consensus first on the following:
--> > Alternative format(s) for IDs, in addition to ASCII text,
--> > should be allowed.  
--> > 
--> > One requirement/motivation for this change (as set forth in
--> > the ID) is to be able to include drawings and diagrams with
--> > something much more flexible than ASCII art.
--> > 
--> > Based on the prior discussion of 'ASCII art', and the current
--> > discussion, I see few people arguing that ASCII text is all we
--> > need and that no other formats should ever be allowed.
--> 
--> Even those of us who are strongly supportive of ASCII as our
--> primary base format and those who believe that the effort needed
--> to simplify illustrations and diagrams sufficiently that they
--> can be accurately represented in ASCII artwork is helpful in
--> forcing clarity are reluctant to say "never".
--> 
--> > Let's set aside for now which format(s), and take that as a
--> > later step if we can take this first step.
--> 
--> Jerry, one of the nice things about baby steps is that you
--> sometimes discover that the baby learned to take the steps
--> without any instruction.
--> 
--> Unless the IESG has changed the rules while I was not looking,
--> it has been permitted to post I-Ds in PDF in addition to ASCII
--> for some years. I find it interesting that it has not been taken
--> advantage of more often (and, for the record, I'm one of those
--> who has taken advantage of it).  When it has been done for
--> artwork purposes, the artwork in the ASCII version has sometimes
--> been pretty rudimentary.   In practice, whether it is "good
--> enough" has been made on a case by case basis by WG Chairs and
--> WGs or, for non-WG documents, by whether or not the relevant
--> people are willing to read and consider those documents.
--> Similarly, when PDF has been posted in order to exhibit
--> non-ASCII characters, it has proven helpful to have Unicode
--> character offsets (i.e., U+nnnn representations)  in both the
--> ASCII and PDF forms to ensure complete precision even though the
--> character-glyphs themselves appear only in the PDF form.  
--> 
--> So, consider the first baby step to have been taken: nothing
--> prevents you from posting an I-D in both ASCII and PDF today,
--> and the relevant sub-community will sort out, on a case by case
--> basis, whether the ASCII is good enough.   If you do more of it,
--> perhaps we can move some of the interoperability problems into
--> the realm of actual IETF experience and out of the realm of
--> extrapolation from other situations mixed with pure speculation.
--> 
--> Free advice: if and when you want to move beyond that point,
--> drop (or isolate into separate documents):
--> 
--> 	(1) Recommendations for IETF process change or specific
--> 	ways to determine consensus.  They should be separate so
--> 	they can be considered separately, using an appropriate
--> 	process.
--> 
--> 	(2) Distinguish clearly between what is required or
--> 	tolerable for I-Ds and what is required or tolerable for
--> 	RFCs.  RFCs, in general, put a less strong requirement
--> 	on easy extraction and modification of text than I-Ds.
--> 	And, since I-Ds in theory expire after six months, you
--> 	might be able to convince the community that the "be
--> 	sure it can be read twenty years later" requirement for
--> 	archival documents should not be taken as seriously for
--> 	I-Ds.
--> 	
--> 	(3) Recommendations to permit any format that is (i)
--> 	proprietary, or (ii) dependent on particular software
--> 	for processing where that software carries either high
--> 	costs, onerous licensing requirements,  or licensing
--> 	requirement that attempt to prohibit the development of
--> 	independent tools to work with the format, or (iii)
--> 	significantly operating-system dependent, or (iv)
--> 	significantly version-dependent in the sense that the
--> 	documents are not forward and backward compatible.
--> 
--> I would suggest to you that the fact that Word hits a jackpot by
--> satisfying all of the negative criteria in that third suggestion
--> is the reason why it has been regularly rejected for IETF
--> posting and working use in the past and is almost certain to be
--> rejected in the future.  If you want to consider that déjà vu
--> (or deja vu, for ASCII-readers), it certainly is in the sense
--> that we have been here before... but that rather misses the
--> point: it has been rejected in the past for substantial and
--> substantive reasons and the déjà vu situation, for me at
--> least, is that someone decides to bring it up again every few
--> years as if it had never been considered in the past.
--> 
--> regards,
-->     john
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@xxxxxxxx
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]