Julian Reschke wrote:
Paul Hoffman wrote:
...
It sure it. It just turns out to be a terrible format for extracting
text as anything other than lines, and even then doesn't work
reliably with commonly-used tools
...
It's also a terrible format for reading documentation in a Web Browser.
I believe the IETF and the W3C came up with a better format for that a
few years ago...
Yup.
And that really underscores the challenging of juggling competing goals:
Long-standing benefits of a readable/searchable text source, against the
considerable improvements in readability that can be achieved with more robust,
multi-media presentation capabilities.
The Braden/Klensin proposal is seeking a balance of goals. This is the
fundamental point about their proposal that we need to appreciate. And to the
extent that there is debate about their proposal, it needs to start by
reconciling goals. The rest is quibbling about details, albeit possibly
important ones.
Not surprisingly, I'd wish for different details, but want to re-emphasize that
we are now (merely) haggling price.
The benefit of the balance they struck is that it is pretty minimal, although
yes I did not some suggestions for simplification. Still, this defines an
important baseline reference.
The detriment is that I think its *benefits* are too minimal. It proposes an
enhancement that requires a number of procedural and technical changes. I
believe that significantly more benefit can be obtained for the same order of
change.
John C Klensin wrote:
That is it. No intention to solve all possible problems, just
what appears to us to be a large and growing subset in which
...
It is our belief that, modulo some tuning, this proposal is
likely to be able to get community consensus. Based on the
One thing that will help resolve things is to be very clear about what goals
need balancing. The Braden/Klensin proposal states some. I suspect there are
some others that are implicit or at least might need stronger emphasis.
My own suggestion for the list of goals expands upon the ones of the B/K
proposal:
1. There is a single, master file for document text.
2. Base text is able to be edited, viewed, compared and searched with
extremely minimal set of tools, such as a classic text editors, and the like.
3. The master file is subject to formatting constraints, to improve
readability when using simple display tools.
4. All formats use strictly open standards.
5. Any mapping from the master file to a presentation format must only
depend
upon well-tested, reliable tools that are available as open-source.
6. Multiple display forms must be supported, notably scroll-form for screen
display and paginated form for printing, as well as classic, basic IETF ASCII
paginated format.
7. Figures can be encoded in classic ASCII art and/or in a graphics format.
8. Enhanced display formats can support basic font changes, within
IETF-defined criteria, since this can enhance readability.
9. Naming conventions tightly link additional files that are used by the
master file.
10. Changes seek to have as much automation as possible for the technical
aspects of RFC development and production.
11. Format for the master file should facilitate later revision efforts.
John C Klensin wrote:
Actually, you don't care because there should be no requirement
that the image file come to the RFC Editor in PDF/A and the
...
What goes to the RFC Editor is
...
(ii) An image file in some format the RFC Editor is
willing to deal with. Certainly standard PDF would be
I think this promotes a singular mistake, namely potentially *additional* work
for the RFC Editor. Where possible, we should seek to move the technical
burden
to authors. Given the current state of editing and publishing technology, the
"where possible" is almost everywhere.
I'm told that xml2rfc produces output that is very, very close to what the RFC
Editor can publish directly... But it is still slightly shy of perfect.
I urge our finding how to close that gap. Perhaps there are tweaks to xml2rfc.
Perhaps there are tweaks to the RFC Editor's requirements. Whatever they
are,
my own perception of the different outputs that xml2rfc generates is that they
seem entirely satisfactory for IETF use.
John C Klensin wrote:
(1) xml2rfc may be widely used, but it is not a requirement or a
standard. It actually has no formal status in the IETF.
The B/K proposal calls for a change in formal status, for PDF. Why, then, is
xml2rfc out of bounds for consideration, particularly given how dominant its
use
has become?
And, by the way, we need to be careful to retain the ability to have simple,
ASCII-only RFCs.
(If we get the document naming conventions correct, I suspect we can even make
it possible to have xml2rfc *or* simple ASCII and still incorporate pointers to
real graphics. I think this would be compatible with the approach that Paul
Hoffman suggested.)
John C Klensin wrote:
We've stuck with ASCII in the last many years because, in
addition to being a very stable and widely-available format, it
is easily accessible to tools that are widely-available and very
simple. Diffs work. Grep works. Nearly mindless regular
expression searches work. Copying text out of one document,
modifying it, and pasting it onto another works, and works
reliably. That list, obviously, goes on. While there are
possible substitutes for each
of those, they are not generally available in free products
(unlike simple creation and rendering of PDF files).
xml2rfc tools are free and can be used online or the desktop. The source is
text-processable. All forms of output are processable with wide variety of free
and commercial tools.
While we have assumed that virtually all of the community
(Frank's remarks notwithstanding) can read, render, and, if
needed, print PDF files, more complex operations require tools
that are less readily available (or significantly expensive).
This statement does not seem to be correct, with respect to xml2rfc.
Anyhow...
By way of example, concerning the combination of ASCII and true image figures,
take a look at the 3 forms of output my own email-arch draft now generates,
notably in terms of figures. Take a look at the "unreleased" -11-14dc version:
<http://bbiw.net/recent.html#emailarch>
Through 4.5 years of development, I only used ASCII art. This was particularly
painful for the largest figure. For the final stages, I've *added" pretty
versions.
What is facinating is that the ascii art remains and when html is being
displayed, if it cannot find the graphics file, it shows the ascii art. Very
nice fallback safety mechanism.
So...
I've just submitted an independent revision to draft-rfc-image-files-00 which
expands upon it, to satisfy the goals listed above.
Besides being submitted as an I-D, the draft is available in the usual xml2rfc
alternate formates, and includes diff listings against
draft-rfc-image-files-00, at:
<http://bbiw.net/recent.html#rfcmedia>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf