of values and attribute groups. Attribute groups consist of a
   sequence of attributes each of which is a name and value.  Names and
   values are ultimately sequences of octets

   The encoding consists of octets as the most primitive type. There are
   several types built from octets, but three important types are
   integers, character strings and octet strings, on which most other
   data types are built. Every character string in this encoding MUST be
   a sequence of characters where the characters are associated with
   some charset and some natural language. A character string MUST be in
   "reading order" with the first character in the value (according to
   reading order) being the first character in the encoding. A character
   string whose associated charset is US-ASCII whose associated natural
   language is US English is henceforth called a US-ASCII-STRING. A
   character string whose associated charset and natural language are
   specified in a request or response as described in the model document
   is henceforth called a LOCALIZED-STRING. An octet string MUST be in
   "IPP model document order" with the first octet in the value
   (according to the IPP model document order) being the first octet in
   the encoding Every integer in this encoding MUST be encoded as a
   signed integer using two's-complement binary encoding with big-endian
   format (also known as "network order" and "most significant byte




 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   first"). The number of octets for an integer MUST be 1, 2 or 4,
   depending on usage in the protocol.  Such one-octet integers,
   henceforth called SIGNED-BYTE, are used for the version-number and
   tag fields. Such two-byte integers, henceforth called SIGNED-SHORT
   are used for the operation-id, status-code and length fields. Four
   byte integers, henceforth called SIGNED-INTEGER, are used for values
   fields and the sequence number.

   The following two sections present the operation layer in two ways

      - informally through pictures and description
      - formally through Augmented Backus-Naur Form (ABNF), as specified
        by RFC 2234 [RFC2234]

3.1 Picture of the Encoding

   The encoding for an operation request or response consists of:

  -----------------------------------------------
  |                  version-number             |   2 bytes  - required
  -----------------------------------------------
  |               operation-id (request)        |
  |                      or                     |   2 bytes  - required
  |               status-code (response)        |
  -----------------------------------------------
  |                   request-id                |   4 bytes  - required
  -----------------------------------------------------------
  |               xxx-attributes-tag            |   1 byte  |
  -----------------------------------------------           |-0 or more
  |             xxx-attribute-sequence          |   n bytes |
  -----------------------------------------------------------
  |              end-of-attributes-tag          |   1 byte   - required
  -----------------------------------------------
  |                     data                    |   q bytes  - optional
  -----------------------------------------------

   The xxx-attributes-tag and xxx-attribute-sequence represents four
   different values of "xxx", namely, operation, job, printer and
   unsupported. The xxx-attributes-tag and an xxx-attribute-sequence
   represent attribute groups in the model document. The xxx-
   attributes-tag identifies the attribute group and the xxx-attribute-
   sequence contains the attributes.

   The expected sequence of  xxx-attributes-tag and xxx-attribute-
   sequence is specified in the IPP model document for each operation
   request and operation response.






 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   A request or response SHOULD contain each xxx-attributes-tag defined
   for that request or response even if there are no attributes except
   for the unsupported-attributes-tag which SHOULD be present only if
   the unsupported-attribute-sequence is non-empty. A receiver of a
   request MUST be able to process as equivalent empty attribute groups:

     a) an xxx-attributes-tag with an empty xxx-attribute-sequence,
     b) an expected but missing xxx-attributes-tag.

   The data is omitted from some operations, but the end-of-attributes-
   tag is present even when the data is omitted. Note, the xxx-
   attributes-tags and end-of-attributes-tag are called 'delimiter-
   tags'. Note: the xxx-attribute-sequence, shown above may consist of 0
   bytes, according to the rule below.