tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 8011

 
 
 

Internet Printing Protocol/1.1: Model and Semantics

Part 2 of 12, p. 15 to 29
Prev Section       Next Section

 


prevText      Top      ToC       Page 15 
2.  Conventions Used in This Document

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The key word "DEPRECATED" in this document refers to an operation,
   attribute, or value that SHOULD NOT be used or supported in new
   implementations.

2.2.  Printing Terminology

   Client: Initiator of outgoing IPP session requests and sender of
   outgoing IPP operation requests (Hypertext Transfer Protocol
   (HTTP/1.1) user agent, as defined in [RFC7230]).

   Document: An object created and managed by a Printer that contains
   description, processing, and status information.  A Document object
   can have attached data and is bound to a single Job [PWG5100.5].

   'ipp' URI: An IPP URI as defined in [RFC3510].

   'ipps' URI: An IPP URI as defined in [RFC7472].

   Job: An object created and managed by a Printer that contains
   description, processing, and status information.  The Job also
   contains zero or more Document objects.

   Logical Device: A print server, software service, or gateway that
   processes Jobs and either forwards or stores the processed Job or
   uses one or more Physical Devices to render output.

   Output Device: A single Logical or Physical Device.

   Physical Device: A hardware implementation of an endpoint device,
   e.g., a marking engine, a fax modem, etc.

   Printer: Listener for incoming IPP session requests and receiver of
   incoming IPP operation requests (HTTP/1.1 server, as defined in
   [RFC7230]) that represents one or more Physical Devices or a Logical
   Device.

Top      Up      ToC       Page 16 
2.3.  Model Terminology

2.3.1.  Administrator

   An End User who is also authorized to manage all aspects of an Output
   Device or Printer, including creating the Printer instances and
   controlling the authorization of other End Users and Operators
   [RFC2567].

2.3.2.  Attributes

   An attribute is an item of information that is associated with an
   instance of an IPP object (Printer, Job, etc.).  An attribute
   consists of an attribute name and one or more attribute values.  Each
   attribute has a specific attribute syntax.  All object attributes are
   defined in Section 5, and all operation attributes are defined in
   Section 4.

   Job Template attributes are described in Section 5.2.  The Client
   optionally supplies Job Template attributes in a Job Creation request
   (operation requests that create Job objects).  The Printer object has
   associated attributes that define supported and default values for
   the Printer.

2.3.2.1.  Attribute Group Name

   Related attributes are grouped into named groups.  The name of the
   group is a keyword.  The group name can be used in place of naming
   all the attributes in the group explicitly.  Attribute groups are
   defined in Section 4.

2.3.2.2.  Attribute Name

   Each attribute is uniquely identified in this document by its
   attribute name.  An attribute name is a keyword.  The keyword
   attribute name is given in the section title in this document that
   describes that attribute.  In running text in this document,
   attribute names are indicated inside double quotation marks (") where
   the quotation marks are not part of the keyword itself.

2.3.2.3.  Attribute Syntax

   Each attribute is defined using an explicit syntax type.  In this
   document, each syntax type is defined as a keyword with specific
   meaning.  The "Encoding and Transport" document [RFC8010] indicates
   the actual "on-the-wire" encoding rules for each syntax type.
   Attribute syntax types are defined in Section 5.1.

Top      Up      ToC       Page 17 
2.3.2.4.  Attribute Value

   Each attribute has one or more values.  Attribute values are
   represented in the syntax type specified for that attribute.  In
   running text in this document, attribute values are indicated inside
   single quotation marks ('), whether their attribute syntax is
   keyword, integer, text, etc. where the quotation marks are not part
   of the value itself.

2.3.3.  End User

   An End User is a person or software process that is authorized to
   perform basic printing functions, including finding/locating a
   Printer, creating a local instance of a Printer, viewing Printer
   status, viewing Printer capabilities, submitting a Print Job, viewing
   Print Job status, and altering the attributes of a Print Job
   [RFC2567].

2.3.4.  Impression

   An Impression is the content imposed upon one side of a Media Sheet
   by a marking engine, independent of the number of times that the
   sheet side passes any marker.  An Impression contains one or more
   Input Pages that are imposed (scaled, translated, and/or rotated)
   during processing of the Document data.

2.3.5.  Input Page

   An Input Page is a page according to the definition of "pages" in the
   language used to express the Document data.

2.3.6.  Job Creation Operation

   A Job Creation operation is any operation that causes the creation of
   a Job object, e.g., the Create-Job, Print-Job, and Print-URI
   operations defined in this document.

2.3.7.  Keyword

   Keywords are used within this document as identifiers of semantic
   entities within the abstract model (see Section 5.1.4).  Attribute
   names, some attribute values, attribute syntaxes, and attribute group
   names are represented as keywords.

Top      Up      ToC       Page 18 
2.3.8.  Media Sheet

   A Media Sheet is a single instance of a medium, whether printing on
   one or both sides of the medium.  Media Sheets also include sections
   of roll media.

2.3.9.  Operator

   An Operator is an End User that also has special rights on the Output
   Device or Printer.  The Operator typically monitors the status of the
   Printer and also manages and controls the Jobs at the Output Device
   [RFC2567].  The Operator is allowed to query and control the Printer,
   Jobs, and Documents based on site policy.

2.3.10.  Set

   A Set is a logical boundary between the delivered Media Sheets of a
   printed Job.  For example, in the case of a ten-page single Document
   with collated pages and a request for 50 copies, each of the 50
   printed copies of the Document constitutes a Set.  If the pages were
   uncollated, then 50 copies of each of the individual pages within the
   Document would represent each Set.  Finishing processes operate on
   Sets.

2.3.11.  Support of Attributes

   By definition, a Printer supports an attribute only if that Printer
   accepts it in a request or responds with the corresponding attribute
   populated with some value(s) in a response to a query for that
   attribute.  A Printer supports an attribute value if the value is one
   of the Printer's "supported values" attributes.  The device behind a
   Printer can exhibit a behavior that corresponds to some IPP
   attribute, but if the Printer, when queried for that attribute,
   doesn't respond with the attribute, then as far as IPP is concerned,
   that implementation does not support that feature.  If the Printer's
   "xxx-supported" attribute is not populated with a particular value
   (even if that value is a legal value for that attribute), then that
   Printer does not support that particular value.

   A conforming implementation supports all REQUIRED attributes.
   However, even for REQUIRED attributes, conformance to IPP does not
   mandate that all implementations support all possible values
   representing all possible Job processing behaviors and features.  For
   example, if a given instance of a Printer supports only certain
   Document formats, then that Printer responds with the
   "document-format-supported" attribute populated with a set of values,
   or possibly only one value, taken from the entire set of possible
   values defined for that attribute.  This limited set of values

Top      Up      ToC       Page 19 
   represents the Printer's set of supported Document formats.
   Supporting an attribute and some set of values for that attribute
   enables IPP End Users to be aware of and make use of those features
   associated with that attribute and those values.  If an
   implementation chooses to not support an attribute or some specific
   value, then IPP End Users would have no ability to make use of that
   feature within the context of IPP itself.  However, due to existing
   practice and legacy systems that are not IPP aware, there might be
   some other mechanism outside the scope of IPP to control or request
   the "unsupported" feature (such as embedded instructions within the
   Document data itself).

   For example, consider the following for the "finishings-supported"
   attribute.

   1)  If a Printer is not physically capable of stapling, the
       "finishings-supported" attribute MUST NOT be populated with the
       value of 'staple'.

   2)  A Printer is physically capable of stapling; however, an
       implementation chooses not to support stapling in the IPP
       "finishings" attribute.  In this case, 'staple' MUST NOT be a
       value in the "finishings-supported" Printer Description
       attribute.  Without support for the value 'staple', an IPP
       End User would have no means within the protocol itself to
       request that a Job be stapled.  However, an existing Document
       data formatter might be able to request that the Document be
       stapled directly with an embedded instruction within the Document
       data.  In this case, the IPP implementation does not "support"
       stapling; however, the End User is still able to have some
       control over the stapling of the completed Job.

   3)  A Printer is physically capable of stapling, and an
       implementation chooses to support stapling in the IPP
       "finishings" attribute.  In this case, 'staple' MUST be a value
       in the "finishings-supported" Printer attribute.  Doing so
       enables End Users to be aware of and make use of the stapling
       feature using IPP attributes.

   Even though support for Job Template attributes by a Printer is
   OPTIONAL in IPP/1.1, Printers whose associated device(s) is capable
   of realizing any feature or function that corresponds to an IPP
   attribute and some associated value SHOULD support that IPP attribute
   and value.

Top      Up      ToC       Page 20 
   The set of values in any of the supported value attributes is set
   (populated) by some administrative process or automatic sensing
   mechanism that is outside the scope of this document.  For
   administrative policy and control reasons, an Administrator can
   choose to make only a subset of possible values visible to the
   End User.  In this case, the real Output Device behind the IPP
   Printer abstraction can be capable of a certain feature; however, an
   Administrator is specifying that access to that feature not be
   exposed to the End User through IPP.  Also, since a Printer can
   represent a logical print device (not just a Physical Device), the
   actual process for supporting a value is undefined and left up to the
   implementation.  However, if a Printer supports a value, some manual
   human action might be needed to realize the semantic action
   associated with the value, but no End User action is required.

   For example, if one of the values in the "finishings-supported"
   attribute is 'staple', the actual process might be an automatic
   staple action by a Physical Device controlled by some command sent to
   the device.  Or, the actual process of stapling might be a manual
   action by an Operator at an Operator-attended Printer.

   For another example of how supported attributes function, consider an
   Administrator who desires to control all Print Jobs so that no Job
   sheets are printed in order to conserve paper.  To force no Job
   sheets, the Administrator sets the only supported value for the
   "job-sheets-supported" attribute to 'none'.  In this case, if a
   Client requests anything except 'none', the Job Creation request is
   rejected or the "job-sheets" value is ignored (depending on the value
   of "ipp-attribute-fidelity").  To force the use of Job start/end
   sheets on all Jobs, the Administrator does not include the value
   'none' in the "job-sheets-supported" attribute.  In this case, if a
   Client requests 'none', the Job Creation request is rejected or the
   "job-sheets" value is ignored (again depending on the value of
   "ipp-attribute-fidelity").

   Job Template attributes will typically have corresponding
   "xxx-supported" and "xxx-default" Printer Description attributes that
   contain the supported and default values for the attribute.  For
   capabilities that are not associated with a Job, the convention is to
   have an "xxx-supported" Printer Description attribute that lists the
   supported values and an "xxx-configured" Printer Description
   attribute that contains the value being used by the Printer.  For
   example, the "charset-supported" Printer Description attribute
   (Section 5.4.18) lists the supported character sets for the Printer
   while the "charset-configured" Printer Description attribute
   (Section 5.4.17) specifies the character set being used by the
   Printer.

Top      Up      ToC       Page 21 
2.3.12.  Terminating State

   The final state for a Job or other object is called its Terminating
   State.  For example, the 'aborted', 'canceled', and 'completed' Job
   states are Terminating States.

2.4.  Abbreviations

   ABNF: Augmented Backus-Naur Form [RFC5234]

   ASCII: American Standard Code for Information Interchange [RFC20]

   HTTP: Hypertext Transfer Protocol [RFC7230]

   HTTPS: HTTP over TLS [RFC2818]

   IANA: Internet Assigned Numbers Authority

   IEEE: Institute of Electrical and Electronics Engineers

   IESG: Internet Engineering Steering Group

   IPP: Internet Printing Protocol (this document, [RFC8010], and
   [PWG5100.12])

   ISTO: IEEE Industry Standards and Technology Organization

   LPD: Line Printer Daemon Protocol [RFC1179]

   PWG: IEEE-ISTO Printer Working Group

   RFC: Request for Comments

   TCP: Transmission Control Protocol [RFC793]

   TLS: Transport Layer Security [RFC5246]

   URI: Uniform Resource Identifier [RFC3986]

   URL: Uniform Resource Locator [RFC3986]

   UTF-8: Unicode Transformation Format - 8-bit [RFC3629]

Top      Up      ToC       Page 22 
3.  IPP Objects

   This document defines IPP objects of types Printer and Job.  Each
   type of object models relevant aspects of a real-world entity such as
   a real Printer or real Print Job.  Each object type is defined as a
   set of possible attributes that can be supported by instances of that
   object type.  For each object (instance), the actual set of supported
   attributes and values describe a specific implementation.  The
   object's attributes and values describe its state, capabilities,
   realizable features, Job processing functions, and default behaviors
   and characteristics.  For example, the Printer object type is defined
   as a set of attributes that each Printer object potentially supports.
   In the same manner, the Job object type is defined as a set of
   attributes that are potentially supported by each Job object.

   Each attribute included in the set of attributes defining an object
   type is labeled as:

   o  "REQUIRED": each object MUST support the attribute.

   o  "RECOMMENDED": each object SHOULD support the attribute.

   o  "OPTIONAL": each object MAY support the attribute.

   Some definitions of attribute values indicate that an object MUST or
   SHOULD support the value; otherwise, support of the value is
   OPTIONAL.  However, if an implementation supports an attribute, it
   MUST support at least one of the possible values for that attribute.

3.1.  Printer Object

   The major component of the IPP Model is the Printer object.  A
   Printer object implements the server side of the IPP/1.1 protocol.
   Using the protocol, End Users can query the attributes of the Printer
   object and submit Print Jobs to the Printer object.  The actual
   implementation components behind the Printer abstraction can take on
   different forms and different configurations.  However, the model
   abstraction allows the details of the configuration of real
   components to remain opaque to the End User.  Section 4 describes
   each of the Printer operations in detail.

Top      Up      ToC       Page 23 
   The capabilities and state of a Printer object are described by its
   attributes.  Printer attributes are divided into two groups:

   o  "job-template" attributes: These attributes describe supported Job
      processing capabilities and defaults for the Printer object (see
      Section 5.2)

   o  "printer-description" attributes: These attributes describe the
      Printer's identification, state, location, references to other
      sources of information about the Printer object, etc. (see
      Section 5.4)

   Since a Printer object is an abstraction of a generic Document Output
   Device and print service provider, a Printer object could be used to
   represent any real or virtual device with semantics consistent with
   the Printer object, such as a fax device, an imager, or even a CD
   writer.

   Some examples of configurations supporting a Printer object include:

   1.  An Output Device with no spooling capabilities

   2.  An Output Device with a built-in spooler

   3.  A print server supporting IPP with one or more associated Output
       Devices

       3a.  The associated Output Devices are or are not capable of
            spooling Jobs

       3b.  The associated Output Devices possibly support IPP

   Figure 2 shows some examples of how Printers can be realized on top
   of various distributed printing configurations.  The embedded case
   below represents configurations 1 and 2 above.  The "hosted Printer"
   and "fan out" items represent configurations 3a and 3b, respectively.

   In this document, the term "Client" refers to a software entity that
   sends IPP operation requests to an IPP Printer and accepts IPP
   operation responses.  A Client MAY be:

   1.  contained within software controlled by an End User, e.g.,
       activated by the "Print" menu item in an application, or

   2.  the print server component that sends IPP requests to either an
       Output Device or another "downstream" print server.

Top      Up      ToC       Page 24 
   The term "IPP Printer" is a network entity that accepts IPP operation
   requests and returns IPP operation responses.  As such, an IPP
   Printer object MAY be:

   1.  an (embedded) device component that accepts IPP requests and
       controls the device, or

   2.  a component of a print server that accepts IPP requests (where
       the print server controls one or more networked devices using IPP
       or other protocols).

   Legend:

   ##### indicates a Printer object that is
         either embedded in an Output Device or
         hosted in a server.  The Printer object
         might or might not be capable of queuing/spooling.

   any   indicates any network protocol or direct
         connect, including IPP

   embedded Printer:
                                             Output Device
                                           +---------------+
    O   +--------+                         |  ###########  |
   /|\  | Client |------------IPP------------># Printer #  |
   / \  +--------+                         |  # Object  #  |
                                           |  ###########  |
                                           +---------------+
   hosted Printer:
                                           +---------------+
    O   +--------+        ###########      |               |
   /|\  | Client |--IPP--># Printer #-any->| Output Device |
   / \  +--------+        # Object  #      |               |
                          ###########      +---------------+
                                            +---------------+
   fan out:                                 |               |
                                        +-->| Output Device |
                                    any/    |               |
    O   +--------+      ###########   /     +---------------+
   /|\  | Client |-IPP-># Printer #--*
   / \  +--------+      # Object  #   \     +---------------+
                        ########### any\    |               |
                                        +-->| Output Device |
                                            |               |
                                            +---------------+

                 Figure 2: IPP Printer Object Architecture

Top      Up      ToC       Page 25 
3.2.  Job Object

   A Job object is used to model a Print Job.  A Job object contains
   zero or more Documents.  The information required to create a Job
   object is sent in a Job Creation request from the End User via an IPP
   Client to the Printer.  The Printer validates the Job Creation
   request, and if the Printer accepts the request, the Printer creates
   the new Job object.  Section 4 describes each of the Job operations
   in detail.

   The characteristics and state of a Job object are described by its
   attributes.  Job attributes are grouped into two groups as follows:

   o  "job-template" attributes: These attributes can be supplied by the
      Client or End User and include Job processing instructions that
      are intended to override any Printer defaults and/or instructions
      embedded within the Document data (see Section 5.2)

   o  "job-description" attributes: These attributes describe the Job's
      identification, state, size, etc.  The Client supplies some of
      these attributes, and the Printer generates others (see
      Section 5.3)

   An implementation MUST support at least one Document per Job object.
   An implementation MAY support multiple Documents per Job object.  A
   Document is either:

   o  a stream of Document data in a format supported by the Printer
      (typically a Page Description Language -- PDL), or

   o  a reference to such a stream of Document data.

   All Job processing instructions are modeled as Job object attributes.
   These attributes are called "Job Template attributes", and they apply
   equally to all Documents within a Job object.

3.3.  Object Relationships

   IPP objects have relationships that are maintained persistently along
   with the persistent storage of the object attributes.

   A Printer object can represent either one or more physical Output
   Devices or a Logical Device that "processes" Jobs but never actually
   uses a physical Output Device to put marks on paper.  Examples of
   Logical Devices include a web page publisher or a gateway into an
   online Document archive or repository.  A Printer contains zero or
   more Job objects.

Top      Up      ToC       Page 26 
   A Job object is contained by exactly one Printer; however, the
   identical Document data associated with a Job could be sent to either
   the same or a different Printer.  In this case, a second Job object
   would be created that would be almost identical to the first Job;
   however, it would have new (different) Job object identifiers (see
   Section 3.4).

   A Job either is empty (before any Documents have been added) or
   contains one or more Documents.  If the contained Document is a
   stream of Document data, that stream can be contained in only one
   Document.  However, there can be identical copies of the stream in
   other Documents in the same or different Jobs.  If the contained
   Document is just a reference to a stream of Document data, other
   Documents (in the same or different Job(s)) contain the same
   reference.

3.4.  Object Identity

   All IPP objects (Printers, Jobs, etc.) are identified by a Uniform
   Resource Identifier (URI) [RFC3986] so that they can be persistently
   and unambiguously referenced.  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.

   An Administrator configures Printers to either support or not support
   authentication and/or message privacy using Transport Layer Security
   (TLS) [RFC5246]; the mechanism for security configuration is outside
   the scope of this document.  In some situations, both types of
   connections (both authenticated and unauthenticated) can be
   established using a single communication channel that has some sort
   of negotiation mechanism.  In other situations, multiple
   communication channels are used, one for each type of security
   configuration.  Section 9 provides a full description of all security
   considerations and configurations.

   If a Printer supports more than one communication channel, some or
   all of those channels might support and/or require different security
   mechanisms.  In such cases, an Administrator could expose the
   simultaneous support for these multiple communication channels as
   multiple URIs for a single Printer where each URI represents one of
   the communication channels to the Printer.  To support this
   flexibility, the IPP Printer object type defines a multi-valued
   identification attribute called the "printer-uri-supported" attribute
   that MUST contain at least one URI.  The "printer-uri-supported"
   attribute has two companion attributes, the "uri-security-supported"
   attribute and the "uri-authentication-supported" attribute.  Both
   have the same cardinality as "printer-uri-supported".  The purpose of

Top      Up      ToC       Page 27 
   the "uri-security-supported" attribute is to indicate the security
   mechanisms (if any) used for each URI listed in
   "printer-uri-supported".  The purpose of the
   "uri-authentication-supported" attribute is to indicate the
   authentication mechanisms (if any) used for each URI listed in
   "printer-uri-supported".  These three attributes are fully described
   in Sections 5.4.1, 5.4.2, and 5.4.3.

   When a Job is submitted to the Printer via a Job Creation request,
   the Client supplies only a single Printer URI.  The Client-supplied
   Printer URI MUST be one of the values in the "printer-uri-supported"
   Printer attribute.

   IPP/1.1 does not specify how the Client obtains the Client-supplied
   URI, but it is RECOMMENDED that a Printer be registered as an entry
   in a directory service.  End Users and programs can then interrogate
   the directory, searching for Printers.  Appendix D defines a generic
   schema for Printer object entries in the directory service and
   describes how the entry acts as a bridge to the actual IPP Printer.
   The entry in the directory that represents the IPP Printer includes
   the possibly many URIs for that Printer as values in one of its
   attributes.

   When a Client submits a Job Creation request to the Printer, the
   Printer validates the request and creates a new Job object.  The
   Printer assigns the new Job a numeric identifier that is stored in
   the "job-id" Job attribute and a URI that is stored in the "job-uri"
   Job attribute.  Both the numeric identifier and URI can then be used
   by Clients as the target for subsequent Job operations; the numeric
   identifier is preferred.  The Printer generates the Job numeric
   identifier and URI based on its configured security policy and the
   URI used by the Client in the Job Creation request.

   For example, consider a Printer that supports both a communication
   channel secured by the use of TLS (using HTTP over TLS with an
   "https" schemed URI) and another open communication channel that is
   not secured with TLS (using a simple "http" schemed URI).  If a
   Client submits a Job using the secure URI, the Printer assigns the
   new Job a secure URI as well.  If a Client were to submit a Job using
   the open-channel URI, the Printer might assign the new Job an
   open-channel URI.  Clients SHOULD use the "printer-uri" and "job-id"
   attributes to target a Job to avoid any ambiguity about the security
   of the communication channel.

   In addition, the Printer also populates the Job's "job-printer-uri"
   attribute.  This is a reference back to the Printer that created the
   Job.  If a Client only has access to a Job's "job-uri" identifier,
   the Client can query the Job's "job-printer-uri" attribute in order

Top      Up      ToC       Page 28 
   to determine which Printer created the Job.  If the Printer supports
   more than one URI, the Printer picks the one URI supplied by the
   Client when creating the Job to build the value for and to populate
   the Job's "job-printer-uri" attribute.

   In addition to identifiers, IPP objects have names -- "printer-name"
   for Printers and "job-name" for Jobs.  An object name is not
   guaranteed to be unique across all instances of all objects.  A
   Printer's name is chosen and set by an Administrator through some
   mechanism outside the scope of this document.  A Job's name can be
   chosen and supplied by the Client submitting the Job.  If the Client
   does not supply a Job name, the Printer generates a name for the new
   Job.  In all cases, the name only has local meaning.

   To summarize:

   o  Each Printer is identified by one or more URIs.  The Printer's
      "printer-uri-supported" attribute contains the URI(s).

   o  The Printer's "uri-security-supported" attribute identifies the
      communication channel security protocols that have been configured
      for the various Printer URIs (e.g., 'tls' or 'none').

   o  The Printer's "uri-authentication-supported" attribute identifies
      the authentication mechanisms that have been configured for the
      various Printer URIs (e.g., 'digest', 'none', etc.).

   o  Each Job is identified by a numeric identifier, which is a 32-bit
      positive integer.  The Job's "job-id" attribute contains the
      Job ID.  The Job ID is only unique within the context of the
      Printer that created the Job.

   o  Each Job is also identified by a URI.  The Job's "job-uri"
      attribute contains the URI, although its use by Clients is
      DEPRECATED.

   o  Each Job has a "job-printer-uri" attribute, which contains the URI
      of the Printer that was used to create the Job.  This attribute is
      used to determine the Printer that created a Job when given only
      the URI for the Job.  This linkage is necessary to determine the
      languages, charsets, and operations that are supported on that Job
      (the basis for such support comes from the creating Printer).

   o  Each Printer has a name, which is not necessarily unique.  The
      Administrator chooses and sets this name through some mechanism
      outside the scope of this IPP/1.1 document.  The Printer's
      "printer-name" attribute contains the name.

Top      Up      ToC       Page 29 
   o  Each Job has a name, which is not necessarily unique.  The Client
      optionally supplies this name in the Job Creation request.  If the
      Client does not supply this name, the Printer generates a name for
      the Job.  The Job's "job-name" attribute contains the name.



(page 29 continued on part 3)

Next Section