Subject: Re: IPP> Protocol Specification Language -Reply

From: Randy Turner <[email-masked]>
Date: Mon, 14 Apr 1997 23:03:17 -0700

If the WG agrees that an ASCII representation of the protocol is what
we want (and it sounds like this is the leaning...) then thats ok with
me
too. One interesting thing that using augmented BNF and ASCII encodings
implies is that the rationale for using something other than an
"HTTP-lite"
for an IPP transport tends to dwindle somewhat. Up to now, most of
the rationale I have heard with regards to the rejection of HTTP, was
the fact that if we used our own protocol directly over TCP, that we
could use a more optimized encapsulation.

If we indeed use 7-bit ASCII to encode IPP, and utilize MIME messaging,
then the fact that we use HTTP-lite as a transport really shouldn't
matter
much. Notice that in my references to transport I am now using the term
HTTP-lite, since saying that we are using HTTP as a transport implies
that we require the implementation of the entire HTTP 1.1 spec, per
comments at the IETF in Memphis.

I will issue some kind of short draft outlining the specifics of HTTP
1.1
that we use in our prototype here at Sharp. Other folks doing
prototyping are free to add their own requirements to this document
as well so we get an idea of just how much HTTP we need to function
as an IPP transport. We could even post the combined document as
an internet-draft to get some kind of overall industry comment on what
a compliant "HTTP-lite" implementation would require.

Randy

Scott A. Isaacson wrote:

> >>> Randy Turner <[email-masked]> 04/13/97 03:04pm >>>
>
> > One problem I had with doing this was that we were talking about
> > formalizing data types within the model document. If we stay away
> > from endian-ness and bit-lengths of data types, then I think we
> could
> >  just use BNF. In other words, the more formal we get with regards
> to
> >  the model document and data types, the more we need a formal way
> >  to express the core IPP protocol in a strict, unambigous manner.
>
> We have tried to formalize the "abstract data types" in the model
> document, but ever since we gave up on using a more robust RPC
> mechanism for a much simpler solution, I had assumed we would
> be doing an 7 bit ASCII encoding where we do not have to worry
> about the "bit lengths" or "endian-ness" of data.  An integer in the
>
> IPP model document encodes as a ASCII digit string.  We have no
> bit fields.  Keywords are simple strings etc.  We do not need ASN.1
> either for a descriptive syntax or BER encoding rules.  The
> augmented
> BNF as used by most other RFCs seems fine to me.  I plan on the
> protocol specification having the "formal" rules for data encodings
> on the wire.
>
> Scott

---

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 15 Apr 1997 08:33:16 -0400

>>>>> "RT" == Randy Turner <[email-masked]> writes:

RT> If the WG agrees that an ASCII representation of the protocol is what
RT> we want (and it sounds like this is the leaning...) then thats ok with
RT> me too.
RT> ...
RT> Notice that in my references to transport I am now using the term
RT> HTTP-lite, since saying that we are using HTTP as a transport implies
RT> that we require the implementation of the entire HTTP 1.1 spec, per
RT> comments at the IETF in Memphis.

  As was pointed out in Memphis, the HTTP/1.1 (rfc 2068) spec already
  does a pretty good job of defining such a subset, they just don't
  label it as HTTP-lite :-).  What you want is the subset of things
  that are required of origin servers.  A great deal of the spec
  applies only to proxies and clients.  Our embeddable 1.1 origin
  server implementation is under 30K of code.

  There are ample hooks in the various headers for adding any
  extentions that you discover you need (I'll be suprised if there are
  very many).

--
Scott Lawrence         EmWeb Embedded Server         <[email-masked]>
Agranat Systems, Inc.      Engineering              http://www.agranat.com/