I think that it is an improvement. I hope that you will agree.
We are proposing the addition of a one byte tag in front of each
parameter. With this change, we eliminate the need for the special
negative lengths for both names and values. We also add the ability to
specify the type of parameter/attribute values so that a value can
be decoded and stored independently of the parameter/attribute name. Both
of these seem like positive changes.
The tag serves the following functions:
o it marks the beginning of:
o the parameter section
o any attribute section
o the data section
o it specifies that a parameter/attribute value is a special
'out-of-band' value, e.g. unsupported
o it specifies the type of a parameter/attribute value, e.g. integer.
The rules for encoding and decoding remain nearly the same. The cost
of the 1 extra byte per parameter/attribute is minimal.
This change is explained in detail below by including what the syntax section
would look like if this proposal were approved.
Please email comments to ipp@pwg.org by Friday 7/9 afternoon.
Thanks.
Bob Herriot
The new text for the protocol document follows:
---------------------------------------------------------------
1. Encoding of the Operation Layer
The operation layer SHALL contain a single operation request or
operation response.
The encoding is defined using both a diagram and Augmented Backus-Naur
Form (ABNF), as specified by draft-ietf-drums-abnf-02.txt [29] except
that `strings of literals' SHALL be case sensitive. For example `A'
means upper-case `A' and not lower case `a'. In addition, two-byte
binary signed integer fields are represented as `%x' values which show
their range of values.
All binary integers in this encoding SHALL be transmitted in big-endian
format (also known as 'network order' and 'most significant byte first')
1.1 Syntax of Encoding
The encoding consists of:
. version
. operation (for a request) or status (for a response)
. parameter-tag
. parameter-sequence
. attribute-tag
. attribute-sequence
. data-tag
. data (absent for some operations)
The parameter-sequence consists of a sequence of one or more
parameters. The attributes-sequence consists of a sequence of one or
more attributes. Each parameter or attribute consists of:
. value-tag: a one byte value that specifies the type of the value,
e.g. integer.
. name-length: a two byte binary integer which is the length of the
following `name'
. name
. value-length: a two byte binary integer which is the length of the
following `value'
. value
A name-length of 0 has a special meaning.
The parameter-tag and parameter-sequence may be omitted if the operation
has no parameters. The attribute-tag and attribute-sequence may be
omitted if the operation has no attributes or it may be replicated for
an operation that contains attributes for multiple objects. The data-tag
is present even when the data is omitted.
A name-length of 0 has a special meaning and denotes an additional
value for the preceding parameter or attribute. The following name is
empty. That is, the `value-length' starts in the next octet. A sequence
of parameters or attribures where all but the first have a name-length
of 0 is called a compound-parameter or compound-attribute, respectively.
From the standpoint of a parsing loop, the encoding consists of:
. version
. operation (for a request) or status (for a response)
. zero or more:
. tag
. empty, parameter, or attribute
. data-tag
. data (which is optional)
The value of the tag determines whether the bytes following the tag are:
. parameters
. attributes
. data
. a single parameter where the tag specifies the type of the value.
The syntax for the operation layer below shows the structure created by
the 3 special `name-length' values described above.
ipp-message = ipp-request / ipp-response
ipp-request = version operation parameter-sequence attribute-sequence
DATA-TAG [ data ]
ipp-response = version status parameter-sequence attribute-sequence
DATA-TAG[ data ]
version = major-version minor-version
major-version = SIGNED-BYTE ; initially %d1
minor-version = SIGNED-BYTE ; initially %d0
operation = SIGNED-SHORT ; mapping from model defined below
status = SIGNED-SHORT ; mapping from model defined below
parameter-sequence = [PARAMETER-TAG *compound-parameter]
attribute-sequence = *(ATTRIBUTE-TAG *compound-attribute)
compound-parameter = parameter *(more-values)
parameter = TYPE-TAG name-length name value-length value
compound-attribute = attribute *(more-values)
attribute = TYPE-TAG name-length name value-length value
more-values = TYPE-TAG ZERO-NAME-LENGTH value-length value
name-length = SIGNED-SHORT ; number of octets of `name'
name = LALPHA *( LALPHA / DIGIT / "-" / "_" )
value-length = SIGNED-SHORT ; number of octets of `value'
value = OCTET-STRING
data = OCTET-STRING
ZERO-NAME-LENGTH = %x00 %x00 ; name-length of 0
SIGNED-BYTE = %x0..%x7F
SIGNED-SHORT = %x0.. %x7FFF
DIGIT = "0".."9"
LALPHA = "a".."z"
BYTE = %x0..%xFF
OCTET-STRING = *BYTE
TYPE-TAG = %x10..%xFF
PARAMETER-TAG = %x01 ; TYPE-TAG of 1
ATTRIBUTE-TAG = %x02 ; TYPE-TAG of 2
DATA-TAG = %x03 ; TYPE-TAG of 3
The following table specifies the allocation of values for the tag byte:
Tag Range Meaning
(Hex)
00-0F tags that identify portions of the
encoding, e.g. DATA-TAG
01-1F a parameter/attribute with a special
`out-of-band' value that is
independent of its ordinary type,
e.g. "unsupported". The value-length
SHOULD be 0, and the value empty.
02-3F signed binary integer in big endian
order
04-7F character string
80-FF reserved
The following table specifies actual values for the tag byte:
Tag Value Meaning
(Hex)
00 reserved
01 start of parameters
02 start of attributes
03 start of data
04-0F reserved
10 unsupported
11 default
12-1F reserved
20 unspecified-integer
21 integer
22 boolean
23 seconds
24 milliseconds
25 enum ISSUE, should there be a
separate type for each enum
26-3F reserved
40 unspecified-string
41 text
42 name
43 filename
44 keyword
45 uri
46 uriScheme
47 dateTime
48-7F reserved
ISSUE: should we have unspecified-integer and unspecified-string for
an implementation that doesn't want to be more specific about an
integer or string.
1.2 Diagram of Encoding
The following is a diagram of the encoding of a request and response
operation.
----------------------------------------------
| major version | minor version | 2 bytes
----------------------------------------------
| operation (request) or status (response) | 2 bytes
-----------------------------------------------------------
| 0x01 | 1 byte |
---------------------------------------------- |- optional
| parameter-sequence | k bytes |
-----------------------------------------------------------
| 0x02 | 1 byte |
---------------------------------------------- |- 0 or more
| attribute-sequence | n bytes |
-----------------------------------------------------------
| 0x03 | 1 byte
----------------------------------------------
| data | q bytes - optional
----------------------------------------------
The following is a diagram of the parameter-sequence which is 0 or more
compound-parameters.
----------------------------------------------
| compound-parameter | r bytes - 0 or more
----------------------------------------------
The following is a diagram of the attribute-sequence which is 0 or more
compound-attributes.
----------------------------------------------
| compound-attribute | s bytes - 0 or more
----------------------------------------------
The following is a diagram of a compound-parameter and a a compound-
attribute. The optional fields are present only when a compound-
parameter or compound-attribute has more than one value.
----------------------------------------------
| value-tag | 1 byte
----------------------------------------------
| name-length | 2 bytes
----------------------------------------------
| name | u bytes
----------------------------------------------
| value-length | 2 bytes
----------------------------------------------
| value | v bytes
-----------------------------------------------------------
| value-tag | 1 bytes |
---------------------------------------------- |
| 0x0000 | 2 bytes |
---------------------------------------------- |- 0 or more
| value-length | 2 bytes |
---------------------------------------------- |
| value | w bytes |
-----------------------------------------------------------