[rfc-i] RFC Format - final requirements and next steps
ole at cisco.com
Wed May 16 01:43:02 PDT 2012
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
Why? Are we or are we not discussing the future of what RFCs should
> 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".
> Best regards, Julian
More information about the rfc-interest