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 <rturner at sharplabs.com> 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