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

From: JK Martin <[email-masked]>
Date: Fri, 20 Jun 1997 12:51:15 -0400 (EDT)

> >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.
> 
> That is what I was thinking on Tuesday 6/17, but actually doing 
> something with it and covering all the possibilities with ASCII seems 
> noticably more complex to implement and to test, and for no apparent 
> benefit.

There are many of us (most of us??) who do not believe the statement
that "ASCII seems noticably more complex to implement and to test".
Furthermore, we do not believe the statement of "for no apparent
benefit".

Again I must ask:  what are we doing in IPP that is fundamentally
different than other web-oriented transactions utilizing HTTP?  Others
have not found a need to degenerate to binary encodings, so why should
we?

IPP is just printing.  It is *not* high volume transaction processing.
Staying in a text-only domain leverages the many text-based development
tools prevalent in today's web-centric environments that span the
entire set of applicable platforms.  (Read: fundamentally the same
regardless of Wintel vs. Unix)

Let's stay with text-only encodings for IPP.

	...jay

---

From: "Sylvan Butler" <[email-masked]>
Date: Fri, 20 Jun 1997 12:13:31 -0700

>"Scott Lawrence" <[email-masked]> wrote:

>Sylvan Butler <[email-masked]> 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 | [email-masked] | AreaCode 208 Phone/TelNet 396-2282 |

---

From: "Sylvan Butler" <[email-masked]>
Date: Fri, 20 Jun 1997 14:00:01 -0700

>that "ASCII seems noticably more complex to implement and to test".

When there is more code containing more loops and more conditionals 
the testing of that code is more complex.

>Furthermore, we do not believe the statement of "for no apparent

Let's discuss these benefits.  I suggest a thread with "benefits of 
ASCII" in the subject line, but this thread will probably suffice.

>different than other web-oriented transactions utilizing HTTP?  Others

HTTP is used to transfer a lot of binary material (primarily, 
according to the stats on a small proxy cache I run).  We are 
primarily binary material.

>have not found a need to degenerate to binary encodings, so why should

"degenerate"?  What is the term for that rhetorical technique...

>tools prevalent in today's web-centric environments that span the

Good.  I like that benefit.  I can see how it might be important.

Will those tools deal with precise delimiters in specific
quantities, combined with length-preceded chunks of binary data
which may contain various delimiters (as defined by 6/17)?  And
those same tools are unable to deal with binary encodings?

sdb

---

From: Scott Isaacson <[email-masked]>
Date: Sat, 21 Jun 1997 11:20:18 -0600

I sure agree with Randy:

>>> Randy Turner <[email-masked]> 06/19/97 09:10PM >>>
> 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

---

From: Harry Lewis <[email-masked]>
Date: Mon, 23 Jun 1997 19:47:33 -0400

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 ---------

        [email-masked]
        06/22/97 01:39 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet, [email-masked] @ internet,
[email-masked] @ 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:[email-masked]]
> Sent: Saturday, June 21, 1997 10:20 AM
> To: [email-masked]; [email-masked]
> Subject: Re: IPP>PRO: sorry, binary is better (?)
>
> I sure agree with Randy:
>