[rfc-i] Problems and requirements for RFC Format

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Mon Apr 23 00:01:07 PDT 2012


On 2012/04/18 21:22, Peter Saint-Andre wrote:
> On 4/18/12 1:00 AM, Stewart Bryant wrote:
>> On 18/04/2012 03:03, Peter Saint-Andre wrote:
>>> On 4/17/12 4:19 PM, Peter Saint-Andre wrote:
>>>> On 4/17/12 4:11 PM, Tim Bray wrote:
>>>>> I observe that several of your baskets include
>>>>>
>>>>> " * Need to be able to include complex graphics/equations"
>>>>>
>>>>> I think it may not be accurate to conflate these two.  There seems
>>>>> widespread support for equations.  But I’d like to place on the record
>>>>> though, that I do *not* support the addition of “complex graphics” to
>>>>> the RFC series.  We’ve done very well without them and some of us
>>>>> think it is actively beneficial to force authors to describe protocols
>>>>> in clear English without recourse to pictures.
>>>> I tend to agree.
>>> To expand upon that statement, I must admit to being concerned about
>>> people wanting to include the kinds of fancy graphics one often finds in
>>> whitepapers and presentations. Perhaps the answer to that concern is
>>> "exercise some self-control"...
>>>
>>> Peter
>>>
>> We have a review process that roots out unnecessary complexity in
>> text, why would it not root out unnecessary complexity in the figs?
>
> Hi Stewart,
>
> Well, for one, we have decades of experience with rooting out complexity
> and lack of clarity (etc.) in text. We have a lot less experience with
> rooting out complexity and lack of clarity in figures. That doesn't mean
> we can't gain such experience, but the learning process could be painful.

What does in mean to "root out complexity and lack of clarity" for text? 
It means you read it, you think about it, you try to ask questions, 
ideally, you try to implement it. If any of this fails, you complain.

So what does the above mean for graphics? Just about the same, except 
that we don't use "read" when we look at graphics, but that's a detail. 
Otherwise, the activities are quite similar. So I don't think there will 
be such a big problem. In other words, our ability to detect, and react 
to, complexity and inconsistency isn't really that much text-bound.

To be clear, I agree that "complex graphics" or "fancy graphics" is the 
wrong word, and that we don't need the stuff that one finds in 
whitepapers and presentations. But on the other hand, ruling out 
graphics from the start because some of them are bad seems a bad idea. 
There's not a (quantitatively) large need for graphics or formulae in 
the same way that there's not a (quantitatively) large need for 
non-ASCII characters. But for all these, there are cases where it 
clearly helps.

Regards,   Martin.


More information about the rfc-interest mailing list