On 2008-08-23 02:05 John C Klensin said the following in reply to Bill
Personal opinions only: I have not polled my esteemed co-author,
nor the contributors from the Editorial Board, and we may not
My hope is that we can discuss and figure out whether the
community likes and will accept the general idea. Your
"interesting way to go", even if not conclusive, seems to align
with that first step.
Beyond that, I'm delighted to quibble, or let others quibble,
about terminology in the text, naming conventions for files,
packaging of files, side-effects on organization of archives,
and probably a range of topics I haven't even thought of yet.
I believe the proposal in this document would be a step forward,
and I'm happy to start quibbling :-) as follows:
Tools-wise I believe this proposal proposes no great challenges.
There's however one point where a minor change could make a big
difference in ease of tools handling:
The proposal suggests that the pdf-format pages which contains
the figures be numbered with page numbers which follow the last
content bearing page of the base (ascii) document, with the
final boilerplate page(s) being numbered to follow the pdf pages.
This means that in order to provide links between text references
in derived formats, such as the htmlized RFC and drafts, a tool
would need to find and parse the figure index, and use that to
create a translation table from Figure number to Page number, in
order to be able to provide links from 'Figure N' references in
the text to the actual figure.
It would be easier to provide correct links if the analogy with
separately printed illustration plates in books (which were
commonly numbered 'Plate 1', 'Plate 2', etc.) were carried
further, and the PDF pages were numbered "Figure-1", "Figure-2",
etc., thus eliminating the indirection through page numbers.
(This would also obviate the need to update xml2rfc to make it
produce non-consecutive page numbers for the trailing boilerplate
Ietf mailing list