[rfc-i] RFC Format - final requirements and next steps
paul.hoffman at vpnc.org
Mon May 14 16:40:37 PDT 2012
On May 14, 2012, at 12:50 PM, Tim Bray wrote:
> There are a few items in this list that I do *not* support. Possibly
> I’m an outlier, in which case feel free to ignore. For simplicity,
> I’m reproducing the relevant bits of the list.
> Draft-Edit, Review (what authors, ADs, and other interested parties
> worry about when writing and reviewing an I-D)
> Need to be able to include graphics/images
> Do not agree. IETF has done without this for a long time and I haven’t
> heard a single convincing narrative about how usability of specs or
> interoperability of results (and these are the things that matter, in
> the final analysis) have been seriously damaged. Plus, getting
> agreement on technologies and editorial issues around graphics is
If the usability is damaged, it doesn't have to be "significantly" for us to want to make a change. I have seen documents where the flow diagram is complex, too complex to use text art but possible to describe in long sentences with lots of "if X is the case, then...". A diagram there would certainly help. The text is correct, but we don't know if it is understood by everyone until we see misimplementations that are based on well-intentioned developers who misunderstood the if-then tangle. A picture would have helped a lot.
I have been in WG meetings where a fairly clear diagram is shown in the slideware and the presenter says "I wish I could turn this into text art but can't". The spec has language, but not enough.
My proposal allows art. The streams themselves might have rules on where art can and cannot be used. Personally, I would hope that any art that has text that should be searchable is either text art or an art pointer with a complete written equivalent immediately before or after the art.
> Want broader character encoding for body of document
> I don't think you have consensus for this, except for the special case
> of examples which require larger character repertoires than are
> necessary for the explanatory text.
It sounds like you are agreeing with the requirement, then.
> Want a more flexible line length
> I don't think this is really a requirement. We want the ability to
> print better, and to use mobiles, but line length specifically?
Agree; we want better display, not different line lengths.
More information about the rfc-interest