[rfc-i] RFC Format - final requirements and next steps

[Julian Reschke]

On 2012-05-16 00:44, Ole Jacobsen wrote:
> ...
> What makes you think "the person changing the parameters" has ANY idea
> about the intent of the designer? And why do you assume that he or she
> changed ANYTHING. Lot's of these issues are badly chosen defaults,
> something somebody else picked.
> ...

I have no idea what specifically you are talking about when saying "lots 
of these issues". Maybe a concrete example would be helpful.

>> Do we do that today? Unless my memory is failing me I've never seen
>> ASCII art with the text continuing beside it in an RFC.
>
> Yes, ironically we DON'T do that today, but it IS done in most modern
> publishing systems, and has been done for hundreds of years.

We could start doing that; but that's a discussion we don't need to have 
right now.

>> This is a false dichotomy. We want to move away from imposing the
>> formatting that works best on a given output device on the file
>> format. If the file format is flexible, it can adapt to a large
>> range of display options. If the file format is HTML, CSS can be
>> used to adapt it to different displays and different user
>> preferences without the need to perform conversions or modify the
>> original file.
>
> Sure, but the trick is to find a source format that allows this.
> The fact that even a simple ASCII diagram can get really messed up
> if only ONE line wraps (or you chose a variable-width font) tells
> us that this isn't a simple problem to solve.

This problem has been solved reliably by the <pre> element in HTML many 
many years ago.

> ...

Best regards, Julian