ietf-openproxy
[Top] [All Lists]

RE: OCP message rendering

2003-10-08 09:46:59


Martin,

        I will reverse the changes and document line breaks exceptions
in the message rendering section.

        I am not sure whether it is a good idea to add a special "soft
break" character (e.g., '\' to follow C and Unix shell convention).
Using your own arguments, people may try to use those "soft break"
characters in real world and complain that they do not work.

        Anybody thinks it is a good idea to add '\' for rendering
purposes only?

        One solution would be to make SP and CRLF interchangeable, but
that complicates parsing. MIME has something like that (implied LWS
rule), but virtually no HTTP agent we tested supported it correctly!

        Finally, what do you think about indentation?  Can we still
use it for rendering purposes? Please? :-)

        {
                n1: v1
                n2: {
                        n21: v21
                        n22: v22
                }
        }

looks/reads much better than

        {
        n1: v1
        n2: {
        n21: v21
        n22: v22
        }
        }

Comments/opinions?

Thanks,

Alex.



On Wed, 8 Oct 2003, Martin Stecher wrote:




I got tired from counting characters and trying to preserve correct
spacing when typing OCP examples. Since OCP message format is strict
and well documented for machine use, I think it is wrong for us,
humans, to suffer from machine-level optimizations when
typesetting OCP
examples irrelevant to those optimizations.

...

I do not agree here.
People try how examples work. We will have prototype implementations that
just replay the examples from the draft and people wonder that they fail,
even more if the debugging output of a working other solution shows the
same output.
OCP is not a binary format and as being text it is easy to copy sample
messages and paste them in a telnet client, playing around with these
examples.
So, I am a strong supporter of having working examples somewhere.
And one of the best places for me is the official draft or RFC.

Line breaks are an exception, they are essential for rendering purposes,
some of those need to be removed to get working samples. An alternative
here could be to print a special character that marks those soft breaks
for rendering purposes.
That's why I'd welcome a Message Rendering Section that explains this.

I can review the examples in the draft and help to ensure correct character
counts and spaces.

Regards
Martin



<Prev in Thread] Current Thread [Next in Thread>