[rfc-i] Graphics and XML

Phillip Hallam-Baker hallam at gmail.com
Tue Jul 10 14:57:51 PDT 2012

The .mhtml format is supported by many browsers and is simply a MIME
message with a HTML body and included files as attachments.

High time that this became a standard piece of Web infrastructure. We
have a whole host of applications that need it. Firefox and IE have
had it for a decade and I think Safari has the same idea in a
different extension.

Reading the RFCs via the Web using any browser is definitely a
requirement. But the ability to read them offline in HTML is not such
a strong requirement in my view. So I suggest the following as output

1) Basic Web - HTML with links to .png files where images and anything
image-like appears.
2) Extended Web - HTML with links to standards based formats (PNG, SVG, MathML)
3) MIME archive of extended Web version
4) PDF of HTML version
5) Caveman format

It may look like a lot of options, but its not really and coding all
five output formats is undoubtedly less effort than arguing over them.

Format (1) is essential to meet the backwards compatibility
requirement, (2) is what we would want browsers to support and (3) is
required to meet the round trip capability requirement, (4) is for the
lawyers as PDF is how they talk, (5) is for people using the net from
a difference engine.

For originating text I would suggest the following approaches:

1) ZIP file of a directory containing the file bundle in a single directory
2) MIME archive format as per (3)

On Tue, Jul 10, 2012 at 12:37 PM, Yoav Nir <ynir at checkpoint.com> wrote:
> On Jul 10, 2012, at 7:15 PM, Paul Hoffman wrote:
>> On Jul 10, 2012, at 8:39 AM, Julian Reschke wrote:
>>> On 2012-07-10 17:23, Paul Hoffman wrote:
>>>> ...
>>>> For RFC output, a stable absolute URI would obviously be better than an unstable one. For Internet-Draft production, local relative URIs are possibly acceptable, but I would hope that the different streams would prohibit them.
>>>> ...
>>> For RFCs, assuming the RFC has a stable URI, a local relative URI will be stable as well, no?
>> Good call. I was thinking about the case where I downloaded the RFC and art, but moved the RFC to somewhere else but didn't move the art. Now that seems like an edge case. It is more likely that I will open the local copy of the RFC in its downloaded location, so the relative links would work fine.
> I don't know. How do you download the RFC? If you just click File-->Save As… in a browser, you will normally just save the HTML file, or batch-use wget to download a bunch of them. Yes, some browsers have the ability to save all contents in a single file, but they are not always interoperable between browsers (can anything other than Safari read .webarchive?). Besides, single files are easier to mail.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Website: http://hallambaker.com/

More information about the rfc-interest mailing list