[rfc-i] draft-rfc-image-files-03

Paul E. Jones paulej at packetizer.com
Sun Apr 8 13:20:30 PDT 2012

Put this draft into context.  It was submitted before a heck of a lot of
dialog happened on the mailing list.  It was one idea and I'm not sure how
many others were formally submitted for consideration; at the very least we
should thank the authors for putting forward a formal proposal.  Put your
hatchet away. :-)

As you know, there are several proposals on the table.  It would appear
(from making a pass over the archive) that a subset of HTML in UTF-8 and
storing images using <img src="data:/image/png;..."> is preferred.  It's
still not clear whether any image format would be acceptable or if people
want SVG.  I even saw some arguing images should not be allowed at all,
though I think flow diagrams, message sequence charts, etc. are usually
helpful in understanding a protocol.  Thus, I support a format that allows


> -----Original Message-----
> From: rfc-interest-bounces at rfc-editor.org [mailto:rfc-interest-
> bounces at rfc-editor.org] On Behalf Of Iljitsch van Beijnum
> Sent: Sunday, April 08, 2012 2:16 PM
> To: RFC Interest
> Subject: [rfc-i] draft-rfc-image-files-03
> I just had a look at http://tools.ietf.org/id/draft-rfc-image-files-03.txt
> I think this is a spectacularly bad idea. This way, we would have all the
> downsides of PDF, all the downsides of formatted ASCII text, and lose the
> advantage that we only have a single file.
> This also locks us into pagination even deeper, while IMO that's something
> we should move away from, because the number of times when US letter
> pagination is convenient are dwarfed by the number of times when it is
> not.
> There are lots of tools that read and write PDFs, but that doesn't mean
> it's necessarily reasonably possible to round trip an image from an image
> editing program to PDF and back without losing a lot of information. For
> instance, the image may be rasterized so what was a vector image is now a
> high resolution bitmap. Or logical structures are broken up in lots of
> small structures but the relationship between them is lost.
> I don't think these issues are easily avoidable without blessing a
> specific tool. And tools tend to go away on decades timescales. Therefore
> I think that if we want to allow images as authoritative parts of RFCs
> (which I still have to see a good case for) this needs to be relatively
> low resolution bitmaps in an open format, like PNG. Bitmaps have the
> advantage that they are very simple structures that are easily manipulated
> with simple software, not unlike ASCII files.
> Finally, let me observe that a lot of people here are applying a
> tinkering/hacking mindset, trying to get some benefits with modest
> changes. I don't think that's the right approach here. It's perfectly fine
> to make very big changes if that gives us what we need. Small steps are a
> bad thing here, that means that 20 years from now the tools that scrape
> the RFC repository need to support many variations that were around for
> only a short time rather than just "old" and "new".
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list