Subject: draft-rfc-image-files-00.txt

From: Bill McQuillan <[email-masked]>
Date: Fri, 22 Aug 2008 16:12:11 -0700

On first reading this seems to be an interesting way to go.

However, is it necessary to call a file full of "figures" an "image" file?
Couldn't we just pick one word throughout? I vote for "figures" since it
seems to match more to the book publishing metaphore. Thus:

draft-...-vv.figs.pdf
RFCn/Figures
and some other text changes.

I also hope that some guidelines for standard ways to reference a
particular figure from the ASCII text will be developed.

-- 
Bill McQuillan <[email-masked]>

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Fri, 22 Aug 2008 20:05:41 -0400

--On Friday, 22 August, 2008 16:12 -0700 Bill McQuillan
<[email-masked]> wrote:

> However, is it necessary to call a file full of "figures" an
> "image" file? Couldn't we just pick one word throughout? I
> vote for "figures" since it seems to match more to the book
> publishing metaphore. Thus:
> 
> draft-...-vv.figs.pdf
> RFCn/Figures
> I also hope that some guidelines for standard ways to
> reference a particular figure from the ASCII text will be
> developed.

Bill,

Personal opinions only: I have not polled my esteemed co-author,
nor the contributors from the Editorial Board, and we may not
agree.

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.
As far as I'm concerned, those details are specified in this
draft in order to have something specified and to give a clear
indication about what needs to be specified.  Not doing so
risked having a draft that would have been sufficiently vague
that we would have risked a debate about what people thought it
might say, and those debates are fairly useless.   There are
some things that might look like details but that are actually
rather carefully chosen after exploration of alternatives but
these aren't them.  Given that, I believe that one set of
details of the sort you describe can be easily substituted for
another if the community has a strong preference.

   john

---

From: Julian Reschke <[email-masked]>
Date: Sat, 23 Aug 2008 09:33:56 +0200

John C Klensin wrote:
> ...

As a contributor to the xml2rfc toolset (rfc2629.xslt), I'm always 
interested in ways to make the document format more usable.

The proposal is very conservative, in that it seems to try to make the 
smallest possible change to allow real figures. That's fine.

On the other hand, I'd really love if we could make a bigger step (like 
using a subset of XHTML as markup, allowing in-line raster graphics 
(such as PNGs) and allowing a bigger character repertoire, at least for 
author contact information, references etc).

BR, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Aug 2008 14:01:09 +0200

...

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
page(s).)

Regards,

	Henrik

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 23 Aug 2008 14:55:21 +0200

John C Klensin wrote:
 
> My hope is that we can discuss and figure out whether
> the community likes and will accept the general idea.

What *is* the general idea ?  If it's "attaching" one
or more figures / images to an RFC I'm fine with it.

Technical detail, for some years we could still stay
within the limits of 8+3 like so:

rfc5555.txt, rfc555a.svg, rfc5555b.gif, rfc5555d.png 

The a..z (26 figures) is not a hard limit, aa..az etc.
is in theory possible (but not more 8+3).  

Your proposal rfc5555.img.pdf gets the conflict with
8+3 now.  And it makes it hard to address individual
figures within this proprietary container format.

It's not impossible, the application/pdf RFC explains
how fragments can address parts of a PDF, but I think
it's rarely used.  

As soon as you have "more than one" part you can as 
well go for the real thing, each figure in a part,
skip the ugly container.  Or pick SWF instead of PDF,
I'd like it better.  What about ordinary TGZs if you
insist on a container format ?  

"Anything PDF" is a serious showstopper from my POV.

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Sat, 23 Aug 2008 18:01:24 +0200

> rfc5555.txt, rfc555a.svg, rfc5555b.gif, rfc5555d.png 

Frank,

if you feel that 8+3 is a limit we need to consider, what's your opinion 
on the naming convention for internet drafts?

BR, Julian

---

From: John C Klensin <[email-masked]>
Date: Sat, 23 Aug 2008 14:01:29 -0400

> the text to the actual figure.

I was assuming that such a tool could reasonably be manual,
since the "image file" would presumably be fairly static.
However...

> produce non-consecutive page numbers for the trailing
> boilerplate page(s).)

That was more or less where we started, and something we came
back to a few times.  The problem is a different and very
practical one.   I've been advised by colleagues in the library
community that the "Plate-1" / "Figure-1" model (or even leaving
those pages unnumbered, which is also common) works because the
pages are physically bound in with the rest of the volume.   If
they are lose, they are often given different accession numbers,
separate check-out records when that is relevant, etc.,  from
the base document/book, just to be sure that both pieces can be
kept track of.  We have no direct analogy to that unless, e.g.,
we don't store "rfcN.txt" and "rfcN.img.pdf" in the archives at
all but instead (borrowing a suggestion from a private note) we
store "rfcN.zip" or "rfcN.sh" (a self-extracting script).
Storing a "get one piece, get it all" aggregate that way has
some considerable advantages, but also considerable
disadvantages (e.g., your retrieval tools would have to extract
the pieces and sort things out).

All of that would be almost irrelevant were it not for the IPR
issue.  The "number consecutively and use common headers and
footers" idea emerged in part from a discussion with Counsel
about whether separate boilerplate would be needed for the image
file.  Even starting down the path of that discussion leads us
into the obvious debate about what should be in that
boilerplate, who could use what for which purposes, etc. -- a
debate that, speaking personally, I'd prefer to avoid at almost
any cost.

By the way, another obvious alternative, which would be
numbering the pages of the image file so that they started
_after_ the boilerplate page of the text base RFC, runs into the
same problem because there are requirements in our various
documents, and perhaps legal requirements, that the "last page"
boilerplate be the last page, not buried somewhere in the middle
of the logical document.

Note that, whether it is a good idea or not, and whether it
should be done by the RFC Editor, otherwise, or not at all, the
format as specified would permit the creation of a rather
trivial of a merging process/ script that would:

	(1) Generate the PDF-print (no additional formatting)
	version of the ASCII text (i.e., the object that now has
	the file name rfcN.txt.pdf if it exists)
	
	(2) Create a new, composite, PDF file that contained
	pages 1 .. N-1 of the output of (1), the image file, and
	then page N of the output of (1).

Numbering the figures/plates in a completely different way
doesn't make that harder, but it does make the result look a
little less coherent.

    john

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 23 Aug 2008 19:37:50 +0200

Julian Reschke wrote:
 
> if you feel that 8+3 is a limit we need to consider,
> what's your opinion on the naming convention for
> internet drafts?

My knowledge about old CD-ROM file system is limited
to "works for me", and I didn't boot a DOS partition
for years (well, once some months ago, but it was no
situation remotely related to reading Internet-Drafts)

But I don't see how potential PDF/A interoperability
messes are necessary for the mere purpose of attaching
figures to RFCs.  As far as I can tell it PDF/A would
not work for say "acroreader 3" because it embeds the
relevant fonts.  Users of this historic reader could
upgrade to ghostscript, but I've not the faintest idea
if it would allow them to create (not only view) PDF/A.

Creating PDF/A is the key for "open and fair".  At one
point John even wrote "author or editor" where I think
he meant "author or reader".  But this also stresses
my point:  Can everybody *create* PDF/A ?  With free
tools on any platform they care about, maybe limited
to "modern" non-mobile platforms of this millennium ?

 Frank

---

From: John C Klensin <[email-masked]>
Date: Sat, 23 Aug 2008 14:20:00 -0400

> or more figures / images to an RFC I'm fine with it.

That is it.  No intention to solve all possible problems, just
what appears to us to be a large and growing subset in which
pretty-printed figures, images, and the like would significantly
add to RFC comprehensibility without having to reopen the debate
about alternate base formats, searchability, etc., etc.  

It is our belief that, modulo some tuning, this proposal is
likely to be able to get community consensus.  Based on the
outcomes of the discussions that have arisen every several years
for what seems forever, there is little or no hope getting
community consensus for any of the "publish RFCs in my favorite,
pretty-printed, format with inline images instead".   I
sincerely hope that we can have a discussion about this proposal
without reopening that debate and/or that people who want to
have that debate will consider getting this approved and
deployed as a useful step in the direction of their goals since
it would demonstrate the utility of better illustrations.

> rfc5555.txt, rfc555a.svg, rfc5555b.gif, rfc5555d.png 

Note that we already have rfcNNNN.txt.pdf and some other
relationships that take us outside 8+3, Internet-Draft naming
conventions that are (as Julian pointed out indirectly) _far_
outside 8+3, and so on.  So I'm not sure what you are trying to
preserve here... it seems to me that we abandoned 8+3 years ago.

> "Anything PDF" is a serious showstopper from my POV.

One of the concerns in putting this proposal, and a major reason
you didn't seem something like it several years ago, is the
question of whether _any_ format other than plain ASCII text is
sufficiently stable long term.  PDF (and preferably PDF/A) was
chosen because, not only is there a stable pair of ISO
standards, but PDF/A is considered stable by the archival /
depository librarians, whose traditional criterion for stability
involves a considerably longer timeframe than even the IETF.
No other contemporary image, image-file, or page definition
format comes even close whether you (or I) "like it better" or
not.  And there is really no issue about a container format
here, even if you consider a multi-page PDF file to be such a
format.  If one gets involved with containers, even "ordinary
TGZ", and one immediately gets involved with questions about
availability and stability of decoders.  At least Multics/
first-generation-U**X archive files, like self-extracting shell
scripts, can be disassembled with a text editor, but I'm not
sure I'd recommend them either.

    john

---

From: John C Klensin <[email-masked]>
Date: Sat, 23 Aug 2008 14:36:44 -0400

> to "modern" non-mobile platforms of this millennium ?

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
document deliberately does not impose that requirement (it
doesn't even require PDF/A output, just recommends it as an
example).

What goes to the RFC Editor is

	(i) A text file and maybe xml or nroff that the RFC
	Editor is willing to edit/process.
	
	(ii) An image file in some format the RFC Editor is
	willing to deal with.  Certainly standard PDF would be
	an appropriate input format, but there could be
	others... and there is no strong requirement for PDF/A.
	Note that, as the spec is now written, the only free
	text in that image file is figure titles, captions, and
	numbers and that it is certainly within the "style
	manual" discretion of the RFC Editor to make
	requirements about the fonts to be used (excluding,
	e.g., 22ndCenturyPostModernObscura).

The RFC Editor takes (i) and processes it more or less as they
do today.  They take (ii), merge in header and footer blocks,
and produce an output file.  That output file is expected (more
or less, see above) to be in PDF/A.  

But that means that one needs exactly one copy of one tool that
can read in PDF (or another approved image file format), overlay
header and footer blocks, and produce PDF/A.   The rest of us do
not need to create that format at all, so how available the
tools are isn't a major concern.

And, yes, I believe that you are correct that Acroread 3 cannot
read PDF/A files, or anything else with embedded fonts.  Neither
can "cat" do a reasonable job of mapping such files to standard
output and having something useful show up on the screen.  I
don't know if I want to go as far as to say "so what?", but,
unless we can move forward enough to accommodate this fairly
minor --but, IMO, powerful) extension, then there is no way
forward. Please also remember that, in sufficiently unusual
circumstances, it is possible to publish an RFC in Postscript
(with its significant interoperability problems) or PDF with no
ASCII base form at all.  So, if you can't read PDF (or
Postscript), those RFCs are inaccessible to you in their
entirety today.   Not much new here.

     john

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Aug 2008 21:13:30 +0200

Hi John,

> since the "image file" would presumably be fairly static.

If a 'Figure concordance file' was produced manually as part of
the publication process, maybe this would work for RFCs, but I
can't really see it working for drafts.  If I even had to spend
one minute doing manual work for each new draft, in order to
produce the htmlized draft versions, it just would not happen.

> the pieces and sort things out).

I'm not so sure the disadvantages are of any great account; while
I also considered the advantages of making a bundle available. I
think, however, that this really is peripheral to the issue of
how to number the Figures pages.

> debate that, speaking personally, I'd prefer to avoid at almost

Hmm.  Understood.

> boilerplate be the last page, not buried somewhere in the middle

Right.

> doesn't make that harder, but it does make the result look a

True.

I'm still concerned about the lack of a solid machine-readable
coupling between figure number in the base document and page
number in the pdf file.  But if my proposal of numbering the
pdf pages with figure numbers doesn't fly, I'll look for
alternatives.

Regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Sat, 23 Aug 2008 21:41:18 +0200

> situation remotely related to reading Internet-Drafts)

As a matter of fact I've been writing CD-ROM drivers (both low level and 
filesystems) in a previous live.

Even back then (in the late 90s), there were at least two extensions 
(Rockridge and Joliet) that allowed longer filenames, the latter being 
supported by Windows 98 and (I guess) everybody else.

> to "modern" non-mobile platforms of this millennium ?

That's a good question. See, for instance 
<http://xmlgraphics.apache.org/fop/trunk/pdfa.html> (FOP would be an 
obvious open source choice for producing PDF/a from xml2rfc input).

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 24 Aug 2008 01:05:30 +0200

John C Klensin wrote:

> PDF/A is considered stable by the archival / depository
> librarians, whose traditional criterion for stability

Yes.  And clearly we can't pick DejaVu, but when it goes
to archival formats without fonts DejaVu is interesting.
Just because it is patented does not mean that it is bad,
and similar just because PDF/A is an ISO standard doesn't
mean that it is good (for the IETF).

For your limited purpose of "attach some images" TAR is
a respectible container format, it is likely a part of a
POSIX standard.

Ordinary W2K users like me can go to a command prompt and
say pax, so it's builtin on a MS platform (I can't say if 
that's still the case for XP and Vista).  For those folks
actually testing this now, simply abort pax with ^Break :-)

For my TGZ proposal we'd know where to find the gzip RFCs.

> format comes even close whether you (or I) "like it better"
> or not.

IBTD, image formats like GIF, JPG, and PNG are very popular.

My SWF proposal was in parts a joke.  I mentioned it, because
from my POV *everything* including SWF is better than PDF.
  
I'd prefer ODF, ooXML, RAR, and CHM in no particular order.
And two of them have an ISO number, if that's what it takes.

I had enough trouble with PDFs.  I'm now on a platform where
I can *read* most PDFs.  It requires about 100 MB disk space,
occasional security updates from scratch (try it over a V.90
line), and many 1 MB PDFs boil down to 1000 ASCII characters.

Which is kind of beside the point, because you want PDF as a
mere container for pictures.  So what is wrong with say SVG,
if you think that PNG isn't as popular as PDF ?  

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 24 Aug 2008 01:51:44 +0200

Julian Reschke wrote:

> I've been writing CD-ROM drivers (both low level
> and filesystems) in a previous live.

Sounds like fun.  The one time I needed to write an
ersatz-file system I got away with flat CP/M style.

Looking around in the mounted CD (Unicode 5.0) all
is fine on my platform, long names, GIFs, JPGs, ZIPs,
TXTs, HTMLs, CSS, and also some PDFs.  Version 1.3,
so this should work on OS/2, and it can't be PDF/A.

> <http://xmlgraphics.apache.org/fop/trunk/pdfa.html>

Interesting, thanks for the link.  When John wrote
that PDF/A is the real thing for long-term archiving
he didn't mention that this is a baby in comparison
with GIF87a (over 20 years) or PNG (about 15 years).

"Get the license for the fonts" might be a relevant
hint for PDF/A producers (here the RFC-editor).

> an obvious open source choice for producing PDF/a
> from xml2rfc input.

Yes.  The page mentions Java, that's another 200 MB
to download for folks who don't have Java yet, again
with occasional security updates from scratch.

Sigh,

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 24 Aug 2008 03:06:56 +0200

> Editor is willing to edit/process.

Yes, that is as it is today.  I'd be opposed to *any*
changes without an ACK by Henrik for the IETF Tools,
and by Julian for his XSLT magic.  And of course Bill
and Marshall, if major changes affect xml2rfc proper.

We are talking about thousands of hours of voluntary
efforts that went into various existing tools.  For
50 exceptions in over 5000 RFCs this is no big deal.

But a general "image permission" is different, folks
might actually adopt it instead of ignoring it.
 
> willing to deal with.  Certainly standard PDF would
> be an appropriate input format, but there could be
> others...

What is the standard image format in PDF ?  Julian's
FOP-link informed me that this is certainly not EPS.

[Some speculations about FAX formats removed before
 sending this...  But I hope you also evaluated FAX.] 

> it is certainly within the "style manual" discretion
> of the RFC Editor to make requirements about the
> fonts to be used (excluding, e.g., 
> 22ndCenturyPostModernObscura).

Each "imaginary RFC" with its own IPR statement about
embedded fonts, I see.  You discussed it with Jorge,
so I guess you are aware of such traps and pitfalls.

[As always:  IANAL, and that is not going to change.]

> The rest of us do not need to create that format at
> all, so how available the tools are isn't a major
> concern.

Okay, glad to hear that.

> I don't know if I want to go as far as to say "so what?",
> but, unless we can move forward enough to accommodate
> this fairly minor --but, IMO, powerful) extension, then
> there is no way forward.

NAK, the idea to attach some selected image formats for
RFC figures does *not* require PDF.  It does not require
any container format at all.  And the actual version of
xml2rfc (without change) can produce HTML with links to
embedded pictures.  

IMHO quite ugly HTML without CSS.  But when you consider 
an acroreader 3 as "prehistoric" (that is PDF 1.3, your
postmodern PDF/A is apparently an 1.4 profile) then you
can also consider "ugly HTML without CSS" as irrelevant.

> it is possible to publish an RFC in Postscript (with
> its significant interoperability problems) or PDF with
> no ASCII base form at all.

Yes, and there was a time when my ghostscript could read
*any* PS (including the rare PS RFCs) I cared about, but
no PDF I was interested in (for that I had acroreader 3,
plus its somewhat obscure netscape 3.x PDF plugin).

Three years ago Bill started a PDF interoperability test
on this list, and because that was a miserable failure
from my POV I got around to find a fresher ghostscript,
with that I had more luck.

> if you can't read PDF (or Postscript), those RFCs are
> inaccessible to you in their entirety today.   Not much
> new here.

Google transforms relevant PDFs into HTML, they don't do
this because everybody prefers PDF.  There is a Firefox
extension transforming PDF to HTML on the fly, it is not
popular because folks like PDF.

 Frank
-- 
PDF is the worst document format since humankind gave
up on using runes in stones for longterm archiving.

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 24 Aug 2008 13:43:33 +0300

This draft tries to solve ONE of the problems we were attempting to solve
in draft-ash-alt-formats (now expired),
namely, handling figures that are hard to render in ASCII art.

On the other hand, the proposed solution reminds me of the state-of-the-art
in the 1980s when I had to submit academic papers with the all figures at the back.
This makes it hard to read and hard to understand.
When reading on a screen (and we don't want to force people into printing everything)
it will be extemely difficult to see the figure and the relevant text at the same time.

One solution would be to have a tool that merges the two files on the screen.

In any case, if we have agreement as to a format (e.g. PDF/A) to be used for non-ASCII,
then why not use that format for the entire draft ?
If we ARE worried about the survivability of the non-ASCII file,
then this proposal does not solve anything,
as the figureless ASCII version will be incomplete.

Y(J)S

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Aug 2008 14:15:23 -0700

>about alternate base formats, searchability, etc., etc.

While it is easy to agree with the "no intention to solve all 
possible problems", the proposed solution is much more difficult than 
is needed, and is also prone to problems in the long term.

 From the draft, the problem to be solved is:

    Documents in the RFC series normally use only plain-text ASCII
    characters and a fixed-width font.  However, there is sometimes a
    need to supplement the ASCII text with graphics or picture images.

Given that problem statement, a simple solution would be for RFCs to 
be able to reference art files archived by the RFC Editor using 
format-neutral URLs. Initially, those art files could be GIFs, PNGs, 
or PDFs. Years from now, when there are no commonly-available readers 
for a particular image type that was used earlier, the RFC Editor of 
the time can convert the old images to newer ones.

An example of a format-neutral URL might be 
<http://www.rfc-editor.org/rfcs/rfc5110.art>.

This proposal takes no changes from the current format for Internet 
Drafts or RFCs. It does require that the RFC Editor add some tools 
and maintain URLs in a consistent manner, but that is what they are 
paid to do. It also avoids the problems that have been listed so far.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 26 Aug 2008 00:34:00 +0200

>  need to supplement the ASCII text with graphics or picture images.

ACK.  Please note the plural, graphics or images, one or more.

> a simple solution would be for RFCs to be able to reference art
> files archived by the RFC Editor using format-neutral URLs.
> Initially, those art files could be GIFs, PNGs, or PDFs. Years
> from now, when there are no commonly-available readers for a
> particular image type that was used earlier, the RFC Editor of 

My condolences when they are ever forced to do something more
complex than "rm" with "PDF abused as artwork".

> paid to do. It also avoids the problems that have been listed so far.

Yes.  It has to be tuned for the "or more" part of "one or more".

E.g., rfc5110.a01 for artwork 1, and so on.  Yakuv's idea was
apparently to embed the figures directly where they are used in
formats supporting this, XML, XHTML, or PDF.  (For the X-fomats
an "embedding" is of course by reference, no B64 data-URL stunt).

 Frank

---

From: "Tim Bray" <[email-masked]>
Date: Mon, 25 Aug 2008 15:56:10 -0700

>    need to supplement the ASCII text with graphics or picture images.

Pardon my reverse-parochialism, but I think the need to be able to
spell editors' and contributors' names correctly, and give examples of
messages containing payloads which are not expressible in 7-bit
characters, dwarfs in importance the need to decorate RFCs with
pictures.  -Tim
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Aug 2008 15:56:30 -0700

>Yes.  It has to be tuned for the "or more" part of "one or more".

I can't fully parse your meaning, but I think I disagree. The RFC 
Editor, on a case-by-case basis, can choose to have one file 
containing multiple figures, or multiple files. The important thing 
is that the URLs used by the RFC Editor for any art needs to be 
long-lived and not tied to the format of the artwork.

>an "embedding" is of course by reference, no B64 data-URL stunt).

I agree with John, and strongly disagree with Yakov, that agreeing on 
a format for text with embedded graphics for the RFC series is still 
impossible.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 Aug 2008 19:23:06 -0400

--On Monday, 25 August, 2008 15:56 -0700 Tim Bray
<[email-masked]> wrote:

> Pardon my reverse-parochialism, but I think the need to be
> able to spell editors' and contributors' names correctly, and
> give examples of messages containing payloads which are not
> expressible in 7-bit characters, dwarfs in importance the need
> to decorate RFCs with pictures.  -Tim

Tim,

The requirement you are stating morphs into the "RFCs in UTF-8
issue".  It is actually a different issue than the image one, in
the sense that, if one could have textual RFCs in UTF-8 (or some
other Unicode flavor), then one would still have the image
problem (which is not really about pictures or decoration but
about being able to express flows, relationships, and similar
diagrams in a clear and concise way.

I see some fairly significant problems with most of the "RFCs in
UTF-8" or equivalent proposals I have seen, many of them having
to do with environments in which UTF-8 is not as ubiquitous as
one might like to believe.   But I don't any point in trying to
discuss or critique such proposals until there is one... and
"proposal" in the IETF continues to mean "write an I-D", not
"sketch an idea on a mailing list" or "express outrage that
something isn't possible/ permitted".

In the meantime, we put this particular proposal together
because it seemed useful, seemed like a plausible solution to a
known and clearly-identified problem, and seemed like something
on which  we might be able to get consensus on the general idea
and then refine the details (unlike more radical proposals to
change the ways in which RFCs were published and archived, which
have always ended up in rat holes or worse).  If, instead,
people want to argue that nothing at all should be done until
they get their particular preferred "most important" change...
well, I can't prevent you or them from doing that and wouldn't
try, but you will forgive me if I don't believe it is
constructive.

   john

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 26 Aug 2008 03:01:40 +0200

Paul Hoffman wrote:

>> It has to be tuned for the "or more" part of "one or more".
 
> I can't fully parse your meaning, but I think I disagree.

Yes, I also think we disagree.  I prefer one file and URL per
figure, avoiding all questions of TARs / ZIPs / JARs / TGZs
to bundle them.  

> The RFC Editor, on a case-by-case basis, can choose to have
> one file containing multiple figures, or multiple files.

Can we maybe agree on "one subdirectory" for these "packs" ?

I'd like to have a "one-click interface" (IPR: ammazon) per
figure.  You mentioned GIF and PDF.  Of course it's somehow
possible to put more than one image in a GIF89a - after all
that's how "animated GIFs" work.  But it's then a pain to
get at an individual image.  Similar PDFs can have multiple
parts, but there is no way to address individual parts in
URLs.

Your art-proposal is more KISS than John's PDF-proposal and
therefore better, but IMO still not yet simple enough.

> The important thing is that the URLs used by the RFC Editor
> for any art needs to be long-lived and not tied to the
> format of the artwork.

Yes, but mixing my rfc5110a.svg, rfc5110b.png, etc. idea with
your rfc5110.art idea is possible: rfc5110.a01, rfc5110.a02,
and so on.

 Frank
-- 
P.S., unrelated, John wrote about UTF-8:

| I don't see any point in trying to discuss or critique such
| proposals until there is one... 

http://purl.net/xyzzy/home/test/draft-hoffman-utf8-rfcs-01.txt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Aug 2008 18:19:16 -0700

>figure, avoiding all questions of TARs / ZIPs / JARs / TGZs

There are no such questions with the proposal. The RFC Editor gets to 
decide how to handle this instead of us trying to mandate this from 
IETF consensus.

>Can we maybe agree on "one subdirectory" for these "packs" ?

No. For one, I didn't say "packs", you did. For another, it is silly 
to try to lock this down now before we have working examples of what 
would be best.

>figure.

And I would like the RFC Editor to have flexibility to do the right 
thing as time moves on.

>http://purl.net/xyzzy/home/test/draft-hoffman-utf8-rfcs-01.txt

...which is long-expired for very good reason.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Tue, 26 Aug 2008 17:30:03 +0100

> On first reading this seems to be an interesting way to go.

It seems to be heading in the right general direction, but 
I wonder why it does not concentrate on specifying inputs
rather than outputs. Given that XML is now widely used as the
input format for RFCs, it seems worthwhile to review the bits
of XML-related stuff that are mature enough for use for writers.

For instance, SVG for diagrams and PNG for images, standard
CSS for tables.

Of course, there has to be a defined standard reporitory output
for "publishing" the RFCs, but that already seems to be PS/PDF.
If the IETF defines a standard input format, and the XML2RFC
toolset is updated to support that toolset and output PS/PDF
format for the repository, then that takes care of the format issue.
Then there is only one file, not two or three. And the toolset could
feasibly generate a text file plus PS/PDF images only format, as an
alternate output if that is desired. Or SWF output files, or TGZ
file with a folder containing HTML and separate files for each SVG
diagram or PNG image. No need to choose, just prioritise.

Stylistic issues are quite separate, although they should probably
also be specified up front if it keeps things more orderly. I'd suggest
avoiding numbering images/diagrams in favor of naming them. E.g. see
diagram former-state-machine or refer to image original-napkin-notes.

--Michael Dillon

---

From: John C Klensin <[email-masked]>
Date: Tue, 26 Aug 2008 12:45:04 -0400

Michael,

Please remember the following minor issues:

(1) xml2rfc may be widely used, but it is not a requirement or a
standard.  It actually has no formal status in the IETF.  Even
the informational RFC that describes it is long out of date.
All of that is reasonable for the way it is being used today,
but is not consistent with your proposal.

(2) People do prepare I-Ds and input to the RFC Editor in other
ways.  Plain ASCII text prepared with an editor, nroff, and,
using other sets of tools, MS Word are all in use and there may
be others that I don't know about.  The specification in the
image file document are compatible with all of these as well as
with xml2rfc (plus or minus some changes or post-processing).

(3) While one can debate it at length --and we, no doubt, will
have to do that-- the other graphic and specification mechanisms
you cite do not have either the track record or external
acceptance to make a reasonable guarantee of long-term stability.

   john

--On Tuesday, 26 August, 2008 17:30 +0100 [email-masked]
wrote:

> format for the repository, then that takes care of the format
> issue. Then there is only one file, not two or three. And the
> toolset could feasibly generate a text file plus PS/PDF images
> only format, as an alternate output if that is desired. Or SWF
> output files, or TGZ file with a folder containing HTML and
> separate files for each SVG diagram or PNG image. No need to
> choose, just prioritise.
> 
> Stylistic issues are quite separate, although they should
> probably also be specified up front if it keeps things more
> orderly. I'd suggest avoiding numbering images/diagrams in
> favor of naming them. E.g. see diagram former-state-machine or
> refer to image original-napkin-notes.
> 
> --Michael Dillon

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Aug 2008 17:45:32 +0100

Just a +1 to the thrust of Paul's suggestion. The I-D does
appear a bit over complex to me,

S.

---

From: John Levine <[email-masked]>
Date: 26 Aug 2008 18:13:21 -0000

>the time can convert the old images to newer ones.

That seems reasonable to me, too, although I am somewhat more sanguine
about the stability of image formats.  In 1992 I wrote a book called
Graphics File Formats, and almost without exception the formats we
described in that book are handled by all of the image tools that
people use today, including GIF, TIFF, PCX, JPEG, and BMP.

If we pick a small set of well-known formats, it'll be decades before
anyone has any trouble reading them.  Indeed, the hardest part of
implementing Paul's proposal will be to maintain the institutional
memory that the RFC Editor is supposed to do format translation if the
formats go stale.

R's,
John

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 27 Aug 2008 15:05:59 +0300

> characters, dwarfs in importance the need to decorate RFCs with

But then again the spell-check and name-checking
would assumably be in the ASCII portion of the text
(leaving aside L8N author names for the moment)
and all that wuld be needed is for the RFC editor to
run the checks on the text portion of the document
before making the final copy.

Making again the point made hundreds of times before,
the figures are not there for decoration.
I personally had to abandon writing drafts on 2 occasions
because I could not capture equations or formal diagrams.
One became a patent application instead of becoming IPR-free
(interestingly, patent offices the world over allow modern formats,
and archive granted patents going back to their beginnings)
and the second became an ITU-T Recommendation
(where PDFs are the normative format).

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 27 Aug 2008 16:26:09 +0300

> and there may be others that I don't know about.

A long time ago I used TeX. There was (and I believe still is) a LaTeX style file.

TeX was the distinct advantage that the source is pure ASCII
(and there are spelling checkers, bibliographic tools, etc.)
but the results are presentation-quality, including graphics.

It also is much richer in features than xml2rfc,
and has been debugged much better
(Knuth offers monetary rewards for finding bugs,
and doubles the reward each time).

(I had considered developing a new LaTeX style file and writing some tools
to go with it. But then I realized that once I "volunteered" to do that,
I would have to continue maintaining it for all time.)

Y(J)S

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Aug 2008 11:35:33 -0400

> A long time ago I used TeX. There was (and I believe still is) a LaTeX style file.

I was never able to get the LaTeX style file to work such that I got
perfectly-formatted output acceptable to id-nits.  (And id-nits was
quite a bit less rigorous the last time I tried this.)  

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 28 Aug 2008 11:39:18 +0300

> I was never able to get the LaTeX style file to work such that I got perfectly-formatted output acceptable to id-nits.
> (And id-nits was quite a bit less rigorous the last time I tried this.)

Which is precisely the reason that the style file will need constant upkeep ...

Y(J)S

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Aug 2008 15:43:40 +0200

On Mon, Aug 25, 2008 at 07:23:06PM -0400,
 John C Klensin <[email-masked]> wrote 
 a message of 49 lines which said:

> one would still have the image problem (which is not really about
> pictures or decoration but about being able to express flows,
> relationships, and similar diagrams in a clear and concise way.

To express flows, relationships, state machines, etc, I *much* prefer
formal languages to images.

For an example for state machines, see <http://www.cosmogol.fr/>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Aug 2008 15:10:23 -0400

--On Thursday, 28 August, 2008 15:43 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

>> one would still have the image problem (which is not really
>> about pictures or decoration but about being able to express
>> flows, relationships, and similar diagrams in a clear and
>> concise way.
> 
> To express flows, relationships, state machines, etc, I *much*
> prefer formal languages to images.
> 

Stephane,

Nothing about this proposal, or the current RFC rules, prevent
you from doing that.   Other things might.  In particular, my
impression is that some members of the community aren't
comfortable reading definitions in formal languages and would
prefer other types of descriptions, one that they are sure they
understand.  Some of them might have even been on the IESG at
one time or another.  So you might get considerable push-back
during Last Call.  But, again, nothing in the "image" proposal
prevents your describing state machines in the formal language
of your choice or, for that matter, complaining on Last Call
every time one is described in images.

    john