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

From: "Gray, Eric" <[email-masked]>
Date: Thu, 5 Jan 2006 12:46:06 -0500

John,

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

--
Eric 

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of John C Klensin
--> Sent: Thursday, January 05, 2006 11:28 AM
--> To: Ash, Gerald R \(Jerry\); Yaakov Stein; [email-masked]
--> Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
--> 
--> 
--> 
--> --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
--> \\(Jerry\\)" <[email-masked]> 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
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jan 2006 13:58:47 -0500

> 	I believe - for the record - that Post-Script is also

It is indeed.  And it, as well as PDF, are allowed in RFCs (see
earlier note).

As others have noted, an ASCII form is still required.  I
consider that a feature and, for various worst cases,
futureproofing, but some others do not.

And, as yet others have noted, it would be wise for us to get
very specific about versioning and permitted feature-sets for
PDF.  It is arguably even more important to get specific about
versions and feature sets for PS although my own personal
opinion is that, given PDF, Postscript has about outlived its
usefulness as a separate posting format.  YMMD, of course, and
this thread on the IETF list is probably not the optimal way to
address that question in any event.

    john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 05 Jan 2006 16:44:12 -0500

>address that question in any event.
Producing good, portable PDF isn't obvious.  I just added the following 
text to a Call for Papers of a conference I'm chairing, based on many 
sad experiences trying to read random PDF files submitted by others:

	PDF users should use "Type 1" fonts instead of "Type 3", and 
	should "Embed" and "Subset" all fonts.  You can find 
	instructions on how to do this at 
	https://www.fastlane.nsf.gov/documents/pdf_create/pdfcreate_01.jsp
	and http://ismir2005.ismir.net/pdf.html

Among the problems I've encountered have been version skew, missing 
fonts (especially Asian language fonts that are frequently not 
installed elsewhere), fuzzy text from LaTeX users who are generating 
bitmap fonts, ligatures getting changed into weird characters, and more.

When I sent the PDF for the second edition of my book to the publisher, 
I had to use these options to dvips:

	-P pdf -G0 

and

	-dMaxSubsetPct=100 -dCompatibilityLevel=1.3 -dSubsetFonts=true -dEmbedAllFonts=true

for ps2pdf.  (I've left out the resolution.)  I should note that it 
didn't work, either -- but if I sent them the PS, they could convert it 
to PDF.  We never did figure out that problem....

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 06 Jan 2006 12:48:58 +0900

Steven M. Bellovin wrote:

> Producing good, portable PDF isn't obvious.

My recent experience is that I got a paper in PDF, though
plain text was more than enough for the paper, and
it included an e-mail address to which I send a mail. I used
Adobe original PDF reader (version 7.0) and, to make sure that I
won't wrongly type or copy the address, used reader's function
to automatically detect e-mail addresses in PDF files (PDF may
contain hyperlinks and recent PDF reader of Adobe optionally
detect additional hyperlinks in text automatically. Both types
of links are not distinguishable). Later, I have noticed that the
mail failed, because the PDF reader has a bug that the auto
detection does not work for e-mail addresses containing "-".

IMHO, the person who choosed the PDF format should be
responsible for the failure.

I hope IETF won't make similar mistakes.

						Masataka Ohta