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

From: John C Klensin <[email-masked]>
Date: Thu, 15 Jun 2006 04:13:00 -0400

Two observations on this...

--On Wednesday, June 14, 2006 22:16 -0400 John L 
<[email-masked]> wrote:

>> The key question is whether there exists a format which is
>> likely to be sufficiently stable that we won't have to
>> revisit this decision in another 35 years. All the proposed
>> formats - including PDF, XML, etc. - are moving targets at
>> this time.
>
> That's why I suggested GIF.  Like ASCII, GIF has its
> shortcomings, but its definition hasn't changed in 16 years
> and I've never seen GIF software that doesn't interoperate.

But one of the important criteria for an acceptable alternate 
form, one which came up in the earlier discussion on this list, 
is that the format be searchable.   With PDF, page-image forms 
may not permit that but, as far as I know, searching inside GIFs 
is impossible except perhaps via fancy AI tools and heuristics.

More generally and to reinforce a point that I think Bob Braden 
made, I believe there was general consensus on this IETF list 
when the earlier discussion occurred that PDF, if it was to be 
used, be narrowly profiled so as to permit only those variations 
that appeared to be stable and meet various other criteria, 
notably ease of searching and extraction by text copying 
operations.  It seems to me that this draft, by omitting 
specifics about versions and features of PDF to be permitted 
and, if it isn't obvious, how the submission or editing process 
automatically verifies that those rules were followed, is not 
responsive to that consensus.  Arguably, on that basis, it 
should never have been Last Called.

      john

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

---

From: "John R Levine" <[email-masked]>
Date: 15 Jun 2006 09:39:08 -0400

> is that the format be searchable.

In case it wasn't clear, my quite informal suggestion was that one might
attach a few GIF illusttrations to an ASCII document, sort of like a paper
book that has a few color plates glued in the back.  I agree it would be
nuts to put text into GIF.

> should never have been Last Called.

Entirely agree.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Jun 2006 13:14:18 -0400

--On Thursday, June 15, 2006 09:39 -0400 John R Levine 
<[email-masked]> wrote:

>> form, one which came up in the earlier discussion on this
>> list, is that the format be searchable.
>
> In case it wasn't clear, my quite informal suggestion was that
> one might attach a few GIF illusttrations to an ASCII
> document, sort of like a paper book that has a few color
> plates glued in the back.  I agree it would be nuts to put
> text into GIF.

I continue to wonder whether what we should be doing here is not 
to invent a new normative document format, but to figure out how 
attach image-type figures to ASCII RFCs.   "plates glued in the 
back" is almost exactly the same as the analogy I have been 
thinking about.

So, while I don't think this particular experiment, as 
described, is plausible, there are two ideas I'd like to see 
proposed, perhaps experimentally, for the future:

(1) A PDF approach, but with PDF carefully researched and 
profiled (to include searchability and copy-and-paste extraction 
in addition to stability and very wide availability for readers 
and formatters) and a back-out plan should the community not be 
happy about the experimental results.

(2) Some specific and well-thought out proposals for a "figure 
supplement" to RFCs with multiple figures in a single file, good 
naming conventions, and so on.  A PDF file of figure-images 
might be the right thing to use; there might be better ones. 
But, as a strawman, we might have.

	    rfcNNNN.txt   (as now)  and
	    rfcNNNN-figs.pdf
	
	Where rfcNNNN.txt would contain things like
	
	    Figure 3. A Left Handed Foogle (please see
	supplement)
	with or without a rudimentary ASCII drawing.
	
	and rfcNNNN-figs.pdf would contain numbered and
	captioned figures, one per page.

There are probably better ways to do this -- I haven't thought 
through the details -- but I think that there is the core of an 
interesting idea in this.

It would _not_ be a small experiment: it implies changes to our 
archives, changes to indexing systems, more work for the RFC 
Editor in verifying that figure numbers, captions, and content 
were consistent between the ASCII RFC and the "plates", and so 
on.  But it would appear to me to point to a way forward that 
would not share most of the disadvantages of normative PDF files.

        john

p.s. When I said "should not have been last-called" in a prior 
note, I wasn't trying to suggest that the _idea_ was obviously 
dead or bad.  I was trying to suggest, instead, that, when an 
idea is discussed at length on the IETF list and a number of 
issues raised with it, it is normal for the IESG to insist that 
any version of the idea that is subsequently to be last-called 
address most of those issues in some substantive way.   "We 
don't see X as a problem" may be appropriate; pretending 
(deliberately or by accidental omission) that X was not raised 
or discussed as an issue is usually not.  The fraction of the 
Last Call discussion that essentially duplicates the discussions 
of some months ago is probably testimony to the wisdom of that 
principle.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 16 Jun 2006 12:34:48 -0500

I could not agree with John more on the desirablilty of a tighter definition 
of PDF and the reasonableness of "plates in the back".

And about the usefulness of including a list of places we've already been.

I note that we use issue trackers in a number of working groups, but this is 
an individual submission... until we come up with a better plan, keeping an 
issues list in the draft might at least cut down on the number of times we 
deja vu.

Spencer

> --On Thursday, June 15, 2006 09:39 -0400 John R Levine <[email-masked]> 
> wrote:
>
> I continue to wonder whether what we should be doing here is not to invent 
> a new normative document format, but to figure out how attach image-type 
> figures to ASCII RFCs.   "plates glued in the back" is almost exactly the 
> same as the analogy I have been thinking about.
>
> So, while I don't think this particular experiment, as described, is 
> plausible, there are two ideas I'd like to see proposed, perhaps 
> experimentally, for the future:
>
> (1) A PDF approach, but with PDF carefully researched and profiled (to 
> include searchability and copy-and-paste extraction in addition to 
> stability and very wide availability for readers and formatters) and a 
> back-out plan should the community not be happy about the experimental 
> results.
>
> (2) Some specific and well-thought out proposals for a "figure supplement" 
> to RFCs with multiple figures in a single file, good naming conventions, 
> and so on.  A PDF file of figure-images might be the right thing to use; 
> there might be better ones. But, as a strawman, we might have.
>
>     rfcNNNN.txt   (as now)  and
>     rfcNNNN-figs.pdf
>
> There are probably better ways to do this -- I haven't thought through the 
> details -- but I think that there is the core of an interesting idea in 
> this.
>
> It would _not_ be a small experiment: it implies changes to our archives, 
> changes to indexing systems, more work for the RFC Editor in verifying 
> that figure numbers, captions, and content were consistent between the 
> ASCII RFC and the "plates", and so on.  But it would appear to me to point 
> to a way forward that would not share most of the disadvantages of 
> normative PDF files.
>
>        john
>
> p.s. When I said "should not have been last-called" in a prior note, I 
> wasn't trying to suggest that the _idea_ was obviously dead or bad.  I was 
> trying to suggest, instead, that, when an idea is discussed at length on 
> the IETF list and a number of issues raised with it, it is normal for the 
> IESG to insist that any version of the idea that is subsequently to be 
> last-called address most of those issues in some substantive way.   "We 
> don't see X as a problem" may be appropriate; pretending (deliberately or 
> by accidental omission) that X was not raised or discussed as an issue is 
> usually not.  The fraction of the Last Call discussion that essentially 
> duplicates the discussions of some months ago is probably testimony to the 
> wisdom of that principle.
>
>
>

---

From: Carl Malamud <[email-masked]>
Date: Fri, 16 Jun 2006 12:34:10 -0700 (PDT)

> of PDF and the reasonableness of "plates in the back".

The problem with tightly defining which piece of PDF you will support is
that most clients don't give the user choice on what they do.  A user
gets a "export to PDF" button, but they don't get a "export to PDF/A and
make sure all fonts are self-contained and don't include embedded video."

Carl

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Jun 2006 16:34:04 -0400

--On Friday, June 16, 2006 12:34 -0700 Carl Malamud 
<[email-masked]> wrote:

>> I could not agree with John more on the desirablilty of a
>> tighter definition  of PDF and the reasonableness of "plates
>> in the back".
>
> The problem with tightly defining which piece of PDF you will
> support is that most clients don't give the user choice on
> what they do.  A user gets a "export to PDF" button, but they
> don't get a "export to PDF/A and make sure all fonts are
> self-contained and don't include embedded video."

I understand that.  But it leaves us in an odd state.  On the 
one hand, some of us have experience with PDF files created in 
some applications not opening in others and, in particular, not 
opening in the presumably-normative Adobe Reader.  Then we have 
RFC 3778 and PDF/A, which more or less specify profiles for PDF 
(although whether or not those profiles are appropriate for our 
purpose here is a separate question).

To the extent to which a user is not able to specify those, or 
other, profiles, or options that would cause them to be created, 
the argument that PDF is widely supported by multiple vendors 
breaks down in practice and, with it, the argument that PDF is 
really ready for prime time and/or applications that require 
stability over very long timelines.

      john

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 16 Jun 2006 16:28:46 -0500

John,

> back" is almost exactly the same as the analogy I have been 

This is a new output format, and previous suggestions for new
input/output formats have not reached any agreement whatever -- there is
every possible opinion expressed on what format to use or not to use,
and why.  IMO a big drawback of this approach is that figures (and
equations) don't appear with the text, which is not easy to use.  Also,
your suggestion for a "figure supplement" to RFCs (with multiple figures
in a single PDF? file) has the same drawback.

The advantage of using PDF is that we already use it, for both drafts
and RFCs, and have a lot of experience using it.  For most people it
seems to work just fine.  IMO PDF is our best shot in IETF at solving
the graphics and equations issues raised in the draft.

> happy about the experimental results.

Specifying profiles for PDF is fine, as long as there is agreement that
it's necessary.
 
> When I said "should not have been last-called" in a prior 

I think you're referring to the comment (from a couple of people) that
the authors "ignored" a "consensus" to specify PDF profiles in the
proposed experiment.  However, we did not "ignore" anything.  It was not
clear to me (or the other co-authors) prior to the -02 version that
there was any "consensus" RE specifying PDF profiles/formats/versions, a
couple of people as I recall commented on that perhaps, among dozens of
other suggestions.  Which suggestions are we supposed to treat as
consensus?

It isn't up to any one individual to declare one comment or another
comment as "consensus" and then charge the authors with ignoring the
supposed "consensus" after the fact.  If the authors agree to address a
particular comment, OK, but we didn't get that far in the discussion of
the -01 draft leading up to the -02 draft.  Also, no additional comments
were made during the 3-week comment period on the -02 draft before last
call was initiated; there was time to raise the comment again.  

In any case, it is OK to specify profiles/versions/features in the next
revision if there is agreement.  It is a last call comment that can be
incorporated in the -03 version.

Jerry

---

From: John L <[email-masked]>
Date: Fri, 16 Jun 2006 19:39:24 -0400 (EDT)

> make sure all fonts are self-contained and don't include embedded video."

There's no question that we have a significant tools issue if we use a 
format as complex as PDF.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Sandy Wills <[email-masked]>
Date: Fri, 16 Jun 2006 20:28:57 -0400

Carl Malamud wrote:
> The problem with tightly defining which piece of PDF you will support
> is that most clients don't give the user choice on what they do.  A
> user gets a "export to PDF" button, but they don't get a "export to
> PDF/A and make sure all fonts are self-contained and don't include
> embedded video."

   Is this an issue?  "Most clients" and "the user" doesn't 
realistically describe the entity which produces RFCs, do they?
   Whatever we decide that the RFC editor needs the ability to do, 
whether it be "export to PDF/A and make sure all fonts are 
self-contained and don't include embedded video" or "produce clay 
tablets in cunieform", then we need only ensure that the RFC editor has 
access to _a_ tool which can do what we decided.  Everyone else need 
merely _read_ what the RFC editor produced.  And, "Most clients" can 
probably do that.  Isn't that one of the primary responsibilities of 
this office, to ensure that, whatever format we decide upon, the RFCs 
all match the chosen format?

-- 
Unable to locate coffee.
Operator halted.

---

From: John Leslie <[email-masked]>
Date: Sat, 17 Jun 2006 08:33:57 -0400

Ash, Gerald R (Jerry), ALABS <[email-masked]> wrote:
> proposed experiment. 

   There's a bit of a "straw-man" here, in that I'm pretty sure that no
two commenters said exactly that; but no matter -- that's not the point
I mean to speak to.

> However, we did not "ignore" anything. 

   s/anything/any such thing/

> It was not clear to me (or the other co-authors) prior to the
> -02 version that there was any "consensus" RE specifying PDF
> profiles/formats/versions,

   Here's the point I wish to speak to.

   It is a perversion of the meaning of "consensus" to take the attitude
that nothing in a draft needs to be changed unless there is "consensus"
on the exact nature of the change. I'm seeing that usage among too many
IETF participants; and it is _very_ annoying!

   The proper use of "consensus" process is to go through the excruciating
pain to reach near-unanimity _once_ to produce a base document; thereafter
discussing _small_ changes and waiting for reasonable "consensus" before
applying small changes. Where there isn't "consensus" to make a change,
consensus theory holds that the group isn't yet ready for the change (and
needs time to learn to accept it).

   Consensus theory evolved in response to well-known failings of
democratic decision-making: in particular the tendency to random-walk as
there are small shifts around a nearly-even split.

   In my experience consensus theory works well for a very large set of
issues in group dynamics -- but not all situations. The difficulty lies
in determining whether one is faced with a situation in which consensus
theory _cannot_ work, or merely a situation in which too few folks
understand consensus theory.

   This determination becomes arbitrarily difficult as personal agendas
of people who _do_ understand consensus theory cause them to act as if
they don't. :^(

   I will not attempt to offer a solution here; but I would appreciate
it as a personal favor if folks would stop using the word "consensus"
to refer to things quite alien to consensus theory.

--
John Leslie <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Jun 2006 13:04:39 -0400

--On Friday, June 16, 2006 16:28 -0500 "Ash, Gerald R 
\\(Jerry\\), ALABS" <[email-masked]> wrote:

> John,
>
>> I continue to wonder whether what we should be doing here is
>> not  to invent a new normative document format, but to figure
>> out how  attach image-type figures to ASCII RFCs.   "plates
>> glued in the  back" is almost exactly the same as the analogy
>> I have been  thinking about.
>
> input/output formats have not reached any agreement whatever
> -- there is every possible opinion expressed on what format to
> use or not to use, and why.  IMO a big drawback of this
> approach is that figures (and equations) don't appear with the
> text, which is not easy to use.  Also, your suggestion for a
> "figure supplement" to RFCs (with multiple figures in a single
> PDF? file) has the same drawback.

Jerry,

It seemed to me to be a plausible middle ground.   I prefer 
books with the figures together with the text that refers to 
them, rather than one with plates bound in the middle or at the 
end, too, but I've figured out a way to live with the latter 
when necessary.  And I believe that an image-only file would not 
have the same requirements that make unrestricted PDF feel like 
a bad choice for me (see note one below).   It is an idea.  I 
haven't written it up in an I-D because I'm not convinced that 
it is a good idea (although I think it may be worth some 
investigation) and because I'm out of energy for this, have been 
able to create ASCII drawings when needed for the RFCs I write, 
and am busy with other things (see note two below).

What I think we do with ideas in the IETF is to think about them 
and maybe discuss them with others and then either write them up 
as I-Ds or let them drop.  If we get community input on those 
ideas, we try to understand them and respond to them... 
typically either by making changes or by explicitly discussing 
why the input is not applicable.  Were I to float that idea as a 
proposal that we actually do something, I would expect to be 
beaten up from both the group that considered the idea 
completely inadequate if we were to do anything (and therefore 
too much work) and from the side that didn't believe it was 
necessary.  Hmm, that has happened already, even without my 
making a specific proposal.

As the result of those beatings -- the IETF sometimes gets 
fairly rough in the pursuit of "rough consensus" -- I would have 
the choice, if I wanted to make a formal proposal, of taking 
either of two approaches: (i) to generate essentially the same 
idea, with no additional changes, qualification, or explanation 
as a formal proposal or (ii) to try to respond clearly to the 
ideas, comments, and suggestions that came out of the 
discussion.  If I did the first, I'd expect the same beatings to 
be administered again, possibly with a higher level of 
irritation by those who commented.   If I did the second, I 
wouldn't expect automatic acceptance but I'd at least hope for a 
different set of discussions and arguments.

Ultimately, the proposal would succeed iff I was able to 
convince the community that my draft addressed a problem that 
existed and was worth solving and that the draft contained a 
satisfactory solution to it.  I can't find that out for a 
particular proposal without posting it and risking a beating or, 
worse, dead silence.  And, especially in the last couple of 
years, I've written a lot of I-Ds proposing ideas that have 
never come to anything ... some after extensive and heated 
discussion and some just quietly sinking from sight.

I have no right to assume that, simply because I make a proposal 
that I think is reasonable, the community is obligated to accept 
it or convince me it is a bad idea.   The default answer to any 
proposal here must be "no" or we all spin into insanity... at 
least IMO.

Accounting for and responding to earlier comments is where you 
and your colleagues, IMO, partially but critically failed to do 
between your original drafts and this one.    You did part of it 
-- the proposal for normative MSWord is gone -- but, again IMO, 
not enough of it.  In particular, my belief is that you got a 
lot of input, from multiple people, that image-only PDF was not 
adequate for the IETF (see note one) and that enough problems 
had been encountered with more text-oriented forms with 
incompatibilities between versions that at least some profiling 
was going to be necessary.  Now I believe --personal opinion of 
someone who has some experience reading the community but who is 
certainly not infallible -- that there was actual consensus 
around the need to tightly specify and constrain PDF if we were 
to use PDF.   But John Leslie's recent note is absolutely right: 
getting into an argument about consensus at this stage just 
isn't the point.    If there had been only a few well-reasoned 
arguments about why unrestricted PDF was a bad idea, it would 
still be your obligation (or at least wise of you) to respond to 
them in your draft if you didn't want the same arguments and 
criticisms repeated, probably with more heat and intensity.

> The advantage of using PDF is that we already use it, for both
> drafts and RFCs, and have a lot of experience using it.  For
> most people it seems to work just fine.  IMO PDF is our best
> shot in IETF at solving the graphics and equations issues
> raised in the draft.

Good.  I actually agree, albeit very tentatively, that it is our 
best shot.  But I believe that saying "PDF" isn't adequate and 
that a lot of work has to be done and specified before we are 
able to use it as a normative or exclusive form for archival RFC 
documents.   I believe (others may not) that there are 
convincing arguments in the community that we don't need 
experiments to figure that out and, hence, if we do an 
experiment, we had better be sure we know how to back out 
without any long-term damage.   In some cases, we, as a 
community, probably know the answers and just need to get them 
written down in a coherent way.  In others we need to do some 
serious work.  The observations by Carl and others that, were we 
to specify a profile, we might not be able to find a 
sufficiently diverse collection of tools to support it are 
extremely relevant here.  Doing that exploration and documenting 
it is a serious piece of work that, IMO, needs to be done before 
a proposal is accepted because "are there enough tools on enough 
platforms" seems to be a question for which the community wants 
an answer.  Of course, that is just an impression: you could 
argue that, for an experiment, it is only necessary that those 
participating have adequate tools.  Whether that argument would 
be successful is an open question --see above about ideas -- but 
nothing prevents you from proposing it.

>> profiled (to include searchability and copy-and-paste
>> extraction  in addition to stability and very wide
>> availability for readers  and formatters) and a back-out plan
>> should the community not be  happy about the experimental
>> results.
>
> Specifying profiles for PDF is fine, as long as there is
> agreement that it's necessary.

Again, with apologies to John Leslie, I believe that a 
compelling case has been made (by more than "a couple of people" 
and based on specific information and experience, not just 
opinions or speculation) for the necessity of doing so.  If you 
believe otherwise, I think you probably need to explain why the 
people who have made that case are incorrect.  Of course, you 
may disagree with that too and try to convince the IESG that you 
have rough consensus without either a profile or an explanation.

>> note, I wasn't trying to suggest that the _idea_ was
>> obviously  dead or bad.  I was trying to suggest, instead,
>> that, when an  idea is discussed at length on the IETF list
>> and a number of  issues raised with it, it is normal for the
>> IESG to insist that  any version of the idea that is
>> subsequently to be last-called  address most of those issues
>> in some substantive way.   "We  don't see X as a problem" may
>> be appropriate; pretending  (deliberately or by accidental
>> omission) that X was not raised  or discussed as an issue is
>> usually not.  The fraction of the  Last Call discussion that
>> essentially duplicates the discussions  of some months ago is
>> probably testimony to the wisdom of that  principle.
>
> I think you're referring to the comment (from a couple of
> people) that the authors "ignored" a "consensus" to specify
> PDF profiles in the proposed experiment.  However, we did not
> "ignore" anything.  It was not clear to me (or the other
> co-authors) prior to the -02 version that there was any
> "consensus" RE specifying PDF profiles/formats/versions, a
> couple of people as I recall commented on that perhaps, among
> dozens of other suggestions.  Which suggestions are we
> supposed to treat as consensus?

See above and John Leslie's note.

> It isn't up to any one individual to declare one comment or
> another comment as "consensus" and then charge the authors
> with ignoring the supposed "consensus" after the fact.  If the
> authors agree to address a particular comment, OK, but we
> didn't get that far in the discussion of the -01 draft leading
> up to the -02 draft.  Also, no additional comments were made
> during the 3-week comment period on the -02 draft before last

Insisting that every comment be repeated every time you (or 
someone else) posts a new draft is a path to either madness or 
denial of service attacks on the IETF community.  I am certain 
you didn't intend either, but I believe it is plausible for 
people to make comments, see a new draft that does not appear to 
address them, and then not comment further until a Last Call is 
issued.  That is where, despite my earlier comment, I believe 
Bill did the right thing in sponsoring this... the Last Call 
gives us a more or less definitive opportunity to get all of the 
issues out again and move toward a decision, rather than having 
the proposal drag out.

> In any case, it is OK to specify profiles/versions/features in
> the next revision if there is agreement.  It is a last call
> comment that can be incorporated in the -03 version.

Given the issue of tools that Carl raised and the fact that no 
one really seems to know how to profile PDF that way, I think 
that task may be larger than you believe.   But I am glad you 
are willing to embark on it if the community, somehow, convinces 
you that it is necessary.  And that leads me to...

Note 1:  I believe that constraints are imposed on _any_ 
normative publication format for the IETF by the way we use 
these documents.  In particular, I believe that for files 
containing the text of the specifications, searchability and 
extractability are absolutely critical.   One thing almost all 
of those of us who have used PDF know is that some files have 
those properties while others, often referred to as PDF image 
files, do not.    As soon as one gets to "need to be able to 
search", then it is necessary to profile PDF so that the right 
sorts of files appear.  And, as I think Bob Braden pointed out, 
one also has to have the tools in place to verify that.

It is reasonable for you to disagree with the main premise of 
the above paragraph, i.e., you may believe that we can dispense 
with searching and extraction.   If so, I would encourage you to 
say that, since it would make the PDF profiling problem much 
easier.  My personal guess is that you would find it quite hard 
to sell to the IETF community, but that is just a guess.

I note in that regard that, as we talk about experience with PDF 
in, e.g., ISO and ITU, we may not have as much relevant 
experience as we think we do.  As far as I can tell, both of 
those organizations consider the normative copy to be the paper 
and PDF, Word, etc., are precisely accurate versions to the 
extent to which they can be used to reproduce the normative 
paper.  Given history, that is a plausible position for them. 
But it implies that they don't have the searchability and 
extractability criteria I claim the IETF has, that permanent 
usability of the PDF files is of less importance to them than it 
might be to IETF (where the normative versions are the online 
ones) because they can always re-scan or regenerate documents if 
the need arises, and so on.

Note 2: Unlike some others on the IETF list, I recognize the 
importance of having illustrations in better-than-ASCII forms. 
We may disagree on how often it is important, or even on whether 
"important" should be a criterion or the criterion should be 
closer to "convenience".  I am nonetheless very sympathetic to 
the arguments that fancy illustrations often hide fuzzy thinking 
while the discipline of producing ASCII line art tends to 
clarify thinking and encourage simplicity in design.  Perhaps as 
a result of those possible disagreement, we might disagree on 
the relevance of ASCII versions of text and ASCII approximations 
to the more advanced, image-type, illustrations.  But we at 
least share the belief that there is a problem in this area that 
should be solved.  I am not positive that even that position has 
IETF community consensus.

regards,
     john

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 19 Jun 2006 15:51:44 -0500

John,

> documents.   
...
> to sell to the IETF community, but that is just a guess.

Of course I believe that searching and extraction from PDF is highly
desirable.  However I think that is probably not easy, and it's likely
that most people can't generate such searchable/extractable PDF files.
I also doubt that searchable/extractable PDF is the secret sauce that
will suddenly lead to agreement on this list.  Besides the beatings
administered RE the proposed experiment, we've seen the usual myriad
proposals all over again.  Based on these discussions, it's hard to see
how any way forward other than "do nothing" will fly.  Hopefully the
IESG, in spite of the discussions, will propose a viable way forward.

> IETF community consensus.

It's good that a key person such as yourself sees a problem that needs
solving.  Hopefully we'll find a way forward to solve the problem.

Thanks,
Regards,
Jerry