[rfc-i] Comment on: draft-crocker-rfc-media-00.txt
dhc2 at dcrocker.net
Sat Sep 27 16:16:49 PDT 2008
Bob Braden wrote:
> Errr... I don't believe in the implication <existing code> => <user
Bob, your formulaic notation, here, is sufficiently cryptic that I am pretty
sure I don't understand it. While I'm going to make a guess, I'll still ask you
to clarify more thoroughly, even if I guess correctly.
One question is what you mean by "user interface"? Are you calling the author's
method of specifying figures a "user interface"?
As for the larger point you appear to be making, it seems to be that we
shouldn't make new standards based on existing practice. That, at least, is how
I am reading your formula. But I can't bring myself to believe that that is
what you really mean, given that the IETF is predicated on having work be based
on running code. I seem to recall some quote or other idealizing that... practice.
> Surely, the implication goes the other way: <user interface> => <old/new
> code>. If we believe that a different convention would be better for users, I
> am sure the XML2RFC folks would find a way to handle it. They have been
> reasonably responsive in the past.
And with this extra paragraph, the best I can derive is that running code should
only be used if we think its quality is sufficient. It shouldn't lock us in, if
we have a strong basis for believing that something different and new is
sufficiently better. And, not surprisingly, I concur with that view
(independent of whether it's what you intended...)
In case it *is* what you meant: I cited xml2rfc because it has demonstrated a
particularly strong success. Enough to make a prima facie case in its favor,
IMO. Enough to suggest that your alternative proposal ought to argue for why it
is better. I noted that yours forces all diagrams to be separate from the text
that cites them; I view that as a negative. xml2rfc places them inline. I view
that as a positive.
>> (I should comment that xml2rfc produces html with the spiffy characteristic
>> of reverting to the provided ascii art, if the external file is not
> This may be a spiffy feature during I-D development, but it is definitely not
> spiffy for published RFCs. You are building in a potential error, without
> telling the user.
Huh? What error? With xml2rfc, all display versions (txt, html, pdf) derive
from exactly the same text. Any errors are shared. So I don't know what
potential error you are referring to.
>> Further, the convention of having one figure per file, rather than multiple
>> per file, shows up regularly, such as the output of html by MS Office and
>> (if I'm interpreting the file properly, OpenOffice) as well as being what
>> html does.
> Large numbers of small files would be a nightmare. Surely you are not going
> to tell me that it must be right because Microsoft does it. When you
> purchase a book, you don't expect to be handed a bound copy of text and a
> pile of separate one-page figures. Do you?
Bob, I cited multiple examples of this approach, with MS as only one. If you
are going to reject a point, please do it without distorting the point and
without artificially constraining it. Note, for example, that I cited other
well-established methods of aggregating files.
>> Hence, what your proposal does is to seek to invent yet-another
>> multiplexing technique. In this case, it is one which forces figures to be
>> separate from the text that refers to them, rather than permitting in-line
> Sorry, I don't follow that.
You specify one file for all figures. (It occurs to me you also do not specify
how to deal with a potential scaling problem, if the aggregate of the figures
gets quite large...)
The only way to correlate a figure reference with a figure is visually by the
textual label encoded inside the image PDF file. Within the framework of your
scheme, that's reasonable, but it is inventing mechanism for defining that
My proposal uses existing practice which is more flexible, since it can use
other image encoding schemes, as well as being automated.
>> In summary, the enhancements that my draft proposes to yours are:
>> 1. Adding the option of having the master file be in xml2rfc which then
>> automatically produces alternative formats, such as txt, html and pdf.
> I believe it is a well-settled question that xml2rfc is a great boost to
> those who choose to use it, but in no way is it required.
The proposal explicitly states that the use of xml2rfc is *optional*, Bob.
Hence, it would only be "required" within the context of this new specification.
Your proposal creates one new set of requirements. Mine a different set. Are
you suggesting that because xml2rfc hasn't been formally specified by the IETF
previously, it can't be now?
>> 2. Specifying external figures, etc., as one-per-file
> I missed that you REQUIRE figures to be one-per-file. Much worse,I think.
More information about the rfc-interest