used by the HTTP server to route the HTTP request to the
         correct resource relative to that HTTP server.  The HTTP server
         need not be aware of the URI within the operation request.
      4. Once the HTTP server resource begins to process the HTTP
         request, it might get the reference to the appropriate IPP
         Printer object from either the HTTP URI (using to the context
         of the HTTP server for relative URLs) or from the URI within
         the operation request; the choice is up to the implementation.
      5. HTTP URIs can be relative or absolute, but the target URI in
         the operation MUST be an absolute URI.

   The model document arranges the remaining attributes into groups for
   each operation request and response. Each such group MUST be
   represented in the protocol by an xxx-attribute-sequence preceded by
   the appropriate xxx-attributes-tag (See the table below and section 9
   "Appendix A:  Protocol Examples"). In addition, the order of these
   xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST
   be the same as in the model document, but the order of attributes
   within each xxx-attribute-sequence MUST be unspecified. The table
   below maps the model document group name to xxx-attributes-sequence:

   Model Document Group           xxx-attributes-sequence

   Operation Attributes           operations-attributes-sequence
   Job Template Attributes        job-attributes-sequence
   Job Object Attributes          job-attributes-sequence
   Unsupported Attributes         unsupported-attributes-sequence
   Requested Attributes           job-attributes-sequence
   Get-Job-Attributes)
   Requested Attributes           printer-attributes-sequence
   Get-Printer-Attributes)
   Document Content               in a special position as described
                                  above

   If an operation contains attributes from more than one job object
   (e.g.  Get-Jobs response), the attributes from each job object MUST
   be in a separate job-attribute-sequence, such that the attributes





 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   from the ith job object are in the ith job-attribute-sequence. See
   Section 9 "Appendix A: Protocol Examples" for table showing the
   application of the rules above.

3.10 Value Length

   Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST
   specify the number of octets in the value which follows this length,
   exclusive of the two bytes specifying the length.

   For any of the types represented by binary signed integers, the
   sender MUST encode the value in exactly four octets.

   For any of the types represented by character-strings, the sender
   MUST encode the value with all the characters of the string and
   without any padding characters.

   If a value-tag contains an "out-of-band" value, such as
   "unsupported", the value-length MUST be 0 and the value empty. The
   value has no meaning when the value-tag has an "out-of-band" value.
   If a client receives a response with a nonzero value-length in this
   case, it MUST ignore the value field. If a printer receives a request
   with a nonzero value-length in this case, it MUST reject the request.

3.11 (Attribute) Value

   The syntax types and most of the details of their representation are
   defined in the IPP model document. The table below augments the
   information in the model document, and defines the syntax types from
   the model document in terms of the 5 basic types defined in section 3
   "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING,
   LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and
   OCTET-STRING.

Syntax of Attribute  Encoding
Value

textWithoutLanguage, LOCALIZED-STRING.
nameWithoutLanguage

textWithLanguage     OCTET_STRING consisting of 4 fields:
                       a) a SIGNED-SHORT which is the number of octets
                          in the following field
                       b) a value of type natural-language,
                       c) a SIGNED-SHORT which is the number of octets
                          in the following field,
                       d) a value of type textWithoutLanguage.





 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999