value that the parser treats atomically.  All these 4 byte tag values
   are currently unallocated except that the values 0x40000000-
   0x7FFFFFFF are reserved for experimental use.

3.8 Name-Length

   The name-length field MUST consist of a SIGNED-SHORT. This field MUST
   specify the number of octets in the name field which follows the
   name-length field, excluding the two bytes of the name-length field.

   If a name-length field has a value of zero, the following name field
   MUST be empty, and the following value MUST be treated as an
   additional value for the preceding attribute. Within an attribute-
   sequence, if two attributes have the same name, the first occurrence
   MUST be ignored. The zero-length name is the only mechanism for
   multi-valued attributes.

3.9 (Attribute) Name

   Some operation elements are called parameters in the model document
   [RFC2566]. They MUST be encoded in a special position and they MUST
   NOT appear as an operation attributes.  These parameters are:

      - "version-number": The parameter  named "version-number" in the
        IPP model document MUST become the "version-number" field in the
        operation layer request or response.




 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


      - "operation-id": The parameter named "operation-id" in the IPP
        model document MUST become the "operation-id" field in the
        operation layer request.
      - "status-code": The parameter named "status-code" in the IPP
        model document MUST become the "status-code" field in the
        operation layer response.
      - "request-id": The parameter named "request-id" in the IPP model
        document MUST become the "request-id" field in the operation
        layer request or response.

   All Printer and Job objects are identified by a Uniform Resource
   Identifier (URI) [RFC2396] so that they can be persistently and
   unambiguously referenced.  The notion of a URI is a useful concept,
   however, until the notion of URI is more stable (i.e.,  defined more
   completely and deployed more widely), it is expected that the URIs
   used for IPP objects will actually be URLs [RFC1738]  [RFC1808].
   Since every URL is a specialized form of a URI, even though the more
   generic term URI is used throughout the rest of this document, its
   usage is intended to cover the more specific notion of URL as well.

   Some operation elements are encoded twice, once as the request-URI on
   the HTTP Request-Line and a second time as a REQUIRED operation
   attribute in the application/ipp entity.  These attributes are the
   target URI for the operation:

      - "printer-uri": When the target is a printer and the transport is
        HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined
        in each operation in the IPP model document MUST be an operation
        attribute called "printer-uri" and it MUST also be specified
        outside of  the operation layer as the request-URI on the
        Request-Line at the HTTP level.
      - "job-uri": When the target is a job and the transport is HTTP or
        HTTPS (for SSL3), the target job-uri of each operation in the
        IPP model document MUST be an operation attribute called "job-
        uri" and it MUST also be specified outside of  the operation
        layer as the request-URI on the Request-Line at the HTTP level.

   Note: The target URI is included twice in an operation referencing
   the same IPP object, but the two URIs NEED NOT be literally
   identical. One can be a relative URI and the other can be an absolute
   URI.  HTTP/1.1 allows clients to generate and send a relative URI
   rather than an absolute URI.  A relative URI identifies a resource
   with the scope of the HTTP server, but does not include scheme, host
   or port.  The following statements characterize how URLs should be
   used in the mapping of IPP onto HTTP/1.1:







 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


      1. Although potentially redundant, a client MUST supply the target
         of the operation both as an operation attribute and as a URI at
         the HTTP layer.  The rationale for this decision is to maintain
         a consistent set of rules for mapping application/ipp to
         possibly many communication layers, even where URLs are not
         used as the addressing mechanism in the transport layer.
      2. Even though these two URLs might not be literally identical
         (one being relative and the other being absolute), they MUST
         both reference the same IPP object.
      3. The URI in the HTTP layer is either relative or absolute and is