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

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

Sylvan Butler SBUTLER at hpbs2024.boi.hp.com
Fri Jun 20 15:13:31 EDT 1997


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


>Sylvan Butler <sbutler at 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 at boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |



More information about the Ipp mailing list