--On Friday, June 16, 2006 16:28 -0500 "Ash, Gerald R
\\(Jerry\\), ALABS" <gash@xxxxxxx> 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.
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.
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.
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.
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.
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.
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
call was initiated; there was time to raise the comment again.
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf