ietf
[Top] [All Lists]

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

2008-08-23 20:05:42
John C Klensin wrote:

(i) A text file and maybe xml or nroff that the RFC
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.
 
(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...

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.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf