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

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

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

Harry Lewis harryl at us.ibm.com
Mon Jun 23 19:47:33 EDT 1997


I've gone back and reviewed this thread before commenting. It seems mostly like
a "religious" discussion based on programming style and preference. I don't buy
that extensibility is easier via text. This is only true if you don't believe a
central
body will continue to exist to review and "issue" new extensions. If we end up
without a central body, then we have "free-for-all" vendor extension via text
and interoperability degrades, anyway. I don't buy the network sniffer
argument. Network sniffers decode wire protocols and present them in a more
friendly fashion.


The one thing that may be overlooked or un-stated in the discussion is that the
IPP Server may well reside on an embedded controller within a printer where the
effect of storing and parsing strings *can* have a significant effect and where
"programmatic" issues should be favored over human readability.


>>>Harry Lewis<<<




---------- Forwarded by Harry Lewis/Boulder/IBM on 06/23/97 05:17 PM ---------


        ipp-owner at pwg.org
        06/22/97 01:39 PM
Please respond to ipp-owner at pwg.org @ internet


To: rturner at sharplabs.com @ internet, ipp at pwg.org @ internet,
SISAACSON at novell.com @ internet
cc:
Subject: RE: IPP>PRO: sorry, binary is better (?)


I have a genuine confusion over something - fundamentally I agree that
the encoding is trivial. BUT I question the reason for insisting on
ASCII - this is a much more interesting question "If its trivial why do
we care either way?", why not just choose the simplest to implement.


I think we have a fundamental disjunction of requirements here.


The idea of IPP is to develop a strong program to program protocol for
clients to talk to servers. Yet the major reason for the ASCII encoding
is so that the client does not have to understand the semantics of the
protocol - i.e. the intention is to allow it to be just displayed on the
screen (after some syntactic munging). This seems to be a pair of
requirements in direct conflict with each other - A client server
protocol that the client does not need to understand. This is just a
display protocol , of which we already have a perfectly good one - HTML.


Everything you are talking about doing can be done using web pages and
an exisiting browser.


Example:-


-If the protocol is going to be read by a program then the encodings are
just 'magic numbers' regardless of text or binary. We could choose the
number '42' to mean 'copies' or we could choose numbers 'COPIES' to mean
copies just so long as we (the implementors) all agree.


-If the protocol is going to be read by a human then we might say "Enter
the number of copies" (in their native language) or even "How many
copies do you want"


We cannot have both. I think this mixed mode is being used to persuade
ourselves that we have solved a profound problem that, in fact, we have
not - the problem of attribute extensibility at a programmatic level.


My fear is that we will end up with a mess and programs trying to
extract meaning from "Combien de copies voulez-vous?" - which is exactly
where we don't want to be.


I don't know - maybe I am missing something. What is it?




> -----Original Message-----
> From: Scott Isaacson [SMTP:SISAACSON at novell.com]
> Sent: Saturday, June 21, 1997 10:20 AM
> To: ipp at pwg.org; rturner at sharplabs.com
> Subject: Re: IPP>PRO: sorry, binary is better (?)
>
> I sure agree with Randy:
>
> >>> Randy Turner <rturner at sharplabs.com> 06/19/97 09:10PM >>>
> > This stuff is really too easy and we shouldn't worry about the
> > differences between
> > ASCII and binary at this point. The code difference is trivial.
> > I thought we have already made this decision?
>
> We seem to reach reasonable conclusions and then keep opening them up
> again.
>  I have
> reviewed several of the long postings on code and it is clear that the
> code and performance differences are TRIVIAL!!!!!!   Brain, Scott L,
> Jay,
> Bob, myself, and
> many others have pointed out many benefits of the ASCII version.
> There was
> a fundamental decision made LONG ago that an ASCII protocol should be
> used
> over a binary protocol.
> It was not re-opened until the SWP proposal in San Diego.
>
> We SHOULD NOT (oops, I had my I-D editors keyborad turned on there)
> remove
> the benefits of an ASCII protocol unless there is a "preponderance of
> evidence" and I
> just don't see it.
>
> In reviewing
>    -  the 6/17 meeting minutes,
>    -  the recent e-mail postings, and
>    -  the minutes from almost ALL of the weekly teleconference calls
> over
> that past 5 months
>           (which have been open to anyone)
> the overwhelming number of participants have expressed support for the
> ABNF based ASCII protocol.   It is not what I personally supported
> initially, but I wanted to make
> progress and listen to the group.  I know that this is not a
> "majority" vote
> situation, but if I were
> an objective outside observer, it would be clear to me  that we are
> close to
> consensus on
> the ASCII based protocol based on what is posted and reported by most
> of the
> participants.
>
> Scott Isaacson
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>



More information about the Ipp mailing list