Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2566

Internet Printing Protocol/1.0: Model and Semantics

Pages: 173
Obsoleted by:  2911
Part 7 of 7 – Pages 155 to 173
First   Prev   None

ToP   noToC   RFC2566 - Page 155   prevText
14. APPENDIX C:  "media" keyword values

   Standard keyword values are taken from several sources.

   Standard values are defined (taken from DPA[ISO10175] and the Printer
   MIB[RFC1759]):

     'default': The default medium for the output device
     'iso-a4-white': Specifies the ISO A4 white medium
     'iso-a4-colored': Specifies the ISO A4 colored medium
     'iso-a4-transparent' Specifies the ISO A4 transparent medium
     'iso-a3-white': Specifies the ISO A3 white medium
     'iso-a3-colored': Specifies the ISO A3 colored medium
     'iso-a5-white': Specifies the ISO A5 white medium
     'iso-a5-colored': Specifies the ISO A5 colored medium
     'iso-b4-white': Specifies the ISO B4 white medium
     'iso-b4-colored': Specifies the ISO B4 colored medium
     'iso-b5-white': Specifies the ISO B5 white medium
     'iso-b5-colored': Specifies the ISO B5 colored medium
     'jis-b4-white': Specifies the JIS B4 white medium
     'jis-b4-colored': Specifies the JIS B4 colored medium
     'jis-b5-white': Specifies the JIS B5 white medium
     'jis-b5-colored': Specifies the JIS B5 colored medium

   The following standard values are defined for North American media:

     'na-letter-white': Specifies the North American letter white medium
     'na-letter-colored': Specifies the North American letter colored
        medium
     'na-letter-transparent': Specifies the North American letter
        transparent medium
     'na-legal-white': Specifies the North American legal white medium
     'na-legal-colored': Specifies the North American legal colored
        medium

   The following standard values are defined for envelopes:

     'iso-b4-envelope': Specifies the ISO B4 envelope medium
     'iso-b5-envelope': Specifies the ISO B5 envelope medium
     'iso-c3-envelope': Specifies the ISO C3 envelope medium
     'iso-c4-envelope': Specifies the ISO C4 envelope medium
     'iso-c5-envelope': Specifies the ISO C5 envelope medium
     'iso-c6-envelope': Specifies the ISO C6 envelope medium
     'iso-designated-long-envelope': Specifies the ISO Designated Long
        envelope medium
     'na-10x13-envelope': Specifies the North American 10x13 envelope
        medium
ToP   noToC   RFC2566 - Page 156
     'na-9x12-envelope': Specifies the North American 9x12 envelope
        medium
     'monarch-envelope': Specifies the Monarch envelope
     'na-number-10-envelope': Specifies the North American number 10
        business envelope medium
     'na-7x9-envelope': Specifies the North American 7x9 inch envelope
     'na-9x11-envelope': Specifies the North American 9x11 inch envelope
     'na-10x14-envelope': Specifies the North American 10x14 inch
        envelope
     'na-number-9-envelope': Specifies the North American number 9
        business envelope
     'na-6x9-envelope': Specifies the North American 6x9 inch envelope
     'na-10x15-envelope': Specifies the North American 10x15 inch
        envelope

   The following standard values are defined for the less commonly used
   media (white-only):

     'executive-white': Specifies the white executive medium
     'folio-white': Specifies the folio white medium
     'invoice-white': Specifies the white invoice medium
     'ledger-white': Specifies the white ledger medium
     'quarto-white': Specified the white quarto medium
     'iso-a0-white': Specifies the ISO A0 white medium
     'iso-a1-white': Specifies the ISO A1 white medium
     'iso-a2-white': Specifies the ISO A2 white medium
     'iso-a6-white': Specifies the ISO A6 white medium
     'iso-a7-white': Specifies the ISO A7 white medium
     'iso-a8-white': Specifies the ISO A8 white medium
     'iso-a9-white': Specifies the ISO A9 white medium
     'iso-10-white': Specifies the ISO A10 white medium
     'iso-b0-white': Specifies the ISO B0 white medium
     'iso-b1-white': Specifies the ISO B1 white medium
     'iso-b2-white': Specifies the ISO B2 white medium
     'iso-b3-white': Specifies the ISO B3 white medium
     'iso-b6-white': Specifies the ISO B6 white medium
     'iso-b7-white': Specifies the ISO B7 white medium
     'iso-b8-white': Specifies the ISO B8 white medium
     'iso-b9-white': Specifies the ISO B9 white medium
     'iso-b10-white': Specifies the ISO B10 white medium
     'jis-b0-white': Specifies the JIS B0 white medium
     'jis-b1-white': Specifies the JIS B1 white medium
     'jis-b2-white': Specifies the JIS B2 white medium
     'jis-b3-white': Specifies the JIS B3 white medium
     'jis-b6-white': Specifies the JIS B6 white medium
     'jis-b7-white': Specifies the JIS B7 white medium
ToP   noToC   RFC2566 - Page 157
     'jis-b8-white': Specifies the JIS B8 white medium
     'jis-b9-white': Specifies the JIS B9 white medium
     'jis-b10-white': Specifies the JIS B10 white medium


   The following standard values are defined for engineering media:

     'a': Specifies the engineering A size medium
     'b': Specifies the engineering B size medium
     'c': Specifies the engineering C size medium
     'd': Specifies the engineering D size medium
     'e': Specifies the engineering E size medium


   The following standard values are defined for input-trays (from ISO
   DPA and the Printer MIB):

     'top': The top input tray in the printer.
     'middle': The middle input tray in the printer.
     'bottom': The bottom input tray in the printer.
     'envelope': The envelope input tray in the printer.
     'manual': The manual feed input tray in the printer.
     'large-capacity': The large capacity input tray in the printer.
     'main': The main input tray
     'side': The side input tray


   The following standard values are defined for media sizes (from ISO
   DPA):

     'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined
        in ISO 216
     'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
        ISO 216
     'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
        ISO 216
     'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
        ISO 216
     'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
        ISO 216
     'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
        ISO 216
     'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
        ISO 216
     'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
        ISO 216
     'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in
        ISO 216
ToP   noToC   RFC2566 - Page 158
     'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in
        ISO 216
     'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
        ISO 216
     'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined
        in ISO 216
     'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined
        in ISO 216
     'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
        ISO 216
     'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
        ISO 216
     'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
        ISO 216
     'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
        ISO 216
     'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
        ISO 216
     'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
        ISO 216
     'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in
        ISO 216
     'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in
        ISO 216
     'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
        ISO 216
     'na-letter': Specifies the North American letter size: 8.5 inches by
        11 inches
     'na-legal': Specifies the North American legal size: 8.5 inches by
        14 inches
     'executive': Specifies the executive size (7.25 X 10.5 in)
     'folio': Specifies the folio size (8.5 X 13 in)
     'invoice': Specifies the invoice size (5.5 X 8.5 in)
     'ledger': Specifies the ledger size (11 X 17 in)
     'quarto': Specifies the quarto size (8.5 X 10.83 in)
     'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
        ISO 269
     'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
        ISO 269
     'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
        ISO 269
     'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
        ISO 269
     'iso-designated-long': Specifies the ISO Designated Long size: 110
        mm by 220 mm as defined in ISO 269
     'na-10x13-envelope': Specifies the North American 10x13 size: 10
        inches by 13 inches
ToP   noToC   RFC2566 - Page 159
     'na-9x12-envelope': Specifies the North American 9x12 size: 9
        inches by 12 inches
     'na-number-10-envelope': Specifies the North American number 10
        business envelope size: 4.125 inches by 9.5 inches
     'na-7x9-envelope': Specifies the North American 7x9 inch envelope
        size
     'na-9x11-envelope': Specifies the North American 9x11 inch envelope
        size
     'na-10x14-envelope': Specifies the North American 10x14 inch
        envelope size
     'na-number-9-envelope': Specifies the North American number 9
        business envelope size
     'na-6x9-envelope': Specifies the North American 6x9 envelope size
     'na-10x15-envelope': Specifies the North American 10x15 envelope
        size
     'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
        in)
     'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
     'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
     'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
     'jis-b3': Specifies the JIS B3 size: 364mm x 515mm
     'jis-b4': Specifies the JIS B4 size: 257mm x 364mm
     'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
     'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
     'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
     'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
     'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
     'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
ToP   noToC   RFC2566 - Page 160
15. APPENDIX D: Processing IPP Attributes

   When submitting a print job to a Printer object, the IPP model allows
   a client to supply operation and Job Template attributes along with
   the document data.  These Job Template attributes in the create
   request affect the rendering, production and finishing of the
   documents in the job.  Similar types of instructions may also be
   contained in the document to be printed, that is, embedded within the
   print data itself.  In addition, the Printer has a set of attributes
   that describe what rendering and finishing options which are
   supported by that Printer.  This model, which allows for flexibility
   and power, also introduces the potential that at job submission time,
   these client-supplied attributes may conflict with either:

     - what the implementation is capable of realizing (i.e., what the
       Printer supports), as well as
     - the instructions embedded within the print data itself.

   The following sections describe how these two types of conflicts are
   handled in the IPP model.

15.1 Fidelity

   If there is a conflict between what the client requests and what a
   Printer object supports, the client may request one of two possible
   conflict handling mechanisms:

     1) either reject the job since the job can not be processed exactly
        as specified, or
     2) allow the Printer to make any changes necessary to proceed with
        processing the Job the best it can.

   In the first case the client is indicating to the Printer object:
   "Print the job exactly as specified with no exceptions, and if that
   can't be done, don't even bother printing the job at all." In the
   second case, the client is indicating to the Printer object: "It is
   more important to make sure the job is printed rather than be
   processed exactly as specified; just make sure the job is printed
   even if client supplied attributes need to be changed or ignored."

   The IPP model accounts for this situation by introducing an "ipp-
   attribute-fidelity" attribute.

   In a create request, "ipp-attribute-fidelity" is a boolean operation
   attribute that is OPTIONALLY supplied by the client.  The value '
   true' indicates that total fidelity to client supplied Job Template
   attributes and values is required.  The client is requesting that the
   Job be printed exactly as specified, and if that is not possible then
ToP   noToC   RFC2566 - Page 161
   the job MUST be rejected rather than processed incorrectly.  The
   value 'false' indicates that a reasonable attempt to print the Job is
   acceptable.  If a Printer does not support some of the client
   supplied Job Template attributes or values, the Printer MUST ignore
   them or substitute any supported value for unsupported values,
   respectively.  The Printer may choose to substitute the default value
   associated with that attribute, or use some other supported value
   that is similar to the unsupported requested value.  For example, if
   a client supplies a "media" value of 'na-letter', the Printer may
   choose to substitute 'iso-a4' rather than a default value of '
   envelope'. If the client does not supply the "ipp-attribute-fidelity"
   attribute, the Printer assumes a value of 'false'.

   Each Printer implementation MUST support both types of "fidelity"
   printing (that is whether the client supplies a value of 'true' or '
   false'):

     - If the client supplies 'false' or does not supply the attribute,
       the Printer object MUST always accept the request by ignoring
       unsupported Job Template attributes and by substituting
       unsupported values of supported Job Template attributes with
       supported values.
     - If the client supplies 'true', the Printer object MUST reject the
       request if the client supplies unsupported Job Template
       attributes.

   Since a client can always query a Printer to find out exactly what is
   and is not supported, "ipp-attribute-fidelity" set to 'false' is
   useful when:

     1) The End-User uses a command line interface to request attributes
        that might not be supported.
     2) In a GUI context, if the End User expects the job might be moved
        to another printer and prefers a sub-optimal result to nothing
        at all.
     3) The End User just wants something reasonable in lieu of nothing
        at all.

15.2 Page Description Language (PDL) Override

   If there is a conflict between the value of an IPP Job Template
   attribute and a corresponding instruction in the document data, the
   value of the IPP attribute SHOULD take precedence over the document
   instruction.  Consider the case where a previously formatted file of
   document data is sent to an IPP Printer.  In this case, if the client
   supplies any attributes at job submission time, the client desires
   that those attributes override the embedded instructions.  Consider
   the case were a previously formatted document has embedded in it
ToP   noToC   RFC2566 - Page 162
   commands to load 'iso-a4' media.  However, the document is passed to
   an end user that only has access to a printer with 'na-letter' media
   loaded.  That end user most likely wants to submit that document to
   an IPP Printer with the "media" Job Template attribute set to 'na-
   letter'.  The job submission attribute should take precedence over
   the embedded PDL instruction.  However, until companies that supply
   document data interpreters allow a way for external IPP attributes to
   take precedence over embedded job production instructions, a Printer
   might not be able to support the semantics that IPP attributes
   override the embedded instructions.

   The IPP model accounts for this situation by introducing a "pdl-
   override-supported" attribute that describes the Printer objects
   capabilities to override instructions embedded in the PDL data
   stream.  The value of the "pdl-override-supported" attribute is
   configured by means outside IPP/1.0.

   This REQUIRED Printer 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.

   At job processing time, an implementation that supports the value of
   'attempted' might do one of several different actions:

     1) Generate an output device specific command sequence to realize
        the feature represented by the IPP attribute value.
     2) Parse the document data itself and replace the conflicting
        embedded instruction with a new embedded instruction that
        matches the intent of the IPP attribute value.
     3) Indicate to the Printer that external supplied attributes take
        precedence over embedded instructions and then pass the external
        IPP attribute values to the document data interpreter.
     4) Anything else that allows for the semantics that IPP attributes
        override embedded document data instructions.

   Since 'attempted' does not offer any type of guarantee, even though a
   given Printer object might not do a very "good" job of attempting to
   ensure that IPP attributes take a higher precedence over instructions
   embedded in the document data, it would still be a conforming
   implementation.
ToP   noToC   RFC2566 - Page 163
   At job processing time, an implementation that supports the value of
   'not-attempted' might do one of the following actions:

     1) Simply pre-pend the document data with the PDL instruction that
        corresponds to the client-supplied PDL attribute, such that if
        the document data also has the same PDL instruction, it will
        override what the Printer object pre-pended.  In other words,
        this implementation is using the same implementation semantics
        for the client-supplied IPP attributes as for the Printer object
        defaults.
     2) Parse the document data and replace the conflicting embedded
        instruction with a new embedded instruction that approximates,
        but does not match, the semantic intent of the IPP attribute
        value.

   Note:  The "ipp-attribute-fidelity" attribute applies to the
   Printer's ability to either accept or reject other unsupported Job
   Template attributes.  In other words, if "ipp-attribute-fidelity" is
   set to 'true', a Job is accepted if and only if the client supplied
   Job Template attributes and values are supported by the Printer.
   Whether these attributes actually affect the processing of the Job
   when the document data contains embedded instructions depends on the
   ability of the Printer to override the instructions embedded in the
   document data with the semantics of the IPP attributes.  If the
   document data attributes can be overridden ("pdl-override-supported"
   set to 'attempted'), the Printer makes an attempt to use the IPP
   attributes when processing the Job. If the document data attributes
   can not be overridden ("pdl-override-supported" set to 'not-
   attempted'), the Printer makes no attempt to override the embedded
   document data instructions with the IPP attributes when processing
   the Job, and hence, the IPP attributes may fail to affect the Job
   processing and output when the corresponding instruction is embedded
   in the document data.

15.3 Using Job Template Attributes During Document Processing.

   The Printer object uses some of the Job object's Job Template
   attributes during the processing of the document data associated with
   that job.  These include, but are not limited to, "orientation",
   "number-up", "sides", "media", and "copies".  The processing of each
   document in a Job Object MUST follow the steps below. These steps are
   intended only to identify when and how attributes are to be used in
   processing document data and any alternative steps that accomplishes
   the same effect can be used to implement this specification.

     1. Using the client supplied "document-format" attribute or some
        form of document format detection algorithm (if the value of
        "document- format" is not specific enough), determine whether or
ToP   noToC   RFC2566 - Page 164
        not the document data has already been formatted for printing.
        If the document data has been formatted, then go to step 2.
        Otherwise, the document data MUST be formatted. The formatting
        detection algorithm is implementation defined and is not
        specified by this specification. The formatting of the document
        data uses the "orientation-requested" attribute to determine how
        the formatted print data should be placed on a print-stream
        page, see section 4.2.10 for the details.

     2. The document data is in the form of a print-stream in a known
        media type. The "page-ranges" attribute is used to select, as
        specified in section 4.2.7, a sub-sequence of the pages in the
        print-stream that are to be processed and images.

     3. The input to this step is a sequence of print-stream pages. This
        step is controlled by the "number-up" attribute. If the value of
        "number-up" is N, then during the processing of the print-stream
        pages, each N print-stream pages are positioned, as specified in
        section 4.2.9, to create a single impression. If a given
        document does not have N more print-stream pages, then the
        completion of the impression is controlled by the "multiple-
        document-handling" attribute as described in section 4.2.4; when
        the value of this attribute is 'single-document' or 'single-
        document-new-sheet', the print-stream pages of document data
        from subsequent documents is used to complete the impression.

        The size(scaling), position(translation) and rotation of the
        print-stream pages on the impression is implementation defined.
        Note that during this process the print-stream pages may be
        rendered to a form suitable for placing on the impression; this
        rendering is controlled by the values of the "printer-
        resolution" and "print- quality" attributes as described in
        sections 4.2.12 and 4.2.13. In the case N=1, the impression is
        nearly the same as the print-stream page; the differences would
        only be in the size, position and rotation of the print-stream
        page and/or any decoration, such as a frame to the page, that is
        added by the implementation.

     4. The collection of impressions is placed, in sequence, onto sides
        of the media sheets. This placement is controlled by the "sides"
        attribute and the orientation of the print-stream page, as
        described in section 4.2.8. The orientation of the print-stream
        pages affects the orientation of the impression; for example, if
        "number-up" equals 2, then, typically, two portrait print-stream
        pages become one landscape impression. Note that the placement
        of impressions onto media sheets is also controlled by the
        "multiple-document-handling" attribute as described in section
        4.2.4.
ToP   noToC   RFC2566 - Page 165
     5. The "copies" and "multiple-document-handling" attributes are
        used to determine how many copies of each media instance are
        created and in what order. See sections 4.2.5 and 4.2.4 for the
        details.

     6. When the correct number of copies are created, the media
        instances are finished according to the values of the
        "finishings" attribute as described in 4.2.6. Note that
        sometimes finishing operations may require manual intervention
        to perform the finishing operations on the copies, especially
        uncollated copies. This specification allows any or all of the
        processing steps to be performed automatically or manually at
        the discretion of the Printer object.
ToP   noToC   RFC2566 - Page 166
16. APPENDIX E: Generic Directory Schema

   This section defines a generic schema for an entry in a directory
   service.  A directory service is a means by which service users can
   locate service providers.  In IPP environments, this means that IPP
   Printers can be registered (either automatically or with the help of
   an administrator) as entries of type printer in the directory using
   an implementation specific mechanism such as entry attributes, entry
   type fields, specific branches, etc.  IPP clients can search or
   browse for entries of type printer.  Clients use the directory
   service to find entries based on naming, organizational contexts, or
   filtered searches on attribute values of entries.  For example, a
   client can find all printers in the "Local Department" context.
   Authentication and authorization are also often part of a directory
   service so that an administrator can place limits on end users so
   that they are only allowed to find entries to which they have certain
   access rights.  IPP itself does not require any specific directory
   service protocol or provider.

   Note: Some directory implementations allow for the notion of
   "aliasing".  That is, one directory entry object can appear as
   multiple directory entry object with different names for each object.
   In each case, each alias refers to the same directory entry object
   which refers to a single IPP Printer object.

   The generic schema is a subset of IPP Printer Job Template and
   Printer Description attributes (sections 4.2 and 4.4).  These
   attributes are identified as either RECOMMENDED or OPTIONAL for the
   directory entry itself.  This conformance labeling is NOT the same
   conformance labeling applied to the attributes of IPP Printers
   objects.  The conformance labeling in this Appendix is intended to
   apply to directory templates and to IPP Printer implementations that
   subscribe by adding one or more entries to a directory.  RECOMMENDED
   attributes SHOULD be associated with each directory entry.  OPTIONAL
   attributes MAY be associated with the directory entry (if known or
   supported).  In addition, all directory entry attributes SHOULD
   reflect the current attribute values for the corresponding Printer
   object.

   The names of attributes in directory schema and entries SHOULD be the
   same as the IPP Printer attribute names as shown.

   In order to bridge between the directory service and the IPP Printer
   object, one of the RECOMMENDED directory entry attributes is the
   Printer object's "printer-uri-supported" attribute.  The IPP client
   queries the "printer-uri-supported" attribute in the directory entry
ToP   noToC   RFC2566 - Page 167
   and then addresses the IPP Printer object using one of its URIs.  The
   "uri-security-supported" attribute identifies the protocol (if any)
   used to secure a channel.

   The following attributes define the generic schema for directory
   entries of type PRINTER:

     printer-uri-supported           RECOMMENDED    Section 4.4.1
     uri-security-supported          RECOMMENDED    Section 4.4.2
     printer-name                    RECOMMENDED    Section 4.4.3
     printer-location                RECOMMENDED    Section 4.4.4
     printer-info                    OPTIONAL       Section 4.4.5
     printer-more-info               OPTIONAL       Section 4.4.6
     printer-make-and-model          RECOMMENDED    Section 4.4.8
     charset-supported               OPTIONAL       Section 4.4.15
     generated-natural-language-
        supported                    OPTIONAL       Section 4.4.17
     document-format-supported       RECOMMENDED    Section 4.4.19
     color-supported                 RECOMMENDED    Section 4.4.23
     finishings-supported            OPTIONAL       Section 4.2.6
     number-up-supported             OPTIONAL       Section 4.2.7
     sides-supported                 RECOMMENDED    Section 4.2.8
     media-supported                 RECOMMENDED    Section 4.2.11
     printer-resolution-supported    OPTIONAL       Section 4.2.12
     print-quality-supported         OPTIONAL       Section 4.2.13
ToP   noToC   RFC2566 - Page 168
17. APPENDIX F:  Change History for the IPP Model and Semantics document

   The following substantive changes and major clarifications have been
   made to this document from the June 30, 1998 version based on the
   interoperability testing that took place September 23-25 1998 and
   subsequent mailing list and meeting discussions.  They are listed in
   the order of occurrence in the document.  These changes are the ones
   that might affect implementations.  Clarifications that are unlikely
   to affect implementations are not listed.  The issue numbers refer to
   the IPP Issues List which is available in the following directory:

        ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/

   Section   Description

   global    Replaced TLS references with SSL3 references as agreed with
             our Area Director on 11/12/1998.

   global    Removed the indications that some of these IPP documents
             are informational, since the intent is now to publish all
             IPP/1.0 documents as informational as agreed with our Area
             Director on 11/12/1998.

   3.1.2,    Clarify that the IPP object SHOULD NOT validate the
   16.3.3    range of the request-id being 1 to 2**31-1, but accepts
   [now ipp- and returns any value.  Clients MUST still keep in the
   iig]      range 1 to 2**31 though.  If the request is terminated
             before the complete "request-id" is received, the IPP
             object rejects the request and returns a response with a
             "request-id" of 0  (Issue 1.36).

   3.1.4.1,  Clarified that when a client submits a request in a
   13.1.4.14 charset that is not supported, the IPP object SHOULD
             return any 'text' or 'name' attributes in the 'utf-8'
             charset, if it returns any, since clients and IPP
             objects MUST support 'utf-8'.  (Issue 1.19)

   3.1.4.1   Clarified Section 3.1.4.1 Request Operation Attributes
             that a client MAY use the attribute level natural
             language override (text/nameWithLanguage) redundantly in
             a request.  (Issue 1.46)

   3.1.4.2   Clarified Section 3.1.4.2 Response Operation Attributes
             that an IPP object MAY use the attribute level natural
             language override (text/nameWithLanguage) redundantly in
             a response.  (Issue 1.46)
ToP   noToC   RFC2566 - Page 169
   3.1.6     Clarified section 3.1.6:  If the Printer object supports
             the "status-message" operation attribute, it NEED NOT
             return a status message for the following error status
             codes:  'client-error-bad-request', 'client-error-
             charset-not-supported', 'server-error-internal-error',
             'server-error-operation-not-supported', and 'server-
             error-version-not-supported'.

   3.2.1.1   Clarified that if a client is not supplying any Job
             Template attributes in a request, the client SHOULD omit
             Group 2 rather than sending an empty group.  However, a
             Printer object MUST be able to accept an empty group.
             This makes [RFC2566] agree with [RFC2565].  (Issue 1.16)

   3.2.1.2,  Clarified that if an IPP object is not returning any
   3.2.5.2,  Unsupported Attributes in a response, the IPP object
   3.2.6.2,  SHOULD omit Group 2 rather than sending an empty group.
   3.3.1.2,  However, a client MUST be able to accept an empty group.
   3.3.3.2,  This makes [RFC2566] agree with [RFC2565].  (Issue 1.17)
   3.3.4.2

   3.2.1.2,  Clarified that an IPP object MUST treat an unsupported
   13.1.2.2, attribute syntax supplied in a request in the same way
   13.1.4.12 as an unsupported value.  The IPP object MUST return the
             attribute, the attribute syntax, and the value in the
             Unsupported Attributes group.  (Issue 1.26)

   3.2.5.2,  Clarified for Get-Printer-Attributes, Get-Jobs, and Get-
   3.2.6.2,  Job-Attributes that an IPP object MUST return
   3.3.4.2,  'successful-ok-ignored-or-substituted-attributes' (0x1),

   13.1.2.1, rather than 'successful-ok' (0x0), when a client
   13.1.2.2, supplies unsupported attributes as values of the
   13.1.4.12 'requested-attributes' operation attribute.  (Issue
             1.24)
             Also clarified that the response NEED NOT contain the
             "requested-attributes" operation attribute with any
             supplied values (attribute keywords) that were requested
             by the client but are not supported by the IPP object.
             (Issue 1.18)

   3.2.6.2   Deleted the job-level natural language override (NLO)
   4.1.1.2   from Section 3.2.6.2 Get-Jobs Response so that all
   4.3.24    operation responses are the same with respect to NLO.
             (Issue 1.47)
ToP   noToC   RFC2566 - Page 170
   3.3.1     Clarified that an IPP Printer that supports the Create-
             Job operation MUST handle the situation when a client
             does not supply Send-Document or Send-URI operations
             within a one- to four-minute time period.  Also
             clarified that a client MUST send documents in a multi-
             document job without undue or unbounded delay.  (Issue
             1.28)

   3.3.3     Clarified that the IPP object MUST reject a Cancel-Job
             request if the job is in 'completed', 'canceled', or
             'aborted' job states.  (Issue 1.12)

   4.1.2.3   Added this new sub-section:  it specifies that
             nameWithoutLanguage plus the implicit natural language
             matches nameWithLanguage, if the values and natural
             languages are the same.  Also added that keyword never
             matches nameWithLanguage or nameWithoutLanguage.
             Clarified that if both have countries, that the
             countries SHOULD match as well.  If either do not, then
             the country field SHOULD be ignored.  (Issues 1.33 and
             1.34)

   4.1.5     Clarified regarding the case-insensitivity of URLs to
             refer only to the RFCs that define them.  (Issue 1.10)

   4.1.11    Clarified that 'boolean' is not a full-sized integer.
             (Issue 1.38)

   4.1.15    Clarified that 'resolution' is not three full-sized
             integers.  (Issue 1.20)

   4.2.*     Clarified that standard values are keywords or enums,
             not names.  (Issue 1.49).

   4.2.4     Added the 'single-document-new-sheet' value to Section
             4.2.4 multiple-document-handling.  (Issue 1.54)

   4.4.18,   Clarified that the "document-format-default" and
   4.4.19    "document-format-supported" Printer Description
             attributes are REQUIRED to agree with the table.  (Issue
             1.4)

   4.4.21    Changed "queued-job-count" from OPTIONAL to RECOMMENDED.
             (Issue 1.14)
ToP   noToC   RFC2566 - Page 171
   4.4.28    Clarified that the implementation supplied value for the
             "multiple-operation-time-out" attribute SHOULD be
             between 30 and 240 seconds, though the implementation
             MAY allow the administrator to set values, and MAY allow
             values outside this range.  (Issue 1.28)

   5.1,      Clarified Client Conformance that if a client supports
   5.2.5     an attribute of 'text' attribute syntax, that it MUST
             support both the textWithoutLanguage and the
             textWithLanguage forms.  Same for 'name' attribute
             syntax.  Same for an IPP object (Issue 1.48)

   6.5,      Added new section to allow Attribute Groups to be
   12.8      registered as extensions for being passed in operation
             requests and responses.  (Issue 1.25)

   7.        Updated the table of text and name attributes to agree
             with Section 4.2.

   8.5       Added a new section RECOMMENDING that the Get-Jobs
             SHOULD return non-IPP jobs whether or not assigning them
             a job-id and job-uri.  Also RECOMMENDED generating, if
             possible, job-id and job-uri and supporting other IPP
             operations on foreign jobs as an implementer option.
             (Issue 1.32)

   9.        Updated document references.

   13.1.4.14 Clarified 'client-error-charset-not-supported' that
             'utf-8' must be used for any 'text' or 'name' attributes
             returned in the error response (Issue 1.19).

   13.1.5.9  Added a new error code 'server-error-job-canceled'
             (0x0508) to be returned if a job is canceled by another
             client or aborted by the IPP object while the first
             client is still sending the document data.  (Issue 1.29)

   15.3,     Moved these sections recommending operation processing
   15.4      steps to the new Implementer's Guide (informational).
             There indicated that all of the error checks are not
             required, so an IPP object MAY be forgiving and accept
             non-conforming requests.  However, a conforming client
             MUST supply requests that would pass all of the error
             checks indicated.  (Issue 1.21)
ToP   noToC   RFC2566 - Page 172
   16        Changed directory schema attributes from REQUIRED to
             RECOMMENDED.  Changed some of the OPTIONAL to
             RECOMMENDED to agree with the SLP template.  Changed the
             "charset-supported" and "natural-language-supported"
             from REQUIRED to OPTIONAL.  Recommended that the names
             be the same in a directory entry as the IPP attribute
             names. (Issue 1.53)
ToP   noToC   RFC2566 - Page 173
18.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.