IPP Mail Archive: Re: IPP>PRO: sorry, binary is better (?)

Re: IPP>PRO: sorry, binary is better (?)

Sylvan Butler (SBUTLER@hpbs2024.boi.hp.com)
Fri, 20 Jun 1997 12:13:31 -0700

>"Scott Lawrence" <lawrence@agranat.com> wrote:

>Sylvan Butler <sbutler@boi.hp.com> wrote:
>SB> That is what I was thinking on Tuesday 6/17, but actually doing
>SB> something with it and covering all the possibilities with ASCII seems
>SB> noticably more complex to implement and to test, and for no apparent
>SB> benefit.
>
> I'm sure that the complexity won't be overwhelming :).

:)

> The benefit is that the protocol is human-readable. Don't discount
> this too much; you are not going to quickly get vendors of network
> monitoring equipment deploying versions of thier products that will
> decode IPP (not until long after you're done, if history is any

Probably not. OTOH, when debugging a protocol I usually end up
staring at the hex-dump even when ASCII is interspersed. The
"readable" dump hides too much information that may be of import.
That is probably why there are HTTP servers on the Internet today
that don't have the specified line endings.

Or maybe this is all just because I spent too much of my early
programming years working in binary and hex. :)

I generally want the sniffer to decode all the parts that surround
what I am developing, but leave my part alone so I see all of what's
there and nothing that isn't there, including spaces, nulls,
linefeeds, etc.

I guess what I am saying, is I haven't found that "human readable"
to be very important, and I have seen too many problems caused by
trusting "human readable" instead of what the computer sees.

...

> One other note: when developing any protocol, one always discovers
> that things you thought would be easy aren't, and often the reverse
> too. If these discoveries always justify reopening early and
> fundamental design decisions (good or not so good), then you can end
> up with a process that goes on for a long long time...

That's for sure. Though I'd hardly call this one of our "early and
fundamental design decisions." The group has been debating this for
a very long time. I think the closest we have been to a decision was
the minutes from 6/17, or only three days ago.

sdb

| Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |