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

[Ole Jacobsen]

On Wed, 16 May 2012, Julian Reschke wrote:
>
> I have no idea what specifically you are talking about when saying "lots of
> these issues". Maybe a concrete example would be helpful.

You missed the context which had to do with changing the way things 
are rendered through "local settings" in conflict (deliberate or 
otherwise) with whatever the designer had in mind. I consider this a 
BIG problem in web design. It is nearly impossible to print anything 
properly from any browser, it is simply not a solved problem, which is 
why so many websites give you PDF files if you need to print. The 
context was further that in print publishing, "design" is very much 
part of the readability and clarity. There was a suggestion that none 
of that mattered and we shouldn't spend any time on the topic. I 
disagree. Particularly since other SDOs very much do.

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

Why? Are we or are we not discussing the future of what RFCs should 
look like?

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

No, it hasn't. RFCs aren't written in HTML, they're written in plain 
ASCII text, or at least the final form is (was). Count the number of 
times people on this list have complained about being able to simple 
print an RFC. Yes, this may be one way we solved that problem in the 
future (by using HTML or XML or whatever).

Again, I don't mind a lot of focus on engineering a solution, I would
expect nothing else from this group, but I still have very little 
sense of the "bigger picture" in terms of what we want from our future
RFCs in terms of format, including "presentation".

Ole


> 
> Best regards, Julian
>