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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf