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

From: Paul Moore <[email-masked]>
Date: Sun, 22 Jun 1997 12:27:18 -0700

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:
> 
> >>> Randy Turner <[email-masked]> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Larry Masinter <[email-masked]>
Date: Mon, 23 Jun 1997 17:31:37 PDT

> copies just so long as we (the implementors) all agree. 

One of the things that is affected by this choice is the extension
mechanism. Suppose I want to try out a new feature. I'll do it
privately, and then I want to register it and make it public. If
I just pick a number, '43', I'm likely to hit someone else's number.
So maybe I'll use a number out of the private extension space, e.g.,
'123451'. But then when I change from 'private extension' to 
'public', I have to go back and recompile all my test code.

With strings, I can pick a string that isn't used by anyone now,
and most likely won't have to change it by the time I register it.

This sounds pretty sloppy, but it's mainly what's done now for
many protocols and it's much more robust than numbers.

The protocol strings aren't human-language, they're just close enough to
language to believe that they're extensible in a more distributed
fashion.

In addition, the debugging and testing aspects shouldn't be ignored;
it's useful to be able to write a test program in a scripting language
or even to telnet to port 80 at a host and just type "GET url HTTP/1.0"
without having to count bytes.

Larry

-- 
http://www.parc.xerox.com/masinter