[rfc-i] RFC Format - final requirements and next steps
Iljitsch van Beijnum
iljitsch at muada.com
Tue May 15 03:30:31 PDT 2012
On 15 May 2012, at 12:11 , Stewart Bryant wrote:
> At the moment the image capable version of an RFC is no allowed to be the normative version.
Apparently this wasn't always so: http://tools.ietf.org/html/rfc1131
> If we could agree that the image capable version of the RFC is allowed to be the normative version, but the images themselves are either not normative
> or are normative only if explicitly stated, then I think there is a way forward.
"normative only if explicitly stated" doesn't seem like a useful variation to me. As far as I can see, there are three possibilities:
1. Images are not allowed
2. Images are allowed, but only as something extra. The RFC must completely specify the protocol / provide all the information without relying on the images.
3. Normative information may be available in just image form
The current situation is (more or less?) 2. I'm against 3, and I don't think I'm the only one. There are also significant numbers of people who are against 1. So it seems to me that staying with 2 is the most obvious choice, unless there is some really compelling argument in favor of 1 or 3 that we haven't heard yet.
Currently, there is a "non (graphical) image capable" normative format and a "(graphical) image capable" additional non-normative format. I would assume the new format would be image _capable_, although it may not necessarily have the images embedded and may not necessarily display images under all circumstances. (Which would of course be compatible with option 2 but not really 1 and certainly not 3).
More information about the rfc-interest