[rfc-i] Towards Consensus

Iljitsch van Beijnum iljitsch at muada.com
Sat May 26 01:52:29 PDT 2012

On 25 May 2012, at 17:46 , Phillip Hallam-Baker wrote:

> Proposition 1: It is reasonable for a participant to request the ability to read IDs and RFCs in a particular format.


> Proposition 2: It is utterly unreasonable for anyone to demand that others read IDs and RFCs in a particular format unless there are specific reasons why a particular format is necessary

I see where you're coming from, but I don't completely agree. It's also unreasonable to require people to speak English at IETF meetings, but without common ground in our communication it's impossible to get work done. We can't have the situation where different people insist on using different versions leading to different results. So one format needs to be more equal than the others. Of course as long as the results are the same this isn't an issue.

> I do not want people to be required to produce plaintext versions of drafts dealing with I18N.

This whole unicode example thing is a red herring. Just look at the issues displaying those in our email discussion here. You simply can't depend on the ability to render them by the hard/software and the ability to recognize them by the reader.

It's a red herring because electrical engineers don't include voltages in their documents, either. Text is and should be sufficient.

But please don't take the above to mean that I am against all forms of non-ASCII unicode, just that it's not something very important.

> Proposition 3: How to support included files (images, source code) should be considered separately from whether to support them

Disagree. Consider together, consider separately, it doesn't matter.

> Proposition 4: XML2RFC MUST continue to be supported as an input format

Disagree. Obviously it will take time to phase out XML2RFC, but we can't be beholden to a particular tool in perpetuity.

> Proposition 5: HTML MUST be supported as an output format

Although I agree that this is the most likely outcome, making this a MUST at this point seems premature.

> Proposition 6: HTML output SHOULD use a restricted set of HTML features.

MUST. The full set of HTML capabilities is too unwieldy, too much in flux and not implemented widely enough.

> Proposition 7: HTML is capable of serving as both an input format and an output format

If 5, then yes.

> I think proposition 4 is self-evident. There is a considerable investment in the XML2RFC format. Even if additional input formats are supported it is going to be necessary to support XML2RFC for legacy.

What I envision is that XML2RFC is extended to output the new HTML format. People who have XML2RFC stuff lying around can then convert their documents and from then on work in HTML.

> But even though HTML is inevitable, the full HTML feature set is not.


> It MUST be possible to roundtrip information from the HTML profile to the XML2RFC format and back.

Strongly disagree. This would either make the conversion tool extremely complex, or require the HTML format to stick very closely to the XML2RFC format, to the severe detriment of the new HTML format.

[from another message]

> We already have tools to convert XML2RFC. If we have a decent profile for HTML that captures all the metadata we want it is going to be pretty easy to convert that HTML output back to XML2RFC. In fact the ability to round trip like that seems to me to be one of the success criteria that is inevitable.

Explain to me how you get this:

<reference anchor='I-D.liu-behave-ftp64'>
<title>IPv6 IPv4 translation FTP considerations</title>

<author initials='D' surname='Liu' fullname='Dapeng Liu'>
    <organization />

<author initials='Z' surname='Cao' fullname='Zhen Cao'>
    <organization />

<date month='August' day='26' year='2009' />

<abstract><t>The File transfer protocol, which is defined by the RFC 959, is widely used. RFC 2428 define IPv6 extensions of FTP, introducing EPRT and EPSV command.  In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. There already have some work to address this problem, such as "draft-van-beijnum-behave-ftp64-05" etc, but this document provides a different approach.</t></abstract>


<seriesInfo name='Internet-Draft' value='draft-liu-behave-ftp64-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-liu-behave-ftp64-03.txt' />

From something like this:

              Liu, D. and Z. Cao, "IPv6 IPv4 translation FTP
              considerations", draft-liu-behave-ftp64-03 (work in
              progress), August 2009.

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.

> 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.

> 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. 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.

More information about the rfc-interest mailing list