*(xxx-attributes-tag  xxx-attribute-sequence)
           end-of-attributes-tag data
  ipp-response = version-number status-code request-id
           *(xxx-attributes-tag xxx-attribute-sequence)
           end-of-attributes-tag data
  xxx-attribute-sequence = *compound-attribute

  xxx-attributes-tag = operation-attributes-tag / job-attributes-tag /
        printer-attributes-tag / unsupported-attributes-tag

  version-number = major-version-number minor-version-number
  major-version-number = SIGNED-BYTE  ; initially %d1
  minor-version-number = SIGNED-BYTE  ; initially %d0

  operation-id = SIGNED-SHORT    ; mapping from model defined below
  status-code = SIGNED-SHORT  ; mapping from model defined below
  request-id = SIGNED-INTEGER ; whose value is > 0

  compound-attribute = attribute *additional-values
  attribute = value-tag name-length name value-length value
  additional-values = value-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.00           ; name-length of 0
  operation-attributes-tag =  %x01             ; tag of 1
  job-attributes-tag   =  %x02                 ; tag of 2
  printer-attributes-tag =  %x04               ; tag of 4
  unsupported-attributes-tag =  %x05          ; tag of 5
  end-of-attributes-tag = %x03                 ; tag of 3
  value-tag = %x10-FF

  SIGNED-BYTE = BYTE
  SIGNED-SHORT = 2BYTE
  SIGNED-INTEGER = 4BYTE
  DIGIT = %x30-39    ;  "0" to "9"
  LALPHA = %x61-7A   ;  "a" to "z"
  BYTE = %x00-FF
  OCTET-STRING = *BYTE






 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   The syntax allows an xxx-attributes-tag to be present when the xxx-
   attribute-sequence that follows is empty. The syntax is defined this
   way to allow for the response of Get-Jobs where no attributes are
   returned for some job-objects.  Although it is RECOMMENDED that the
   sender not send an xxx-attributes-tag if there are no attributes
   (except in the Get-Jobs response just mentioned), the receiver MUST
   be able to decode such syntax.

3.3 Version-number

   The version-number MUST consist of a major and minor version-number,
   each of which MUST be represented by a SIGNED-BYTE. The protocol
   described in this document MUST have a major version-number of 1
   (0x01) and a minor version-number of  0 (0x00).  The ABNF for these
   two bytes MUST be %x01.00.

3.4 Operation-id

   Operation-ids are defined as enums in the model document. An
   operation-ids enum value MUST be encoded as a SIGNED-SHORT.

   Note: the values 0x4000 to 0xFFFF are reserved for private
   extensions.

3.5 Status-code

   Status-codes are defined as enums in the model document. A status-
   code enum value MUST be encoded as a SIGNED-SHORT.

   The status-code is an operation attribute in the model document. In
   the protocol, the status-code is in a special position, outside of
   the operation attributes.

   If an IPP status-code is returned, then the HTTP Status-Code MUST be
   200 (successful-ok).  With any other HTTP Status-Code value, the HTTP
   response MUST NOT contain an IPP message-body, and thus no IPP
   status-code is returned.

3.6 Request-id

   The request-id allows a client to match a response with a request.
   This mechanism is unnecessary in HTTP, but may be useful when
   application/ipp entity bodies are used in another context.

   The request-id in a response MUST be the value of the request-id
   received in the corresponding request.  A client can set the