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))

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

 





--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

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