> 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