Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2566

Internet Printing Protocol/1.0: Model and Semantics

Pages: 173
Obsoleted by:  2911
Part 5 of 7 – Pages 100 to 124
First   Prev   Next

ToP   noToC   RFC2566 - Page 100   prevText
4.4.2 uri-security-supported (1setOf type2 keyword)

   This REQUIRED Printer attribute MUST have the same cardinality
   (contain the same number of values) as the "printer-uri-supported"
   attribute.  This attribute identifies the security mechanisms used
   for each URI listed in the "printer-uri-supported" attribute.  The "i
   th" value in "uri-security-supported" corresponds to the "i th" value
   in "printer-uri-supported" and it describes the security mechanisms
   used for accessing the Printer object via that URI. The following
   standard values are defined:

     'none': There are no secure communication channel protocols in use
        for the given URI.

     'ssl3': SSL3 [SSL] is the secure communications channel protocol in
        use for the given URI.

   Consider the following example.  For a single Printer object, an
   administrator configures the "printer-uri-supported" and "uri-
   security-supported" attributes as follows:

     "printer-uri-supported": 'http://acme.com/open-use-printer', '
        http://acme.com/restricted-use-printer', '
        http://acme.com/private-printer'
     "uri-security-supported": 'none', 'none', 'ssl3'

   In this case, one Printer object has three URIs.

     - For the first URI, 'http://acme.com/open-use-printer', the value
        'none' in "uri-security-supported" indicates that there is no
        secure channel protocol configured to run under HTTP.  The name
        implies that there is no Basic or Digest authentication being
        used, but it is up to the client to determine that while using
        HTTP underneath the IPP application protocol.
     - For the second URI, 'http://acme.com/restricted-use-printer', the
        value 'none' in "uri-security-supported" indicates that there is
        no secure channel protocol configured to run under HTTP.  In
        this case, although the name does imply that there is some sort
        of Basic or Digest authentication being used within HTTP, it is
        up to the client to determine that while using HTTP and by
        processing any '401 Unauthorized' HTTP error messages.
     - For the third URI, 'http://acme.com/private-printer', the value '
        ssl3' in "uri-security-supported" indicates that SSL3 is being
        used to secure the channel.  The client SHOULD be prepared to
        use SSL3 framing to negotiate an acceptable ciphersuite to use
        while communicating with the Printer object.  In this case, the
        name implies the use of a secure communications channel, but the
        fact is made explicit by the presence of the 'ssl3' value in
ToP   noToC   RFC2566 - Page 101
        "uri-security-supported".  The client does not need to resort to
        understanding which security it must use by following naming
        conventions or by parsing the URI to determine which security
        mechanisms are implied.

   It is expected that many IPP Printer objects will be configured to
   support only one channel (either configured to use SSL3 access or
   not), and will therefore only ever have one URI listed in the
   "printer-uri-supported" attribute.  No matter the configuration of
   the Printer object (whether it has only one URI or more than one
   URI), a client MUST supply only one URI in the target "printer-uri"
   operation attribute.

4.4.3 printer-name (name(127))

   This REQUIRED Printer attribute contains the name of the Printer
   object.  It is a name that is more end-user friendly than a URI. An
   administrator determines a printer's name and sets this attribute to
   that name. This name may be the last part of the printer's URI or it
   may be unrelated.  In non-US-English locales, a name may contain
   characters that are not allowed in a URI.

4.4.4 printer-location (text(127))

   This Printer attribute identifies the location of the device. This
   could include things like: "in Room 123A, second floor of building
   XYZ".

4.4.5 printer-info (text(127))

   This Printer attribute identifies the descriptive information about
   this Printer object.  This could include things like: "This printer
   can be used for printing color transparencies for HR presentations",
   or "Out of courtesy for others, please print only small (1-5 page)
   jobs at this printer", or even "This printer is going away on July 1,
   1997, please find a new printer".

4.4.6 printer-more-info (uri)

   This Printer attribute contains a URI used to obtain more information
   about this specific Printer object.  For example, this could be an
   HTTP type URI referencing an HTML page accessible to a Web Browser.
   The information obtained from this URI is intended for end user
   consumption.  Features outside the scope of IPP can be accessed from
   this URI.  The information is intended to be specific to this printer
   instance and site specific services (e.g. job pricing, services
   offered, end user assistance). The device manufacturer may initially
   populate this attribute.
ToP   noToC   RFC2566 - Page 102
4.4.7 printer-driver-installer (uri)

   This Printer attribute contains a URI to use to locate the driver
   installer for this Printer object.   This attribute is intended for
   consumption by automata.  The mechanics of print driver installation
   is outside the scope of IPP.  The device manufacturer may initially
   populate this attribute.

4.4.8 printer-make-and-model (text(127))

   This Printer attribute identifies the make and model of the device.
   The device manufacturer may initially populate this attribute.

4.4.9 printer-more-info-manufacturer (uri)

   This Printer attribute contains a URI used to obtain more information
   about this type of device.  The information obtained from this URI is
   intended for end user consumption.  Features outside the scope of IPP
   can be accessed from this URI (e.g., latest firmware, upgrades, print
   drivers, optional features available, details on color support).  The
   information is intended to be germane to this printer without regard
   to site specific modifications or services. The device manufacturer
   may initially populate this attribute.

4.4.10 printer-state (type1 enum)

   This REQUIRED Printer attribute identifies the current state of the
   device.  The "printer-state reasons" attribute augments the
   "printer-state" attribute to give more detailed information about the
   Printer in the given printer state.

   A Printer object need only update this attribute before responding to
   an operation which requests the attribute; the Printer object NEED
   NOT update this attribute continually, since asynchronous event
   notification is not part of IPP/1.0.  A Printer NEED NOT implement
   all values if they are not applicable to a given implementation.

   The following standard enum values are defined:

     Value  Symbolic Name and Description

     '3'    'idle':  If a Printer receives a job (whose required
                  resources are ready) while in this state, such a job
                  MUST transit into the 'processing' state immediately.
                  If the "printer-state-reasons" attribute contains any
                  reasons, they MUST be reasons that would not prevent a
                  job from transiting into the 'processing' state
                  immediately, e.g., 'toner-low'. Note: if a Printer
ToP   noToC   RFC2566 - Page 103
                  controls more than one output device, the above
                  definition implies that a Printer is 'idle' if at
                  least one output device is idle.

     '4'    'processing':  If a Printer receives a job (whose required
                  resources are ready) while in this state, such a job
                  MUST transit into the 'pending' state immediately.
                  Such a job MUST transit into the 'processing' state
                  only after jobs ahead of it complete.  If the
                  "printer-state-reasons" attribute contains any
                  reasons, they MUST be reasons that do not prevent the
                  current job from printing, e.g.  'toner-low'.  Note:
                  if a Printer controls more than one output device, the
                  above definition implies that a Printer is '
                  processing' if at least one output device is
                  processing, and none is idle.

     '5'    'stopped':  If a Printer receives a job (whose required
                  resources are ready) while in this state, such a job
                  MUST transit into the 'pending' state immediately.
                  Such a job MUST transit into the 'processing' state
                  only after some human fixes the problem that stopped
                  the printer and after jobs ahead of it complete
                  processing.  If supported, the "printer-state-reasons"
                  attribute MUST contain at least one reason, e.g. '
                  media-jam', which prevents it from either processing
                  the current job or transitioning a 'pending' job to
                  the 'processing' state.

                  Note: if a Printer controls more than one output
                  device, the above definition implies that a Printer is
                  'stopped' only if all output devices are stopped.
                  Also, it is tempting to define 'stopped' as when a
                  sufficient number of output devices are stopped and
                  leave it to an implementation to define the sufficient
                  number.  But such a rule complicates the definition of
                  'stopped' and 'processing'. For example, with this
                  alternate definition of 'stopped', a job can move from
                  'pending' to 'processing' without human intervention,
                  even though the Printer is stopped.

4.4.11 printer-state-reasons (1setOf type2 keyword)

   This Printer attribute supplies additional detail about the device's
   state.
ToP   noToC   RFC2566 - Page 104
   Each keyword value MAY have a suffix to indicate its level of
   severity.  The three levels are: report (least severe), warning, and
   error (most severe).

     - '-report':  This suffix indicates that the reason is a "report".
        An implementation may choose to omit some or all reports. Some
        reports specify finer granularity about the printer state;
        others serve as a precursor to a warning. A report MUST contain
        nothing that could affect the printed output.
     - '-warning': This suffix indicates that the reason is a "warning".
        An implementation may choose to omit some or all warnings.
        Warnings serve as a precursor to an error. A warning MUST
        contain nothing that prevents a job from completing, though in
        some cases the output may be of lower quality.
     - '-error': This suffix indicates that the reason is an "error".
        An implementation MUST include all errors. If this attribute
        contains one or more errors, printer MUST be in the stopped
        state.

   If the implementation does not add any one of the three suffixes, all
   parties MUST assume that the reason is an "error".

   If a Printer object controls more than one output device, each value
   of this attribute MAY apply to one or more of the output devices.  An
   error on one output device that does not stop the Printer object as a
   whole MAY appear as a warning in the Printer's "printer-state-reasons
   attribute".  If the "printer-state" for such a Printer has a value of
   'stopped', then there MUST be an error reason among the values in the
   "printer-state-reasons" attribute.

   The following standard keyword values are defined:

     'other': The device has detected an error other than one listed in
        this document.
     'none': There are not reasons. This state reason is semantically
        equivalent to "printer-state-reasons" without any value.
     'media-needed': A tray has run out of media.
     'media-jam': The device has a media jam.
     'paused': Someone has paused the Printer object.  In this state, a
        Printer MUST NOT produce printed output, but it MUST perform
        other operations requested by a client.  If a Printer had been
        printing a job when the Printer was paused, the Printer MUST
        resume printing that job when the Printer is no longer paused
        and leave no evidence in the printed output of such a pause.
     'shutdown': Someone has removed a Printer object from service, and
        the device may be powered down or physically removed.  In this
        state, a Printer object MUST NOT produce printed output, and
        unless the Printer object is realized by a print server that is
ToP   noToC   RFC2566 - Page 105
        still active, the Printer object MUST perform no other
        operations requested by a client, including returning this
        value. If a Printer object had been printing a job when it was
        shutdown, the Printer NEED NOT resume printing that job when the
        Printer is no longer shutdown. If the Printer resumes printing
        such a job, it may leave evidence in the printed output of such
        a shutdown, e.g. the part printed before the shutdown may be
        printed a second time after the shutdown.
     'connecting-to-device': The Printer object has scheduled a job on
        the output device and is in the process of connecting to a
        shared network output device (and might not be able to actually
        start printing the job for an arbitrarily long time depending on
        the usage of the output device by other servers on the network).
     'timed-out': The server was able to connect to the output device
        (or is always connected), but was unable to get a response from
        the output device.
     'stopping': The Printer object is in the process of stopping the
        device and will be stopped in a while. When the device is
        stopped, the Printer object will change the Printer object's
        state to 'stopped'.  The 'stopping-warning' reason is never an
        error, even for a Printer with a single output device.  When an
        output-device ceases accepting jobs, the Printer will have this
        reason while the output device completes printing.
     'stopped-partly': When a Printer object controls more than one
        output device, this reason indicates that one or more output
        devices are stopped.  If the reason is a report, fewer than half
        of the output devices are stopped.  If the reason is a warning,
        fewer than all of the output devices are stopped.
     'toner-low': The device is low on toner.
     'toner-empty': The device is out of toner.
     'spool-area-full': The limit of persistent storage allocated for
        spooling has been reached.
     'cover-open': One or more covers on the device are open.
     'interlock-open': One or more interlock devices on the printer are
        unlocked.
     'door-open': One or more doors on the device are open.
     'input-tray-missing': One or more input trays are not in the
        device.
     'media-low': At least one input tray is low on media.
     'media-empty': At least one input tray is empty.
     'output-tray-missing': One or more output trays are not in the
        device
     'output-area-almost-full': One or more output area is almost full
        (e.g. tray, stacker, collator).
     'output-area-full': One or more output area is full. (e.g. tray,
        stacker, collator)
     'marker-supply-low': The device is low on at least one marker
        supply.  (e.g. toner, ink, ribbon)
ToP   noToC   RFC2566 - Page 106
     'marker-supply-empty: The device is out of at least one marker
        supply. (e.g. toner, ink, ribbon)
     'marker-waste-almost-full': The device marker supply waste
        receptacle is almost full.
     'marker-waste-full': The device marker supply waste receptacle is
        full.
     'fuser-over-temp': The fuser temperature is above normal.
     'fuser-under-temp': The fuser temperature is below normal.
     'opc-near-eol': The optical photo conductor is near end of life.
     'opc-life-over': The optical photo conductor is no longer
        functioning.
     'developer-low': The device is low on developer.
     'developer-empty: The device is out of developer.
     'interpreter-resource-unavailable': An interpreter resource is
        unavailable (i.e. font, form)

4.4.12 printer-state-message (text(MAX))

   This Printer attribute specifies the additional information about the
   printer state and printer state reasons in human readable text.  If
   the Printer object supports this attribute, the Printer object MUST
   be able to generate this message in any of the natural languages
   identified by the Printer's "generated-natural-language-supported"
   attribute (see the "attributes-natural-language" operation attribute
   specified in Section 3.1.4.1).

4.4.13 operations-supported (1setOf type2 enum)

   This REQUIRED Printer attribute specifies the set of supported
   operations for this Printer object and contained Job objects.  All
   32-bit enum values for this attribute MUST NOT exceed 0x8FFF, since
   these values are passed in two octets in each Protocol request
   [RFC2565].

   The following standard enum and "operation-id" (see section 3.1.2)
   values are defined:

     Value               Operation Name
     -----------------   -------------------------------------

     0x0000              reserved, not used
     0x0001              reserved, not used
     0x0002              Print-Job
     0x0003              Print-URI
     0x0004              Validate-Job
     0x0005              Create-Job
     0x0006              Send-Document
     0x0007              Send-URI
ToP   noToC   RFC2566 - Page 107
     0x0008              Cancel-Job
     0x0009              Get-Job-Attributes
     0x000A              Get-Jobs
     0x000B              Get-Printer-Attributes
     0x000C-0x3FFF       reserved for future operations
     0x4000-0x8FFF       reserved for private extensions

   This allows for certain vendors to implement private extensions that
   are guaranteed to not conflict with future registered extensions.
   However, there is no guarantee that two or more private extensions
   will not conflict.

4.4.14 charset-configured (charset)

   This REQUIRED Printer attribute identifies the charset that the
   Printer object has been configured to represent 'text' and 'name'
   Printer attributes that are set by the operator, system
   administrator, or manufacturer, i.e., for "printer-name" (name),
   "printer-location" (text), "printer-info" (text), and "printer-make-
   and-model" (text).  Therefore, the value of the Printer object's
   "charset-configured" attribute MUST also be among the values of the
   Printer object's "charset-supported" attribute.

4.4.15 charset-supported (1setOf charset)

   This REQUIRED Printer attribute identifies the set of charsets that
   the Printer and contained Job objects support in attributes with
   attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST
   be present, since IPP objects MUST support the UTF-8 [RFC2279]
   charset.  If a Printer object supports a charset, it means that for
   all attributes of syntax 'text' and 'name' the IPP object MUST (1)
   accept the charset in requests and return the charset in responses as
   needed.

   If more charsets than UTF-8 are supported, the IPP object MUST
   perform charset conversion between the charsets as described in
   Section 3.2.1.2.

4.4.16 natural-language-configured (naturalLanguage)

   This REQUIRED Printer attribute identifies the natural language that
   the Printer object has been configured to represent 'text' and 'name'
   Printer attributes that are set by the operator, system
   administrator, or manufacturer, i.e., for "printer-name" (name),
   "printer-location" (text), "printer-info" (text), and "printer-make-
   and-model" (text).  When returning these Printer attributes, the
   Printer object MAY return them in the configured natural language
   specified by this attribute, instead of the natural language
ToP   noToC   RFC2566 - Page 108
   requested by the client in the "attributes-natural-language"
   operation attribute.  See Section 3.1.4.1 for the specification of
   the OPTIONAL multiple natural language support.  Therefore, the value
   of the Printer object's "natural-language-configured" attribute MUST
   also be among the values of the Printer object's "generated-natural-
   language-supported" attribute.

4.4.17 generated-natural-language-supported (1setOf naturalLanguage)

   This REQUIRED Printer attribute identifies the natural language(s)
   that the Printer object and contained Job objects support in
   attributes with attribute syntax 'text' and 'name'.  The natural
   language(s) supported depends on implementation and/or configuration.
   Unlike charsets, IPP objects MUST accept requests with any natural
   language or any Natural Language Override whether the natural
   language is supported or not.

   If a Printer object supports a natural language, it means that for
   any of the attributes for which the Printer or Job object generates
   messages, i.e., for the "job-state-message" and "printer-state-
   message" attributes and Operation Messages (see Section 3.1.5) in
   operation responses, the Printer and Job objects MUST be able to
   generate messages in any of the Printer's supported natural
   languages.  See section 3.1.4 for the specification of 'text' and '
   name' attributes in operation requests and responses.

   Note: A Printer object that supports multiple natural languages,
   often has separate catalogs of messages, one for each natural
   language supported.

4.4.18 document-format-default (mimeMediaType)

   This REQUIRED Printer attribute identifies the document format that
   the Printer object has been configured to assume if the client does
   not supply a "document-format" operation attribute in any of the
   operation requests that supply document data.  The standard values
   for this attribute are Internet Media types (sometimes called MIME
   types).  For further details see the description of the '
   mimeMediaType' attribute syntax in Section 4.1.9.

4.4.19 document-format-supported (1setOf mimeMediaType)

   This REQUIRED Printer attribute identifies the set of document
   formats that the Printer object and contained Job objects can
   support. For further details see the description of the '
   mimeMediaType' attribute syntax in Section 4.1.9.

4.4.20 printer-is-accepting-jobs (boolean)
ToP   noToC   RFC2566 - Page 109
   This REQUIRED Printer attribute indicates whether the printer is
   currently able to accept jobs, i.e., is accepting Print-Job, Print-
   URI, and Create-Job requests.  If the value is 'true', the printer is
   accepting jobs.  If the value is 'false', the Printer object is
   currently rejecting any jobs submitted to it.  In this case, the
   Printer object returns the 'server-error-not-accepting-jobs' status
   code.

   Note: This value is independent of the "printer-state" and "printer-
   state-reasons" attributes because its value does not affect the
   current job; rather it affects future jobs.  This attribute may cause
   the Printer to reject jobs when the "printer-state" is 'idle' or it
   may cause the Printer object to accepts jobs when the "printer-state"
   is 'stopped'.

4.4.21 queued-job-count (integer(0:MAX))

   This RECOMMENDED Printer attribute contains a count of the number of
   jobs that are either 'pending', 'processing', 'pending-held', or '
   processing-stopped' and is set by the Printer object.

4.4.22 printer-message-from-operator (text(127))

   This Printer attribute provides a message from an operator, system
   administrator or "intelligent" process to indicate to the end user
   information or status of the printer, such as why it is unavailable
   or when it is expected to be available.

4.4.23 color-supported (boolean)

   This Printer attribute identifies whether the device is capable of
   any type of color printing at all, including highlight color.  All
   document instructions having to do with color are embedded within the
   document PDL (none are external IPP attributes in IPP/1.0).

   Note:  end-users are able to determine the nature and details of the
   color support by querying the "printer-more-info-manufacturer"
   Printer attribute.

4.4.24 reference-uri-schemes-supported (1setOf uriScheme)

   This Printer attribute specifies which URI schemes are supported for
   use in the "document-uri" operation attribute of the Print-URI or
   Send-URI operation.  If a Printer object supports these optional
   operations, it MUST support the "reference-uri-schemes-supported"
   Printer attribute with at least the following schemed URI value:

     'ftp':  The Printer object will use an FTP 'get' operation as
ToP   noToC   RFC2566 - Page 110
        defined in RFC 2228 [RFC2228] using FTP URLs as defined by
        [RFC2396] and[RFC2316].

   The Printer object MAY OPTIONALLY support other URI schemes (see
   section 4.1.6).

4.4.25 pdl-override-supported (type2 keyword)

   This REQUIRED Printer attribute expresses the ability for a
   particular Printer implementation to either attempt to override
   document data instructions with IPP attributes or not.

   This attribute takes on the following values:

     - 'attempted': This value indicates that the Printer object
       attempts to make the IPP attribute values take precedence over
       embedded instructions in the document data, however there is no
       guarantee.

     - 'not-attempted': This value indicates that the Printer object
       makes no attempt to make the IPP attribute values take precedence
       over embedded instructions in the document data.

   Section 15 contains a full description of how this attribute
   interacts with and affects other IPP attributes, especially the
   "ipp-attribute-fidelity" attribute.

4.4.26 printer-up-time (integer(1:MAX))

   This REQUIRED Printer attribute indicates the amount of time (in
   seconds) that this instance of this Printer implementation has been
   up and running.  This value is used to populate the Job attributes
   "time-at-creation", "time-at-processing", and "time-at-completed".
   These time values are all measured in seconds and all have meaning
   only relative to this attribute, "printer-up-time".  The value is a
   monotonically increasing value starting from 1 when the Printer
   object is started-up (initialized, booted, etc.).

   If the Printer object goes down at some value 'n', and comes back up,
   the implementation MAY:

     1. Know how long it has been down, and resume at some value greater
        than 'n', or
     2. Restart from 1.

   In the first case, the Printer SHOULD not tweak any existing related
   Job attributes ("time-at-creation", "time-at-processing", and "time-
   at-completed").  In the second case, the Printer object SHOULD reset
ToP   noToC   RFC2566 - Page 111
   those attributes to 0.  If a client queries a time-related Job
   attribute and finds the value to be 0, the client MUST assume that
   the Job was submitted in some life other than the Printer's current
   life.

4.4.27 printer-current-time (dateTime)

   This Printer attribute indicates the current absolute wall-clock
   time.  If an implementation supports this attribute, then a client
   could calculate the absolute wall-clock time each Job's "time-at-
   creation", "time-at-processing", and "time-at-completed" attributes
   by using both "printer-up-time" and this attribute, "printer-
   current-time".  If an implementation does not support this attribute,
   a client can only calculate the relative time of certain events based
   on the REQUIRED "printer-up-time" attribute.

4.4.28 multiple-operation-time-out (integer(1:MAX))

   This Printer attributes identifies the minimum time (in seconds) that
   the Printer object waits for additional Send-Document or Send-URI
   operations to follow a still-open multi-document Job object before
   taking  any recovery actions, such as the ones indicated in section
   3.3.1.

   It is RECOMMENDED that vendors supply a value for this attribute that
   is between 60 and 240 seconds.  An implementation MAY allow a system
   administrator to set this attribute.  If so, the system administrator
   MAY be able to set values outside this range.

4.4.29 compression-supported (1setOf type3 keyword)

   This Printer attribute identifies the set of supported compression
   algorithms for document data.  Compression only applies to the
   document data; compression does not apply to the encoding of the IPP
   operation itself.  The supported values are used to validate the
   client supplied "compression" operation attributes in Print-Job,
   Send-Document, and Send-URI requests.

   Standard values are :

     'none': no compression is used.
     'deflate':  ZIP public domain inflate/deflate) compression
        technology
     'gzip' GNU zip compression technology described in RFC 1952
        [RFC1952].
     'compress': UNIX compression technology

4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX))
ToP   noToC   RFC2566 - Page 112
   This Printer attribute specifies the upper and lower bounds of total
   sizes of jobs in K octets, i.e., in units of 1024 octets. The
   supported values are used to validate the client supplied "job-k-
   octets" operation attributes in create requests.  The corresponding
   job description attribute "job-k-octets" is defined in section
   4.3.17.

4.4.31 job-impressions-supported (rangeOfInteger(0:MAX))

   This Printer attribute specifies the upper and lower bounds for the
   number of impressions per job. The supported values are used to
   validate the client supplied "job-impressions" operation attributes
   in create requests.  The corresponding job description attribute
   "job-impressions" is defined in section 4.3.18.

4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX))

   This Printer attribute specifies the upper and lower bounds for the
   number of media sheets per job. The supported values are used to
   validate the client supplied "job-media-sheets" operation attributes
   in create requests.  The corresponding Job attribute "job-media-
   sheets" is defined in section 4.3.19.

5. Conformance

   This section describes conformance issues and requirements. This
   document introduces model entities such as objects, operations,
   attributes, attribute syntaxes, and attribute values.  These
   conformance sections describe the conformance requirements which
   apply to these model entities.

5.1 Client Conformance Requirements

   A conforming client MUST support all REQUIRED operations as defined
   in this document.  For each attribute included in an operation
   request, a conforming client MUST supply a value whose type and value
   syntax conforms to the requirements of the Model document as
   specified in Sections 3 and 4.  A conforming client MAY supply any
   registered extensions and/or private extensions in an operation
   request, as long as they meet the requirements in Section 6.

   Otherwise, there are no conformance requirements placed on the user
   interfaces provided by IPP clients or their applications.  For
   example, one application might not allow an end user to submit
   multiple documents per job, while another does.  One application
   might first query a Printer object in order to supply a graphical
   user interface (GUI) dialogue box with supported and default values
   whereas a different implementation might not.
ToP   noToC   RFC2566 - Page 113
   When sending a request, an IPP client NEED NOT supply any attributes
   that are indicated as OPTIONALLY supplied by the client.

   A client MUST be able to accept any of the attribute syntaxes defined
   in Section 4.1, including their full range, that may be returned to
   it in a response from a Printer object.  In particular for each
   attribute that the client supports whose attribute syntax is 'text',
   the client MUST accept and process both the 'textWithoutLanguage' and
   'textWithLanguage' forms.  Similarly, for each attribute that the
   client supports whose attribute syntax is 'name', the client MUST
   accept and process both the 'nameWithoutLanguage' and '
   nameWithLanguage' forms.  For presentation purposes, truncation of
   long attribute values is not recommended.  A recommended approach
   would be for the client implementation to allow the user to scroll
   through long attribute values.

   A query response may contain attribute groups, attributes, and values
   that the client does not expect.  Therefore, a client implementation
   MUST gracefully handle such responses and not refuse to inter-operate
   with a conforming Printer that is returning extended registered or
   private attributes and/or attribute values that conform to Section 6.
   Clients may choose to ignore any parameters, attributes, or values
   that they do not understand.

5.2 IPP Object Conformance Requirements

   This section specifies the conformance requirements for conforming
   implementations with respect to objects, operations, and attributes.

5.2.1 Objects

   Conforming implementations MUST implement all of the model objects as
   defined in this specification in the indicated sections:

     Section 2.1 - Printer Object
     Section 2.2 - Job Object

5.2.2 Operations

   Conforming IPP object implementations MUST implement all of the
   REQUIRED model operations, including REQUIRED responses, as defined
   in this specification in the indicated sections:

     For a Printer object:
        Print-Job (section 3.2.1)          REQUIRED
        Print-URI (section 3.2.2)          OPTIONAL
        Validate-Job (section 3.2.3)       REQUIRED
        Create-Job (section 3.2.4)         OPTIONAL
ToP   noToC   RFC2566 - Page 114
        Get-Printer-Attributes (section 3.2.5)  REQUIRED
        Get-Jobs (section 3.2.6)           REQUIRED

     For a Job object:
        Send-Document (section 3.3.1)      OPTIONAL
        Send-URI (section 3.3.2)           OPTIONAL
        Cancel-Job (section 3.3.3)         REQUIRED
        Get-Job-Attributes (section 3.3.4) REQUIRED

   Conforming IPP objects MUST support all REQUIRED operation attributes
   and all values of such attributes if so indicated in the description.
   Conforming IPP objects MUST ignore all unsupported or unknown
   operation attributes or operation attribute groups received in a
   request, but MUST reject a request that contains a supported
   operation attribute that contains an unsupported value.

   The following section on object attributes specifies the support
   required for object attributes.

5.2.3 IPP Object Attributes

   Conforming IPP objects MUST support all of the REQUIRED object
   attributes, as defined in this specification in the indicated
   sections.

   If an object supports an attribute, it MUST support only those values
   specified in this document or through the extension mechanism
   described in section 5.2.4. It MAY support any non-empty subset of
   these values.  That is, it MUST support at least one of the specified
   values and at most all of them.

5.2.4 Extensions

   A conforming IPP object MAY support registered extensions and private
   extensions, as long as they meet the requirements specified in
   Section 6.

   For each attribute included in an operation response, a conforming
   IPP object MUST return a value whose type and value syntax conforms
   to the requirement of the Model document as specified in Sections 3
   and 4.
ToP   noToC   RFC2566 - Page 115
5.2.5 Attribute Syntaxes

   An IPP object MUST be able to accept any of the attribute syntaxes
   defined in Section 4.1, including their full range, in any operation
   in which a client may supply attributes or the system administrator
   may configure attributes (by means outside the scope of IPP/1.0).  In
   particular for each attribute that the IPP object supports whose
   attribute syntax is 'text', the IPP object MUST accept and process
   both the 'textWithoutLanguage' and 'textWithLanguage' forms.
   Similarly, for each attribute that the IPP object supports whose
   attribute syntax is 'name', the IPP object MUST accept and process
   both the 'nameWithoutLanguage' and 'nameWithLanguage' forms.
   Furthermore, an IPP object MUST return attributes to the client in
   operation responses that conform to the syntax specified in Section
   4.1, including their full range if supplied previously by a client.

5.3 Charset and Natural Language Requirements

   All clients and IPP objects MUST support the 'utf-8' charset as
   defined in section 4.1.7.

   IPP objects MUST be able to accept any client request which correctly
   uses the "attributes-natural-language" operation attribute or the
   Natural Language Override mechanism on any individual attribute
   whether or not the natural language is supported by the IPP object.
   If an IPP object supports a natural language, then it MUST be able to
   translate (perhaps by table lookup) all generated 'text' or 'name'
   attribute values into one of the supported languages (see section
   3.1.4).  That is, the IPP object that supports a natural language
   NEED NOT be a general purpose translator of any arbitrary 'text' or '
   name' value supplied by the client into that natural language.
   However, the object MUST be able to translate (automatically
   generate) any of its own attribute values and messages into that
   natural language.

5.4 Security Conformance Requirements

   Conforming IPP Printer objects MAY support Secure Socket Layer
   Version 3 (SSL3) [SSL] access, support access without SSL3 or support
   both means of access.

   Conforming IPP clients SHOULD support SSL3 access and non-SSL3
   access.  Note: This client requirement to support both means that
   conforming IPP clients will be able to inter-operate with any IPP
   Printer object.
ToP   noToC   RFC2566 - Page 116
   For a detailed discussion of security considerations and the IPP
   application security profile required for SSL3 support, see section
   8.

6. IANA Considerations (registered and private extensions)

   This section describes how IPP can be extended to allow the following
   registered and private extensions to IPP:

     1. keyword attribute values
     2. enum attribute values
     3. attributes
     4. attribute syntaxes
     5. operations
     6. attribute groups
     7. status codes

   Extensions registered for use with IPP/1.0 are OPTIONAL for client
   and IPP object conformance to the IPP/1.0 Model specification.

   These extension procedures are aligned with the guidelines as set
   forth by the IESG [RFC2434].  Section 11 describes how to propose new
   registrations for consideration.  IANA will reject registration
   proposals that leave out required information or do not follow the
   appropriate format described in Section 11.  IPP/1.0 may also be
   extended by an appropriate RFC that specifies any of the above
   extensions.

6.1 Typed 'keyword' and 'enum' Extensions

   IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3
   and 4.1.4).  This document uses prefixes to the 'keyword' and 'enum'
   basic attribute syntax type in order to communicate extra information
   to the reader through its name. This extra information is not
   represented in the protocol because it is unimportant to a client or
   Printer object.  The list below describes the prefixes and their
   meaning.

     "type1":  The IPP specification must be revised to add a new
        keyword or a new enum.  No private keywords or enums are
        allowed.

     "type2":  Implementers can, at any time, add new keyword or enum
        values by proposing the complete specification to IANA:

        iana@iana.org
ToP   noToC   RFC2566 - Page 117
        IANA will forward the registration proposal to the IPP
        Designated Expert who will review the proposal with a mailing
        list that the Designated Expert keeps for this purpose.
        Initially, that list will be the mailing list used by the IPP
        WG:

             ipp@pwg.org

        even after the IPP WG is disbanded as permitted by [RFC2434].
        The IPP Designated Expert is appointed by the IESG Area Director
        responsible for IPP, according to [RFC2434].

        When a type2 keyword or enum is approved, the IPP Designated
        Expert becomes the point of contact for any future maintenance
        that might be required for that registration.

     "type3":  Implementers can, at any time, add new keyword and enum
        values by submitting the complete specification to IANA as for
        type2 who will forward the proposal to the IPP Designated
        Expert.  While no additional technical review is required, the
        IPP Designated Expert may, at his/her discretion, forward the
        proposal to the same mailing list as for type2 registrations for
        advice and comment.

        When a type3 keyword or enum is approved by the IPP Designated
        Expert, the original proposer becomes the point of contact for
        any future maintenance that might be required for that
        registration.

   For type2 and type3 keywords, the proposer includes the name of the
   keyword in the registration proposal and the name is part of the
   technical review.

   After type2 and type3 enums specifications are approved, the IPP
   Designated Expert in consultation with IANA assigns the next
   available enum number for each enum value.

   IANA will publish approved type2 and type3 keyword and enum
   attributes value registration specifications in:

        ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt

   where xxx is the attribute name that specifies the initial values and
   yyy.txt is a descriptive file name that contains one or more enums or
   keywords approved at the same time.  For example, if several
   additional enums for stapling are approved for use with the
ToP   noToC   RFC2566 - Page 118
   "finishings" attribute (and "finishings-default" and "finishings-
   supported" attributes), IANA will publish the additional values in
   the file:

        ftp.isi.edu/iana/assignments/ipp/attribute-
        values/finishings/stapling.txt

   Note: Some attributes are defined to be: 'type3 keywords' | 'name'
   which allows for attribute values to be extended by a site
   administrator with administrator defined names.  Such names are not
   registered with IANA.

   By definition, each of the three types above assert some sort of
   registry or review process in order for extensions to be considered
   valid.  Each higher numbered level (1, 2, 3) tends to be decreasingly
   less stringent than the previous level.   Therefore, any typeN value
   MAY be registered using a process for some typeM where M is less than
   N, however such registration is NOT REQUIRED.  For example, a type3
   value MAY be registered in a type 1 manner (by being included in a
   future version of an IPP specification), however, it is NOT REQUIRED.

   This specification defines keyword and enum values for all of the
   above types, including type3 keywords.

   For private (unregistered) keyword extensions, implementers SHOULD
   use keywords with a suitable distinguishing prefix, such as "xxx-"
   where xxx is the (lowercase) fully qualified company name registered
   with IANA for use in domain names [RFC1035].  For example, if the
   company XYZ Corp.  had obtained the domain name "XYZ.com", then a
   private keyword 'abc' would be: 'xyz.com-abc'.

   Note: RFC 1035 [RFC1035] indicates that while upper and lower case
   letters are allowed in domain names, no significance is attached to
   the case.  That is, two names with the same spelling but different
   case are to be treated as if identical.  Also, the labels in a domain
   name must follow the rules for ARPANET host names:  They must start
   with a letter, end with a letter or digit, and have as interior
   characters only letters, digits, and hyphen.  Labels must be 63
   characters or less.  Labels are separated by the "." character.

   For private (unregistered) enum extension, implementers MUST use
   values in the reserved integer range which is 2**30 to 2**31-1.
ToP   noToC   RFC2566 - Page 119
6.2 Attribute Extensibility

   Attribute names are type2 keywords.  Therefore, new attributes may be
   registered and have the same status as attributes in this document by
   following the type2 extension rules.  For private (unregistered)
   attribute extensions, implementers SHOULD use keywords with a
   suitable distinguishing prefix as described in Section 6.1.

   IANA will publish approved attribute registration specifications as
   separate files:

        ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt

   where "xxx-yyy" is the new attribute name.

   If a new Printer object attribute is defined and its values can be
   affected by a specific document format, its specification needs to
   contain the following sentence:

     "The value of this attribute returned in a Get-Printer-Attributes
     response MAY depend on the "document-format" attribute supplied
     (see Section 3.2.5.1)."

   If the specification does not, then its value in the Get-Printer-
   Attributes response MUST NOT depend on the "document-format" supplied
   in the request.  When a new Job Template attribute is registered, the
   value of the Printer attributes MAY vary with "document-format"
   supplied in the request without the specification having to indicate
   so.

6.3 Attribute Syntax Extensibility

   Attribute syntaxes are like type2 enums.  Therefore, new attribute
   syntaxes may be registered and have the same status as attribute
   syntaxes in this document by following the type2 extension rules
   described in Section 6.1.  The value codes that identify each of the
   attribute syntaxes are assigned in the Encoding and Transport
   specification [RFC2565], including a designated range for private,
   experimental use.

   For attribute syntaxes, the IPP Designated Expert in consultation
   with IANA assigns the next attribute syntax code in the appropriate
   range as specified in [RFC2565].  IANA will publish approved
   attribute syntax registration specifications as separate files:

        ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt

   where 'xxx-yyy' is the new attribute syntax name.
ToP   noToC   RFC2566 - Page 120
6.4 Operation Extensibility

   Operations may also be registered following the type2 procedures
   described in Section 6.1, though major new operations will usually be
   done by a new standards track RFC that augments this document.  For
   private (unregistered) operation extensions, implementers MUST use
   the range for the "operation-id" in requests specified in Section
   4.4.13 "operations-supported" Printer attribute.

   For operations, the IPP Designated Expert in consultation with IANA
   assigns the next operation-id code as specified in Section 4.4.13.
   IANA will publish approved operation registration specifications as
   separate files:

        ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt

   where "Xxx-Yyy" is the new operation name.

6.5 Attribute Groups

   Attribute groups passed in requests and responses may be registered
   following the type2 procedures described in Section 6.1.  The tags
   that identify each of the attribute groups are assigned in [RFC2565].

   For attribute groups, the IPP Designated Expert in consultation with
   IANA assigns the next attribute group tag code in the appropriate
   range as specified in [RFC2565].  IANA will publish approved
   attribute group registration specifications as separate files:

        ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
        tag.txt

   where 'xxx-yyy-tag' is the new attribute group tag name.

6.6 Status Code Extensibility

   Operation status codes may also be registered following the type2
   procedures described in Section 6.1.  The values for status codes are
   allocated in ranges as specified in Section 13 for each status code
   class:

     "informational" - Request received, continuing process
     "successful" - The action was successfully received, understood,
        and accepted
     "redirection" - Further action must be taken in order to complete
        the request
     "client-error" - The request contains bad syntax or cannot be
        fulfilled
ToP   noToC   RFC2566 - Page 121
     "server-error" - The IPP object  failed to fulfill an apparently
        valid request

   For private (unregistered) operation status code extensions,
   implementers MUST use the top of each range as specified in Section
   13.

   For operation status codes, the IPP Designated Expert in consultation
   with IANA assigns the next status code in the appropriate class range
   as specified in Section 13.  IANA will publish approved status code
   registration specifications as separate files:

        ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt

   where "xxx-yyy" is the new operation status code keyword.

6.7 Registration of MIME types/sub-types for document-formats

   The "document-format" attribute's syntax is 'mimeMediaType'.  This
   means that valid values are Internet Media Types (see Section 4.1.9).
   RFC 2045 [RFC2045] defines the syntax for valid Internet media types.
   IANA is the registry for all Internet media types.

6.8 Registration of charsets for use in 'charset' attribute values

   The "attributes-charset" attribute's syntax is 'charset'.  This means
   that valid values are charsets names.  When a charset in the IANA
   registry has more than one name (alias), the name labeled as
   "(preferred MIME name)", if present, MUST be used (see Section
   4.1.7).  IANA is the registry for charsets following the procedures
   of [RFC2278].

7. Internationalization Considerations

   Some of the attributes have values that are text strings and names
   which are intended for human understanding rather than machine
   understanding (see the 'text' and 'name' attribute syntaxes in
   Sections 4.1.1 and 4.1.2).

   In each operation request, the client

     - identifies the charset and natural language of the request which
       affects each supplied 'text' and 'name' attribute value, and
     - requests the charset and natural language for attributes returned
       by the IPP object in operation responses (as described in Section
       3.1.4.1).
ToP   noToC   RFC2566 - Page 122
   In addition, the client MAY separately and individually identify the
   Natural Language Override of a supplied 'text' or 'name' attribute
   using the 'textWithLanguage' and 'nameWithLanguage' technique
   described section 4.1.1.2 and 4.1.2.2 respectively.

   All IPP objects MUST support the UTF-8 [RFC2279] charset in all '
   text' and 'name' attributes supported.  If an IPP object supports
   more than the UTF-8 charset, the object MUST convert between them in
   order to return the requested charset to the client according to
   Section 3.1.4.2.  If an IPP object supports more than one natural
   language, the object SHOULD return 'text' and 'name' values in the
   natural language requested where those values are generated by the
   Printer (see Section 3.1.4.1).

   For Printers that support multiple charsets and/or multiple natural
   languages in 'text' and 'name' attributes, different jobs may have
   been submitted in differing charsets and/or natural languages.  All
   responses MUST be returned in the charset requested by the client.
   However, the Get-Jobs operation uses the 'textWithLanguage' and '
   nameWithLanguage' mechanism to identify the differing natural
   languages with each job attribute returned.

   The Printer object also has configured charset and natural language
   attributes.   The client can query the Printer object to determine
   the list of charsets and natural languages supported by the Printer
   object and what the Printer object's configured values are.  See the
   "charset-configured", "charset-supported", "natural-language-
   configured", and "generated-natural-language-supported" Printer
   description attributes for more details.

   The "charset-supported" attributed identifies the supported charsets.
   If a charset is supported, the IPP object MUST be capable of
   converting to and from that charset into any other supported charset.
   In many cases, an IPP object will support only one charset and it
   MUST be the UTF-8 charset.

   The "charset-configured" attribute identifies the one supported
   charset which is the native charset given the current configuration
   of the IPP object (administrator defined).

   The "generated-natural-language-supported" attribute identifies the
   set of supported natural languages for generated messages; it is not
   related to the set of natural languages that must be accepted for
   client supplied 'text' and 'name' attributes.  For client supplied '
   text' and 'name' attributes, an IPP object MUST accept ALL supplied
   natural languages.  Just because a Printer object is currently
ToP   noToC   RFC2566 - Page 123
   configured to support 'en-us' natural language does not mean that the
   Printer object should reject a job if the client supplies a job name
   that is in 'fr-ca'.

   The "natural-language-configured" attribute identifies the one
   supported natural language for generated messages which is the native
   natural language given the current configuration of the IPP object
   (administrator defined).

   Attributes of type 'text' and 'name' are populated from different
   sources.  These attributes can be categorized into following groups
   (depending on the source of the attribute):

     1. Some attributes are supplied by the client (e.g., the client
        supplied "job-name", "document-name", and "requesting-user-name"
        operation attributes along with the corresponding Job object's
        "job-name" and "job-originating-user-name" attributes).  The IPP
        object MUST accept these attributes in any natural language no
        matter what the set of supported languages for generated
        messages
     2. Some attributes are supplied by the system administrator (e.g.,
        the Printer object's "printer-name" and "printer-location"
        attributes).  These too can be in any natural language.  If the
        natural language for these attributes is different than what a
        client requests, then they must be reported using the Natural
        Language Override mechanism.
     3. Some attributes are supplied by the device manufacturer (e.g.,
        the Printer object's "printer-make-and-model" attribute).  These
        too can be in any natural language.  If the natural language for
        these attributes is different than what a client requests, then
        they must be reported using the Natural Language Override
        mechanism.
     4. Some attributes are supplied by the operator (e.g., the Job
        object's "job-message-from-operator" attribute). These too can
        be in any natural language.  If the natural language for these
        attributes is different than what a client requests, then they
        must be reported using the Natural Language Override mechanism.
     5. Some attributes are generated by the IPP object (e.g., the Job
        object's "job-state-message" attribute, the Printer object's
        "printer-state-message" attribute, and the "status-message"
        operation attribute).  These attributes can only be in one of
        the "generated-natural-language-supported" natural languages.
        If a client requests some natural language for these attributes
        other than one of the supported values, the IPP object SHOULD
        respond using the value of the "natural-language-configured"
        attribute (using the Natural Language Override mechanism if
        needed).
ToP   noToC   RFC2566 - Page 124
   The 'text' and 'name' attributes specified in this version of this
   document (additional ones will be registered according to the
   procedures in Section 6) are:

     Attributes                      Source
     --------------------------      ----------
     Operation Attributes
        job-name (name)               client
        document-name (name)          client
        requesting-user-name (name)   client
        status-message                Job or Printer object

     Job Template Attributes:
        job-hold-until)          client matches administrator-configured
            (keyword | name
        job-hold-until-default   client matches administrator-configured
            (keyword | name)
        job-hold-until-supported client matches administrator-configured
            (keyword | name)
        job-sheets               client matches administrator-configured
            (keyword | name)
        job-sheets-default       client matches administrator-configured
            (keyword | name)
        job-sheets-supported     client matches administrator-configured
            (keyword | name)
        media                    client matches administrator-configured
            (keyword | name)
        media-default            client matches administrator-configured
            (keyword | name)
        media-supported          client matches administrator-configured
            (keyword | name)
        media-ready              client matches administrator-configured
            (keyword | name)

     Job Description Attributes:
        job-name (name)               client or Printer object
        job-originating-user-name (name)   Printer object
        job-state-message (text)      Job or Printer object
        output-device-assigned (name(127)) administrator
        job-message-from-operator (text(127))   operator

     Printer Description Attributes:
        printer-name (name(127))      administrator
        printer-location (text(127))  administrator
        printer-info (text(127))      administrator
        printer-make-and-model (text(127)) administrator or manufacturer
        printer-state-message (text)  Printer object
        printer-message-from-operator (text(127))    operator


(next page on part 6)

Next Section