[rfc-i] Towards Consensus
jhildebr at cisco.com
Sat May 26 08:43:02 PDT 2012
On 5/26/12 2:48 AM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:
> Explain to me how you get this:
> <reference anchor='I-D.liu-behave-ftp64'>
> Liu, D. and Z. Cao, "IPv6 IPv4 translation FTP
> considerations", draft-liu-behave-ftp64-03 (work in
> progress), August 2009.
I wouldn't want to. I'd want to start with something marked up.
> The only way that works is by creating HTML versions of every possible option
> that XML2RFC supports, which would make the HTML format much more complex than
> it needs to be.
If we decide to go down this road, I think it's reasonable to have
discussions over which parts of the semantic data described by the
xml2rfc-format are important to carry forward. So far in looking at it, the
problem doesn't seem too bad.
>> 2) How to manage included files.
>> This is actually the hardest part when it comes to dealing with images and
>> source. I think that the easiest approach in practice is likely to be to use
>> MHTML format. This is widely supported by browsers, at least on the desktop.
>> so one way I could submit a document with included images as a draft would be
>> to bring it up in my browser, then select, 'save as MHTML' and submit the
>> saved file. That is clunky but not much more so than usual.
> Never heard of this, and I have no idea if my browser supports it. But for
> sure this will make text-based tools much more complex. In my opinion, images
> should remain optional as they are today, so it's perfectly fine if they are
> linked from the HTML and if someone then forgets to download the images along
> with the RFC file, they simply don't display, which is fine.
I still think data: URIs are just fine for the final published version.
Tooling can easily take an external reference to an image and inline it in
HTML. There is no need for MHTML or to settle for broken documents.
>> Some formats that we would require are pretty obvious:
>> Image: JPEG, PNG, HTML Vector
> No JPEG, that's for photos, which I don't think we need. PNG, yes, unless
> there is a compelling reason to use GIF instead. Vector is a bad idea, but
> I'll settle for requiring a bitmap alternative for any included vector images.
+1 on PNG. Agree no JPEG or GIF needed. Browser support for SVG is getting
there, but I'd suggest that we start small, and add stuff later. MathML is
further behind, so we have to deal with that anyway.
> As far as I know, PNG and GIF can be implemented by most programmers, but JPEG
> or vector formats are too complex to support in homegrown tools (without the
> use of external libraries). Remember, RFCs should still be decodable when the
> formats have fallen out of widespread use.
+1 for simplicity, particularly to start.
More information about the rfc-interest