[rfc-i] Problems and requirements for RFC Format

Phillip Hallam-Baker hallam at gmail.com
Mon Apr 23 08:00:28 PDT 2012

It would be a heck of a lot easier to describe crypto protocols if we
could use subscripts. Then we can use the same notation in the
protocol that is used in the papers we are referencing.

On Mon, Apr 23, 2012 at 3:01 AM, "Martin J. Dürst"
<duerst at it.aoyama.ac.jp> wrote:
> 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.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Website: http://hallambaker.com/

More information about the rfc-interest mailing list