IPP>PRO proposed tweak to protocol

IPP>PRO proposed tweak to protocol

IPP>PRO proposed tweak to protocol

Robert Herriot Robert.Herriot at Eng.Sun.COM
Wed Jul 9 22:32:08 EDT 1997


In today's meeting we decided to propose one last small tweak to the
IPP protocol.  We decided that I would send out this proposal for all
of you to read and comment on.


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 at 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 |
   -----------------------------------------------------------



More information about the Ipp mailing list