I'd like to propose a change to the IPP encoding that would allow more =
robust
implementations in a world of buggy HTTP implementations. Specifically=
, I
propose adding a magic number at the beginning of the ipp-message:
ipp-message =3D ipp-request / ipp-response
ipp-request =3D magic-number version operation
*(xxx-attributes-tag xxx-attribute-sequence) data-tag data
ipp-response =3D magic-number version status-code
*(xxx-attributes-tag xxx-attribute-sequence) data-tag data=
magic-number =3D %x3f2c59d1 ;Literal 4 byte value to be
;defined by the protocol specification
Why would this be a useful addition to the protocol? Take the example =
of an
IPP client reading a ipp-response. The client can check the beginning =
of the
entity-body for the magic-number. If there is a mismatch, it's not saf=
e to
proceed with parsing the rest of the entity body, and the client should=
raise
some kind of protocol exception. It might be worth scanning a few byte=
s along
in the data stream looking for the magic-number in case a buggy HTTP tr=
ansport
layer has, say, inserted an extra CRLF after the message-header.
This kind of sanity check is difficult to apply to the protocol stream =
as it's
defined today, for example (pulled from the INTERNET-DRAFT IPP/1.0: Pro=
tocol
Specification September 29, 1997):
The following is the beginning of an example of a Print-Job request:
Octets Symbolic Value Protocol field
0x0100 1.0 version
0x0002 PrintJob operation
0x01 start operation- operation-attributes tag
attributes
...
Instead, I'd like to see this:
Octets Symbolic Value Protocol field
0x3f2c59d1 magic-number
0x0100 1.0 version
0x0002 PrintJob operation
0x01 start operation- operation-attributes tag
attributes
...
I've seen this kind of thing done before, for example, in graphics inte=
rchange
formats and various APIs. Unnecessary in theory, but a practical way to=
add
some robustness.
Carl Kugler
IBM
kugler at us.ibm.net
303-924-5060
=