IPP> MOD - Updated Issues List, 1.3, for Model document

IPP> MOD - Updated Issues List, 1.3, for Model document

IPP> MOD - Updated Issues List, 1.3, for Model document

Tom Hastings hastings at cp10.es.xerox.com
Tue Oct 6 13:55:05 EDT 1998


I've posted an updated Issue list, version 1.3.  I've only proposed answers
for the issues relating to the Model document based on our discussions and
agreements at the August and September meetings and the DL discussions.

I'd like to start discussing the text for the resolutions at the telecon,
tommorrow, Wed, Oct 7, 10-12 PDT (1-3 EDT).

I've attached a plain text version with the "Discussion" section deleted
from each issue.

The files are available at:

ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-mod-1.3.doc
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-mod-1.3.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-mod-1.3.txt

Please start any discussion about any specific issue on the DL.  Please
include the usual "MOD" followed by the Issue number and something
descriptive.  For example:  

   MOD Issue 1.10 - Case sensitiveness in URLs

Please do NOT discuss more than one issue in a single mail message.
(So don't reply to this mail message).

Thanks,
Tom





                      IPP Issues List - Model only

Editor: Carl-Uno Manros and Tom Hastings
File:  ipp-issues-list-mod-1.3.doc
Version: 1.3
Date: October 6, 1998

This document contains the issues related to the IPP/1.0 Model and
Semantics, dated June 30, 1998.  A few resolutions also affect the
IPP/1.0 Transport and Encoding, dated June 30, 1998 (referred to as
PRO).

This document is prepared by the Printer Working Group (PWG), in
accordance with the editing rules that apply to PWG documents. The
information in this document will be continuously updated and replaced
as decided in the meetings, telecons, and e-mail discussions of the PWG.
The document is made freely available also to non-members of the PWG,
but no guarantee is given that the content of this document is fully
correct and consistent with the official documents on IPP from the IETF.

This version includes questions raised on the IPP DL between July 1 and
September 30, 1998 including the Bake-Off held September 23-25, 1998.

All references are to the June 30, 1998 drafts.

The purpose of this document is to collect information about
implementation questions and issues against the current IPP draft
documents.  Allowable questions and issues are about things like
suspected errors, inconsistencies, or needs for further clarifications.
Questions about extensions or functional changes to the drafts are dealt
with in the overall IPP development activities and are outside the scope
of this document. Please note that even if a question does get listed,
the PWG might decide that it is outside the scope of the IPP Issues List
and remove it in a later version.

A separate IPP Implementer's Guide (IIG) will be developed which
contains advice to implementers that supplements the standards track
documents.  It will contain advice to implementers that goes beyond the
exact IPP conformance requirements, e.g. how to ensure interoperability
with earlier versions of Internet components, or even early
implementations of IPP itself.  Section 16 of MOD and most of section 4
of PRO will be moved to the IPP.  Also the conformance language of MUST,
SHOULD, and MAY will be removed from the IPP.  The publication of the
IIG may be as an informational RFC along with the other IPP documents,
or may remain as a PWG document.  Which form of publication is TDB.

When the disposition of a question or issue in the IPP Issues List is of
the form of information suitable for the IIG, rather than clarifications
of the IPP standard (MOD or PRO), it will be put into the IIG.

Each new Question on the IPP DL has been listed in a separate table.
Added in the table is also one section called Discussion, which reflects
comments back from other IPP DL participants.  When the PWG has come up
with an agreed Answer to the Question, it is reflected in the Answer
section of the table.  Before an issue is completely resolved, the exact
text for the MOD, PRO, or IIG will be included in the Answer section for
review and approval, including which document(s) will be changed.


IPP Issues List - Model only
                           TABLE OF CONTENTS

1 Change History for Model and Encoding/Transfer documents...........4
 Change History for the IPP Model and Semantics document.............4
2 Model & Semantics..................................................6
 1.1  xxx-supported and PDL-only supported features..................6
 1.2  Identifying document-format dependent JT attributes............7
 1.3  Validating type 3 keyword | name attributes....................9
 1.4  Are "document-format-default" and "document-format-supported.
 REQUIRED Printer Description attributes?...........................10
 1.5  What charset conversion is required for Get-xxx requests?.....11
 1.6  Should we add "pages-per-minute" Printer Description attribute to
 IPP-MOD, Directory, and SLP?.......................................13
 1.7  Should Validate-Job remain a REQUIRED operation?..............14
 1.8  Is it ok for an IPP Printer to restrict Create-Job, Send-
 Document, and Send-URI to one document?............................14
 1.9  Requirements for "printer-up-time" versus "time-at-creation",
 "time-at-processing", and "time-at-completed?......................15
 1.10  Case sensitivness in URLs....................................16
 1.11  No response to a Cancel-Job operation........................16
 1.12  Cancel-Job response to a 'completed' job.....................17
 1.13  Job-attribute response to Hold-Job, Release-Job, Restart-Job.18
 1.14  Should "queued-job-count" be REQUIRED?.......................19
 1.15  Should "queued-job-count" not include 'pending-held' jobs?...19
 1.16  Empty Job Template attribute group in a Print-Job request....19
 1.17  Empty groups in responses....................................20
 1.18  Returning Unsupported attributes in Get-Xxxx operations......21
 1.19  What charset to return when an unsupported charset is requested?
  ...................................................................21
 1.20  The 'resolution' attribute syntax is not two bytes...........23
 1.21  Position of the target operation attributes in requests......23
 1.22  A Paused printer may never return a response to Print-job until
 Resumed............................................................24
 1.23  Returning job-uri and job-id when "job-template" attributes are
 requested..........................................................24
 1.24  Definition of 'successful-attributes-substituted-or-ignored' and
 unsupported attribute values in Get-Xxxx operations................25
 1.25  Can new attribute groups be added through registration?......26
 1.26  What about unsupported attribute syntaxes?...................28
 1.27  How staple multiple documents as one document, but start each
 document on a new sheet?...........................................30
 1.28  What MUST an IPP object do if Create-Job never gets an Add-
 Document or Send-Document with 'last-document' set to 'true'?......30
 1.29  What does an IPP Printer return in a Print-Job response if the
 job was canceled by another client before the first client had
 supplied all of the data?..........................................33
 1.32 Listing of jobs not submitted by IPP?.........................36
 1.33 Equality between different syntaxes?..........................37
 1.34 Equality between .natural language. tags?.....................40
 1.35 Names for enums?..............................................40
 1.36 Request-id in response when validation fails?.................41
 1.37 None value for empty sets.....................................43
 1.38 Syntax for boolean?...........................................43
 1.39 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........45
 1.40 HTTP server resource?.........................................46
 1.41 Empty attribute and delimiter?................................46

                                                                       2


IPP Issues List - Model only
 1.42 Spooling jobs?................................................48
 1.43 Target URI?...................................................48
 1.44 Target URI  and HTTP URI?.....................................49
 1.45 text/name with language?......................................49





















































                                                                       3


IPP Issues List - Model only


1  Change History for Model and Encoding/Transfer documents

We agreed that the Model and Semantics (MOD) and the Encoding/Transfer
documents (PRO) should have a change history that lists the substantive
changes from the June 30 document.  It should also contain major
clarifications, but not list every minor clarification.  This section
contains copies of those change histories.

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.  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.


Section Description

3.1.2   Clarify that the IPP object SHOULD NOT validate
16.3.3  the range of the request-id being 1 to 2**31-1,
        but accepts and returns any value.  Clients MUST
        still keep in the range though.  (Issue 1.36)

3.2.4   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 Cancel-Job MUST be rejected if the
        job is in 'completed', 'canceled', or 'aborted'
        job states.  (Issue 1.12)

4.1.1.3 Added sections about comparing textWithLanguage
4.1.2.3 and textWithoutLanguage indicating that the
        explicit language MUST match the implicit
        language.  Same for comparing nameWithLanguage and
        nameWithoutLanguage.  A keyword value never
        matches either type of value, even if the language
        is 'en-us'.  (Issue 1.33 and 1.34)

4.1.5   Clarified regarding the case-insensitivity of
        URLs.  (Issue 1.10)

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

4.4.21  Changed "queued-job-count" from OPTIONAL to
        RECOMMENDED.  (Issue 1.14)





                                                                       4


IPP Issues List - Model only

8.5     Added a new section RECOMMENDING listing non-IPP
        jobs using Get-Jobs whether or not assigning them
        a job-id and job-uri.  Leave assigning job-id and
        job-uri and supporting other IPP operations on
        foreign jobs as an implementer option.  (Issue
        1.32)

14.1.2. Clarified that an IPP object MUST return
2       'successful-ok-ignored-or-substituted-attributes'
and     (0x1), rather than 'successful-ok' (0x0), when a
Get-xxx client supplied unsupported attributes as values
operati of the 'requested-attributes' operation attribute.
ons     (Issue 1.24)

14.1.5. Added a new error code 'server-error-job-canceled'
9       (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)






































                                                                       5


IPP Issues List - Model only


2  Model & Semantics



Question
          1.1  xxx-supported and PDL-only supported
          features

          For each job template attribute there is the
          associated default and supported values. I have a
          question about the xxx-supported values. Imagine
          a printer that say supports binding which may be
          controlled by various PDL commands, but does not
          support controlling binding via the IPP
          finishings job template attribute. Should the
          printer response to finishings-supported include
          binding or not? I assume that it should not
          include binding as this would give the idea to
          the client that binding can be controlled with
          the finishings attribute. Thus, xxx-supported is
          not intended to indicate printer capabilities,
          but rather support for the IPP attributes. Is
          this correct?
                    Stuart Rowley

Answer    Correct.  The values of "xxx-supported"
8/19/199  attributes MUST not include values that are only
8         supported in the PDL data stream.  The values do
          include values that are supported in both the
          protocol and the PDL data stream, as well as
          values that are supported only in the protocol.
          The values MAY also include actions carried about
          manually by an operator on a completed job, such
          as stapling or bursting. Yes, further attributes
          may be added in the future. Capability might be
          provided by post processing outside the printer.

          No change to MOD.  Add question and answer to FAQ



















                                                                       6


IPP Issues List - Model only

Question
          1.2  Identifying document-format dependent JT
          attributes

          It looks like the problem discussed in "document-
          format-supported" [MOD needs clarification],
          http://www.findmail.com/list/ipp/showthread.html?
          num=3864 was addressed in the new MOD,
          ftp://ftp.ietf.org/internet-drafts/draft-ietf-
          ipp-model-10.txt June 30, 1998.  The new words
          say:

          "If the Printer object does distinguish between
          different sets of supported values for each
          different document format specified by the
          client, this specialization applies only to the
          following Printer object attributes:

          - Printer attributes that are Job Template
          attributes ("xxx-default" "xxx-supported", and
          "xxx-ready" in the Table in Section 4.2),
          - "pdl-override-supported",
          - "compression-supported",
          - "job-k-octets-supported",
          - "job-impressions-supported,
          - "job-media-sheets-supported"
          - "printer-driver-installer",
          - "color-supported", and
          - "reference-uri-schemes-supported"

          "The values of all other Printer object
          attributes (including "document-format-
          supported") remain invariant with respect to the
          client supplied document format (except for new
          Printer description attribute as registered
          according to section 6.2).

          While this new wording gets around the problem, I
          think it presents a poor model.  It blatantly
          violates Second Normal Form, in that some Printer
          attributes depend on the (Printer identifier,
          document-format) tuple, while others depend only
          on the Printer identifier.  The model says that
          all these attributes, including those that vary
          with document-format (e.g., number-up), are
          attributes of the Printer class of objects.  But
          the implication is that each real-wold printer
          maps to a whole set of Printer object instances,
          selected by document-format.  Attributes (e.g.
          printer-name) which don't vary with document-
          format are redundantly stored in each instance.
          Updates to attributes that don't vary with
          document-format (e.g. printer-state) require
          visiting all the instances.



                                                                       7


IPP Issues List - Model only

          A better model would split the existing Printer
          into two classes of objects:  1) a new, reduced
          Printer, and 2) something else that could be
          called "Interpreter".  Then the attributes can be
          normalized between these two new classes.
          Attributes that don't vary with document-format
          are assigned to the Printer.  Each real-world
          printer maps to one instance of Printer.
          Attributes that do vary with document-format are
          assigned to Interpreter.  Each Printer instance
          contains one or more Interpreter instances,
          selected by document-format.

          I know that IPP doesn't claim to be truly object-
          oriented.  But I think considerations like this
          are important for a few reasons:

          - IPP looks object-oriented, with terms like
          Object, and attribute, and Operation bandied
          about.  It will lead to confusion if the IPP
          model is anti-object-oriented.  Let's not call
          Printer an object if it represents something
          other than what an object is commonly understood
          to be.

          - Many implementors are likely to use OO methods.
          (How about a poll of current implementors?)  It
          would sure be nice if the IPP model could map
          easily to an OO design and implementation.

          - Although an implementor's design could split up
          these classes internally and still meet the
          existing spec, there is some value in having the
          implementation, the design, and the model trace
          cleanly back to the real world.
          Carl Kugler

Answer    In IPP v1.0, other objects are .hidden.. We might
8/19/199  consider this for a future version.  No change to
8         MOD.

















                                                                       8


IPP Issues List - Model only


Question
          1.3  Validating type 3 keyword | name attributes

          In the Job Template Attributes there are
          attributes that can be a type3 keyword or a name
          (job-hold-until, job-sheets, and media).  As I
          read the spec, these attributes are usually type3
          keywords but can optionally be changed at the
          printer to a name type.  Is this correct or did I
          miss something in the spec?

          My question is how does an IPP client know which
          type to send?  If the wrong type is sent, what
          should the expected reply be?
                    Rajesh Chawla

Answer    Section 16.4.3 needs to be clarified.  The
8/19/199  sentence should only be talking about the case of
8         a value that is too long, but is one of the
          expected attribute syntaxes (keyword,
          nameWithLanguage, or nameWithoutLanguage). After
          examining the question, the group does not agree
          with Carl Kugler.s last paragraph as an attempted
          answer. Bob Herriot will draft a proposed
          response for this issue, and submit it to for
          consideration by the group.































                                                                       9


IPP Issues List - Model only


Question
          1.4  Are "document-format-default" and "document-
          format-supported. REQUIRED Printer Description
          attributes?

          The table in Section 4 says that "document-
          format-default" and "document-format-supported"
          are REQUIRED, but the descriptions of those
          attributes in sections 4.4.18 and 4.4.19 do not
          say REQUIRED.

          I believe that 4.4.18 and 4.4.19 should be fixed
          by adding REQUIRED to agree with the table, like
          the other attributes that are REQUIRED.

          These two attributes are so fundamental to the
          description of a Printer object that the fix
          should NOT be to remove REQUIRED from the table.
                    Tom Hastings

Answer    Update sections 4.4.18 and 4.14.19 to indicate
8/19/199  that the "document-format-default" and "document-
8         format-supported" Printer Descriptions attributes
          are REQUIRED to agree with the table in Section
          4. The group agreed to Tom Hastings.s suggestion
          proposed in the Question.































                                                                      10


IPP Issues List - Model only



Question
          1.5  What charset conversion is required for Get-
          xxx requests?

          How should the server handle the situation where
          the "attributes-charset" of the response itself
          is "us-ascii", but one or more attributes in that
          response is in the "utf-8" format?

          Consider a case where a client sends a Print-Job
          request with "utf-8" as the value of "attributes-
          charset" and with the "job-name" attribute
          supplied.  Later another client
          sends a Get-Job-Attribute or Get-Jobs request.
          This second request contains the "attributes-
          charset" with value "us-ascii" and "requested-
          attributes" attribute with
          exactly one value "job-name".

          According to the IPP-Mod document (section
          3.1.4.2), the value of the "attributes-charset"
          for the response of the second request must be
          "us-ascii" since that is the charset
          specified in the request.  The "job-name" value,
          however,  is in "utf-8" format.  Should the
          request be rejected even though both "utf-8" and
          "us-ascii" charsets are supported by the server?
          or should the "job-name" value be converted to
          "us-ascii" and return "successful-ok-conflicting-
          attributes"  (0x0002) as the status code?
                    Van Dang
























                                                                      11


IPP Issues List - Model only

Answer    An IPP object that supports both utf-8 (REQUIRED)
8/19/199  and us-ascii, the second paragraph of section
8         3.1.4.2 applies so that the IPP object MUST
          accept the request, perform code set conversion
          between these two charsets with "the highest
          fidelity possible" and return 'successful-ok',
          rather than a warning 'successful-ok-conflicting-
          attributes, or an error.

          Also we observed that is would be smarter for a
          client to ask for 'utf-8', rather than 'us-ascii'
          and throw away characters that it doesn't
          understand.
          The current document addresses this Question
          already. The printer will do the best it can to
          convert between each of the character sets that it
          supports--even if that means providing a string of
          question marks because none of the characters are
          representable in US ASCII. [Some people noted that
          the problem is not likely to occur in most
          practical situations.]

          No change to MOD.  Add the above discussion to
          the IIG.
































                                                                      12


IPP Issues List - Model only


Question
          1.6  Should we add "pages-per-minute" Printer
          Description attribute to IPP-MOD, Directory, and
          SLP?

          I recently noticed there is no pages-per-minute
          attribute in IPP. I noticed this first when
          reviewing the draft printer scheme for SLP
          (draft-ietf-srvloc-printer-scheme-02.txt). The
          printer scheme seems to inherit it's attribute
          definitions from IPP. I think ppm is one of the
          most fundamental attributes in terms of printer
          selection. I'm sure this must have been discussed
          at some point during IPP development, probably at
          a time when I wasn't paying much attention to the
          mail list. I do remember a discussion about a
          cost attribute that was eliminated because it was
          deemed too qualitative. But ppm is quantitative
          and universal in advertising printers. So, can
          someone explain why it is not an IPP printer
          attribute?  And, for those familiar with the SLP
          printer scheme effort, why is it not part of the
          SLP printer scheme?
                    Angelo Caruso

Answer    Such an attribute should be registered.  Perhaps
8/19/199  call it "pages-per-minute".  Also clarify that
8         the number used is not exact, but is what is used
          in the promotional literature to describe the
          device.  Even devices that are not page printers
          are described in pages per minute in such
          literature.

          That attribute should also be added to the list
          of directory attributes in section 17 of IPP-MOD,
          "APPENDIX E: Generic Directory Schema.

          That attribute should also be added to the SLP
          Schema too.

          [The group feels that this Question does not
          belong in the Issues List. The Question will be
          removed.] Because the definition of .pages-per-
          minute. is so varied--based on quality, color,
          page content, etc.--a single-valued attribute
          will not be added. Instead, people are encouraged
          to generate a proposal for addressing this issue
          as a future registration proposal.









                                                                      13


IPP Issues List - Model only

Question
          1.7  Should Validate-Job remain a REQUIRED
          operation?

          Is it really necessary to keep the "Validate-Job"
          operation as a MUST to implement? The "Get-
          Printer-Attributes" operation seems to provide
          all the functionality that is needed.
                    Carl-Uno Manros

Answer    Keep Validate-Job as a REQUIRED operation.  The
8/19/199  September .98 bake off confirmed that every
8         implementation had implemented it.  The intention
          is that the Print-Job code can be re-used for
          Validate-Job, with the only difference being that
          no data is sent and no job attributes are
          returned.
          Yes, it is really necessary to keep the
          .Validate-Job. operation as a MUST to implement.

          No change to MOD.



Question
          1.8  Is it ok for an IPP Printer to restrict
          Create-Job, Send-Document, and Send-URI to one
          document?

          Can you implement the operations "Create-Job",
          "Send-Document" and "Send-URI", without the need
          to support multiple documents? This could be
          useful for environments where you have long jobs,
          but do not need support for multiple documents.
                    Carl-Uno Manros

Answer    If you support Create-Job, Send-Document (and
8/19/199  Send-URI), then you MUST support multiple
8         documents.  Thus a client can determine if an IPP
          Printer supports multiple documents by querying
          the Printer's "operations-supported" attribute.
          No change to MOD.


















                                                                      14


IPP Issues List - Model only


Question
          1.9  Requirements for "printer-up-time" versus
          "time-at-creation", "time-at-processing", and
          "time-at-completed?

          What was the rationale for making the "printer-
          up-time" attribute a REQUIIRED attribute,
          considering that the other 3 attributes "time-at-
          creation", "time-at-processing", and "time-at-
          completed", with which it is associated, are all
          OPTIONAL?
                    Carl-Uno Manros

Answer    The group agreed that Harry.s response (contained
8/19/199  in the document) will be re-worded and used as
8         the answer.

          No change to MOD.







































                                                                      15


IPP Issues List - Model only


Question
          1.10  Case sensitivness in URLs

          Which parts of a URL are case-insensitive and
          which parts are case-sensitive?
                    IPP Bake Off

Answer    In order to address the interoperability of URIs
9/30/199  between clients, IPP objects, and directories, we
8         agreed at the Savannah GA IPP meeting, 9/30/1998,
          to the following:
          The URI spec allows some portions of a URI to be
          case-sensitive in some implementations.
          Therefore, the IIG will:
          1.recommend to the System Administrator to
            configure Printer URIs using all lower case
            where possible
          2.recommend to implementers of IPP Printers to
            generate Job URIs that are all lower case where
            possible
          3.recommend, but not require, an IPP Printer
            implementation to support case-insensitive
            Printer and Job URIs
          4.require clients to preserve the case of URIs
            received from an IPP response for subsequent
            IPP requests
          5.require System Administrators that have
            implementations where IPP Printer URIs are
            case-sensitive to configure printers that do
            not differ in case only, i.e., do not configure
            'http://.../Printer1' and
            'http://.../printer1'.
          Since the case of URIs is covered in the URI
          standard, the above text will be put into the
          IIG, not MOD.



Question
          1.11  No response to a Cancel-Job operation

          Some implementations do not send back an HTTP
          response to the Cancel-Job operation.
                    IPP Bake Off

Answer    Not returning a response to a Cancel-Job
9/30/199  operation is a bug in the implementation.
8         No change will be made to the MOD, PRO, or IIG
          documents.










                                                                      16


IPP Issues List - Model only


Question
          1.12  Cancel-Job response to a 'completed' job

          Implementations react differently to .Cancel-
          Job..  Some return a client-error-not-possible
          error as IPP-MOD says.  Some return success-ok
          and leave the job in the 'completed' state.  Some
          return success-ok and delete the job immediately,
          removing it from the job history.  What is
          correct response when job is already completed?
          Should Cancel-Job result in deletion of job
          history?
                    IPP Bake Off

Answer    Keep Cancel-Job spec as MOD section 3.3.3.2 says:
9/30/199       If the job is already in the 'completed',
8              'aborted', or 'canceled' state, or the
               'process-to-stop-point' value is set in the
               Job's "job-state-reasons" attribute, the
               Printer object MUST reject the request and
               return the 'client-error-not-possible' error
               status code.

          The first line of MOD section 3.3.3 will be
          changed from:
               This REQUIRED operation allows a client to
               cancel a Print Job any time after a create
               job operation.

          to:
               This REQUIRED operation allows a client to
               cancel a Print Job from the time the job is
               created up to the time it is completed,
               canceled, or aborted.

          so that it does not appear to contradict section
          3.3.3.2.




















                                                                      17


IPP Issues List - Model only

Question
          1.13  Job-attribute response to Hold-Job,
          Release-Job, Restart-Job

          The Set 1 Spec specifies that the three job
          operations (Hold-Job, Release-Job, and Restart-
          Job) MUST return the "job-state", and, if
          supported, the "job-state-reasons" attributes.
          However, implementations did not return any job
          attributes in the response.

          Should we change the spec to not require any job
          attributes to be returned?
          Should we allow any to be returned?
          Should a Restart-Job implementation be required
          to return the same job attributes that Print-Job
          returns ("job-uri", "job-id", neither of which
          can change, "job-state" which could be 'pending',
          'pending-held', or 'processing')
          Should Restart-Job implementation be allowed to
          return the same optional job attributes that
          Print-Job returns ("job-state-reasons", "job-
          state-message", and "number-of-intervening-
          jobs")?
                    IPP Bake Off

Answer    Remove Group 3 from the spec for the responses
9/30/199  for all six operations so that none of them
8         return job or printer attributes.

          The IIG cannot mention these Set 1 operations,
          since the IIG is going to go become an Internet-
          Draft along with MOD and PRO, but Set 1 will
          become and Internet-Draft after IPP 1.0 is
          approved by the IESG.























                                                                      18


IPP Issues List - Model only


Question
          1.14  Should "queued-job-count" be REQUIRED?

          Should we make the printer description attribute
          .queued-job-count. a required attribute?
                    IPP Bake Off

Answer    Recommend that "queued-job-count" be implemented.
9/30/199
8         Change MOD Section 4.4 Table to add SHOULD to
          last column entry for "queued-job-count".

          Add the word "RECOMMENDED" as the second word in
          the first sentence of MOD section 4.4.21.

          In the IIG, indicate that the reason that
          "queued-job-count" is RECOMMENDED, is that some
          clients look at that attribute alone when
          summarizing the status of a list of printers,
          instead of doing a Get-Jobs to determine the
          number of jobs in the queue.



Question
          1.15  Should "queued-job-count" not include
          'pending-held' jobs?

          The current Model document specifies that
          "queued-job-count" includes jobs that are in the
          'pending-held' state, as well as 'pending',
          'processing', and 'processing-stopped'.  But
          these jobs are not in competition (yet) for the
          printer, until a client performs a Release-Job
          operation on them.
                    IPP Bake Off

Answer    No change to MOD.
9/30/199
8         The IIG will indicate that the "queued-job-count"
          is not a good measure of how busy the printer is
          when there are held jobs.  Also indicate that a
          future registration could be to add a "held-job-
          count" (or an "active-job-count") Printer
          Description attribute.



Question
          1.16  Empty Job Template attribute group in a
          Print-Job request

          If a client does not have any job template
          attributes to send (or does not support ANY job
          template attributes), does it still have to send
          the empty group for job template attributes?
                    IPP Bake Off




                                                                      19


IPP Issues List - Model only

Answer    An IPP object MUST accept both forms in a request
9/30/199  and that a client MUST accept both forms in a
8         response.  PRO lines 24-267:

               The syntax allows an xxx-attributes-tag to
               be present when the xxx-attribute-sequence
               that follows is empty. The syntax is defined
               this way to allow for the response of Get-
               Jobs where no attributes are returned for
               some job-objects.  Although it is
               RECOMMENDED that the sender not send an xxx-
               attributes-tag if there are no attributes
               (except in the Get-Jobs response just
               mentioned), the receiver MUST be able to
               decode such syntax.

          There doesn't seem to be any reason to specify in
          MOD whether or not empty groups can be omitted by
          a sender, since a different syntax might have
          different rules about empty groups.  Therefore,
          no changes to either MOD or PRO.

          The IIG will indicate that the terms "sender"
          means client for a request and IPP object for a
          response.  Also that an IPP object SHOULD be
          forgiving in accepting requests in order to work
          with the most clients.  On the other hand,
          clients should be conforming in requests so that
          they will work with the most IPP objects.



Question
          1.17  Empty groups in responses

          MAY an IPP object omit an empty group, such as a
          Job Attributes or Printer Attributes group
          entirely in a response for any operation if there
          are no attributes to return?
                    IPP Bake Off

Answer    No change to MOD or PRO, see Issue 1.17.
9/30/199
8















                                                                      20


IPP Issues List - Model only


Question
          1.18  Returning Unsupported attributes in Get-
          Xxxx operations

          Inconsistent wording in the Model & Semantics
          document about whether you must return
          unsupported attributes in Get-Printer-Attributes,
          Get-Job-Attributes, and Get-Jobs in the
          Unsupported Attributes group.
                    IPP Bake Off

Answer    An IPP object MAY return requested attributes
9/30/199  that are unsupported in Group 2 in Get-Printer-
8         Attributes, Get-Jobs, and Get-Job-Attributes
          responses, but a client cannot depend on it.

          Add the following sentence:

               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.

          to MOD 3.2.5.2 Get-Printer-Attributes response,
          3.2.6.2 Get-Jobs response, and 3.3.4.2 Get-Job-
          Attributes response:

               Group 2: Unsupported Attributes

                    This is a set of Operation attributes
                    supplied by the client (in the request)
                    that are not supported by the Printer
                    object or that conflict with one
                    another (see sections 3.2.1.2 and 16).

          Add a statement to the IIG that the client cannot
          depend on getting unsupported attributes returned
          in the Unsupported Attributes group of Get-Xxxx
          responses that the client requested, but are not
          supported by the IPP object.  However, such
          unsupported requested attributes will not be
          returned in the Job Attributes or Printer
          Attributes group (since they are unsupported).



Question
          1.19  What charset to return when an unsupported
          charset is requested?

          What character set should a server use for the
          value when returning the value of an unknown or
          badly formed attribute?  Should it be the IPP
          Printer's configured charset or  UTF-8?
                    IPP Bake Off


                                                                      21


IPP Issues List - Model only

Answer    The IPP object returns any 'text' or 'name'
9/30/199  attributes using the Printer's "charset-
8         configured" charset and the 'client-error-
          charset-not-supported' error status code.

          Clarify MOD section 3.1.4.1 third paragraph by
          adding:
               and any 'text' or 'name' attributes using
               the Printer's "charset-configured" charset.

          to the end of:
               If the Printer object does not support the
               client supplied charset value, the Printer
               object MUST reject the request and return
               the 'client-error-charset-not-supported'
               status code.

          Clarify MOD section 14.1.4.14 'client-error-
          charset-not-supported' by replacing:
               the Printer MUST reject the operation and
               return this status (see Section 3.1.4.1).
          with:
               the Printer MUST reject the operation and
               return this status and any 'text' or 'name'
               attributes using the Printer's "charset-
               configured" charset (see Section 3.1.4.1).

          Add to the IIG:  Since such an error is a client
          error, rather than a user error, the client
          should check the status code first so that it can
          avoid displaying any other returned 'text' and
          'name' attributes that are in an unexpected
          charset.
























                                                                      22


IPP Issues List - Model only


Question
          1.20  The 'resolution' attribute syntax is not
          two bytes

          IPP-MOD says that resolution should be two bytes.
          This is wrong, see syntax.
                    IPP Bake Off

Answer    MOD section 4.1.15 'resolution' says:
9/30/199       It consists of 3 integers:
8         Since the third integer is only a byte according
          to PRO, change the above MOD sentence to:
               It consists of 3 values:



Question
          1.21  Position of the target operation attributes
          in requests

          Although IPP-MOD says that target (Job-URI,
          Print-URI plus Job-Id or Printer-URI) MUST be the
           rd
          3   operation attribute, several implementations
          do not have it in that place or not at all. Can
          we relax that requirement or should it be
          strictly enforced?
                    IPP Bake Off

Answer    Keep MOD requiring the client to supply the
9/30/199  target operation attribute and in the correct
8         position.  However, the IPP object SHOULD NOT
          check for it being present and in the correct
          position, following the philosophy that clients
          should be conforming and servers should be
          forgiving.

          Move Section 16 (Appendix D) to the IIG.  Keep
          the error check as something that a test suite
          for clients might include, but remove the error
          check for recommended IPP object behavior.



















                                                                      23


IPP Issues List - Model only


Question
          1.22  A Paused printer may never return a
          response to Print-job until Resumed

          Test cases 2.6-2.7 and 2.9 in TS1 seems to expect
          a response before all the data has been sent.
          This results in  a deadlock situation with some
          printers which are still waiting for all the data
          to first be delivered.
                    IPP Bake Off

Answer    No change to MOD or PRO.  All printers will
9/30/199  eventually flow control a Print-Job data when its
8         buffers and spool space, if it spools, fills up.
          The Printer should not return an error, since
          either the printer will be resumed and/or the
          spool space will be freed up as jobs print.

          Fix the script to still test sending a Print-Job
          while the printer is paused, but figure out a way
          for the script not to hang, if the Printer flow
          controls the script off.

          Add the above discussion to the IIG.



Question
          1.23  Returning job-uri and job-id when "job-
          template" attributes are requested.

          TS1 is saying that the job attributes job-uri and
          job-id should be returned in the response to a
          Get-Jobs operation with requested-attributes of
          <job-template>, but job-uri and job-id are not in
          the job-template group.
                    IPP Bake Off

Answer    The "job-uri" and "job-id" attributes are not
9/30/199  job-template attributes.  This is a bug in the
8         script.  Fix the script.


















                                                                      24


IPP Issues List - Model only


Question
          1.24  Definition of 'successful-attributes-
          substituted-or-ignored' and unsupported attribute
          values in Get-Xxxx operations

          Is it required to return a status of 01 when a
          bogus attribute is included as one of requested
          attributes of a Get-Jobs operation? Technically,
          this situation is not covered by the definition
          of status x0001. The first part of the definition
          says .some attributes were ignored.. The
          attribute being .requested-attributes. was not
          ignored. What was ignored is one of the bvalues
          (bogus-attribute) of the attribute. The second
          half of the definition is .unsupported values
          were substituted with supported values.. this
          wasn.t done either, since the unsupported value
          was ignored. So this status code does not apply.
          Recommended that the definition gets beefed up to
          include something like .or unsupported values
          were ignored..
                    IPP Bake Off


































                                                                      25


IPP Issues List - Model only

Answer    While the IPP object is NOT REQUIRED to return
9/30/199  requested attributes that are unsupported (see
8         Issue 1.18), it is REQUIRED to return the
          'successful-attributes-substituted-or-ignored'
          success code, rather than 'successful-ok'.

          MOD 14.1.2.1 'successful-ok' change:
               The request has succeeded.
          to:
               The request has succeeded and no request
               attributes were substituted or ignored.

          MOD 14.1.2.2 'successful-ok-ignored-or-
          substituted-attributes' clarify that it is used
          for all requests, not just create operations, by
          changing:
               The request has succeeded, but some
               attributes were ignored or unsupported
               values were substituted with supported
               values in order to process the job without
               rejecting it.
          to:
               The request has succeeded, but some
               attributes were ignored or unsupported
               values were substituted with supported
               values or were ignored in order to perform
               the operation without rejecting it.  These
               unsupported attributes or values are
               returned in the Unsupported Attributes group
               of the response.  In the case of Get-Xxxx
               operations when supplied values of the
               "requested-attributes" operation attribute
               are requesting attributes that are not
               supported, the IPP object MUST return this
               status code and MAY return the "requested-
               attributes" attribute in the Unsupported
               Attribute response group (with the
               unsupported values only).



Question
          1.25  Can new attribute groups be added through
          registration?


                    Tom Hastings











                                                                      26


IPP Issues List - Model only

Answer    Yes, so add the following section to Section 6
9/30/199  after Section 6.4 Operation Extensibility:
8              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 [IPP-PRO].

               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 [IPP-PRO].
               IANA will publish approved attribute group
               registration specifications as separate
               files:

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

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



































                                                                      27


IPP Issues List - Model only


Question
          1.26  What about unsupported attribute syntaxes?

          Does the implementation respond as if the
          attribute or value were not supported?  If so,
          then Section 3.2.1.2 should add this condition to
          the list.
                    Tom Hastings

Answer    Clarify the following three categories of
9/30/199  unsupported attributes in section 3.2.1.2:
8              1. The Printer object does not support the
                    named attribute (no matter what the
                    value).
               2. The Printer object does support the
                    attribute, but does not support some or
                    all of the particular values supplied
                    by the client (i.e., the Printer object
                    does not have those values in the
                    corresponding supported values
                    attribute).
          by replacing the above with:
               1. The Printer object does not support the
                    supplied attribute (no matter what the
                    attribute syntax or value).
               2. The Printer object does support the
                    attribute, but does not support some or
                    all of the particular values supplied
                    by the client (i.e., the Printer object
                    does not have those values in the
                    corresponding supported values
                    attribute) or does not support some or
                    all of the particular attribute
                    syntaxes supplied by the client for the
                    value(s) of the named attribute.






















                                                                      28


IPP Issues List - Model only

          Clarify the following paragraph in Section
          3.2.1.2:
               In the case of a supported attribute with
               one or more unsupported values, the Printer
               object simply returns the client-supplied
               attribute with the unsupported values as
               supplied by the client.  This indicates
               support for the attribute, but no support
               for that particular value. If the client
               supplies a multi-valued attribute with more
               than one value and the Printer object
               supports the attribute but only supports a
               subset of the client supplied values, the
               Printer object MUST return only those values
               that are unsupported.
          by replacing "values" with "attribute syntaxes or
          values" to make:
               In the case of a supported attribute with
               one or more unsupported attribute syntaxes
               or values, the Printer object simply returns
               the client-supplied attribute with the
               unsupported attribute syntaxes or values as
               supplied by the client.  This indicates
               support for the attribute, but no support
               for that particular attribute syntax or
               value.  If the client supplies a multi-
               valued attribute with more than one value
               and the Printer object supports the
               attribute but only supports a subset of the
               client supplied attribute syntaxes or
               values, the Printer object MUST return only
               those attribute syntaxes or values that are
               unsupported.

          Clarify that when the spec for an attribute
          specifies more than one attribute syntax, then
          all such specified attribute syntaxes are
          required to be supported in order to support that
          attribute.  So add the following sentence to the
          last paragraph of section 4.1:
               If an attribute specification includes more
               than one attribute syntax in the sub-section
               heading, all such attribute syntaxes are
               required to be supported in order to support
               the attribute.











                                                                      29


IPP Issues List - Model only


Question
          1.27  How staple multiple documents as one
          document, but start each document on a new sheet?

          The 'single-document' value of "multiple-
          document-handling" requires that each document
          not be forced to start on a new sheet.
                    IPP Bake Off

Answer    Deferred.  Such a value can be registered in the
9/30/199  future for use with the "multiple-document-
8         handling" Job Template attribute.



Question
          1.28  What MUST an IPP object do if Create-Job
          never gets an Add-Document or Send-Document with
          'last-document' set to 'true'?

          Should the IPP object close the job after some
          period of time and:
          1. move the job to the 'aborted' state with the
          'aborted-by-system' job-state-reasons value set
          2. move the job to the 'pending-held' state (with
          some new job-state-reason indicating an
          incomplete job, or
          3. move the job to the 'pending' state and print
          the job?

          What if the job never had any Add-Document or
          Send-Document operations, so that the job has no
          documents?
                    IPP Bake Off
























                                                                      30


IPP Issues List - Model only

Answer    Replace the last two paragraphs and three actions
9/30/199  in MOD 3.3.1 with:
8              Since the Create-Job and the send operations
               (Send-Document or Send-URI operations) that
               follow could occur over an arbitrarily long
               periods of time for a particular job, a
               client MUST send another send operation
               within an IPP Printer implementation-defined
               time interval after the receipt of the
               previous request for the job.  An IPP object
               MUST recover from an errant client that does
               not supply a send operation with a "last-
               document" set to 'true', sometime within
               this implementation-defined time interval
               after the most recent Create-Job or send
               operation has been received for the job.
               The implementation-defined time period MUST
               be within one to four minutes.
               Such recovery MAY include any of the
               following recovery actions:

                    1. Assume that the Job is an invalid
                    job, start the process of changing the
                    job state to 'aborted', adding the
                    'aborted-by-system' value to the job's
                    "job-state-reasons" attribute, if
                    supported, and clean up all resources
                    associated with the Job.  In this case,
                    if another send operation is finally
                    received, the Printer responds with an
                    "client-error-not-possible" or "client-
                    error-not-found" depending on whether
                    or not the Job object is still around
                    when the send operation finally
                    arrives.

                    2. Assume that the last send operation
                    received was in fact the last document
                    (as if the "last-document" flag had
                    been set to 'true'), close the Job
                    object, and proceed to process it
                    (i.e., move the Job's state to
                    'pending').

                    3. Assume that the last send operation
                    received was in fact the last document,
                    close the Job, but move it to the
                    'pending-held' to allow an operator to
                    determine whether or not to continue
                    processing the Job by moving it back to
                    the 'pending' state.







                                                                      31


IPP Issues List - Model only

               Each implementation is free to decide the
               "best" action to take depending on local
               policy, the value of "ipp-attribute-
               fidelity", whether any documents have been
               added, whether the implementation spools
               jobs or not, and/or any other piece of
               information available to it.  If the choice
               is to abort the Job object, it is possible
               that the Job object may already have been
               processed to the point that some media sheet
               pages have been printed.













































                                                                      32


IPP Issues List - Model only


Question
          1.29  What does an IPP Printer return in a Print-
          Job response if the job was canceled by another
          client before the first client had supplied all
          of the data?

          Presumably, the IPP Printer returns an error code
          that rejects the request, the job does not come
          into existence?  Must the "job-id" and "job-uri"
          not be re-used (for the next job)?
                    IPP Bake Off

Answer    Add a new server error status code by adding the
9/30/199  following new section:
8              14.1.5.9 server-error-job-canceled (0x0508)

               An error indicating that the job has been
               canceled by an operator or the system while
               the client was transmitting the data to the
               IPP Printer.  If a job-id and job-uri had
               been created, then they are returned in the
               Print-Job, Send-Document, or Send-URI
               response as usual; otherwise, no job-id and
               job-uri are returned in the response.

































                                                                      33


IPP Issues List - Model only


Question  1.30 Correct .job-state. for Job-Submit?
          An IPP client submits a small job via "job-
          submit".  By the time the IPP printer/print
          server is putting together a response to the
          operation, the job has finished printing and been
          removed as an object from the print system.  What
          should the job-state be in the response?
                    Hugo Parra

Answer    No change to MOD.  Add the above discussion to
9/30/199  the IIG.
8












































                                                                      34


IPP Issues List - Model only


Question  1.31 What is the correct syntax for multi-valued
          attributes?
          Each value in a multi-valued attribute includes
          its own value-tag.  It is syntactically possible
          then for each value in the list be of a different
          syntax (integer, uri, nameWithoutLangugage, etc)
          Is this right?  Is this explicitly stated in the
          documentation?  Does it need to be?
                    Hugo Parra

Answer    No change to MOD.  See the last paragraph of
9/30/199  Section 4.1, just before Section 4.1.1 that
8         contains the statement:

               Most attributes are defined to have a single
               attribute syntax.  However, a few attributes
               (e.g., "job-sheet", "media", "job-hold-
               until") are defined to have several
               attribute syntaxes, depending on the value.
               These multiple attribute syntaxes are
               separated by the "|" character in the sub-
               section heading to indicate the choice.
               Since each value MUST be tagged as to its
               attribute syntax in the protocol, a single-
               valued attribute instance may have any one
               of its attribute syntaxes and a multi-valued
               attribute instance may have a mixture of its
               defined attribute syntaxes.

          Add question to the FAQ and discussion to the
          IIG.

























                                                                      35


IPP Issues List - Model only


Question
          1.32 Listing of jobs not submitted by IPP?

          We've talked about list-jobs somehow
          differentiating between jobs submitted through
          IPP and other jobs.  Is there a hard requirement?
          Is it documented?
                    Hugo Parra

Answer    Since both the Get-Jobs and Get-Job-Attributes
9/30/199  operations refer to Section 8 for security, the
8         following new section will be added to section 8,
          after Section 8.4 Restricted Queries:

               8.5 Queries on jobs submitted using non-IPP
               protocols
               If the device that an IPP Printer is
               representing is able to accept jobs using
               other job submission protocols in addition
               to IPP, it is RECOMMEND that such an
               implementation at least allow such "foreign"
               jobs to be queried using Get-Jobs returning
               "job-id" and "job-uri" as 'unknown'.  Such
               an implementation NEED NOT support all of
               the same IPP job attributes as for IPP jobs.
               The IPP object returns the 'unknown' out-of-
               band value for any requested attribute of a
               foreign job that is supported for IPP jobs,
               but not for foreign jobs.

               It is further RECOMMENDED, that the IPP
               Printer generate "job-id" and "job-uri"
               values for such "foreign jobs", if possible,
               so that they may be targets of other IPP
               operations, such as Get-Job-Attributes and
               Cancel-Job.  Such an implementation also
               needs to deal with the problem of
               authentication of such foreign jobs.  One
               approach would be to treat all such foreign
               jobs as belonging to users other than the
               user of the IPP client.  Another approach
               would be for the foreign job to belong to
               'anonymous'.  Only if the IPP client has
               been authenticated as an operator or
               administrator of the IPP Printer object,
               could the foreign jobs be queried by an IPP
               request.  Alternatively, if the security
               policy is to allow users to query other
               users' jobs, then the foreign jobs would
               also be visible to an end-user IPP client
               using Get-Jobs and Get-Job-Attributes.

          Amplify the above discussion in the IIG.




                                                                      36


IPP Issues List - Model only


Question
          1.33 Equality between different syntaxes?

          When checking for equality or containment (e.g.,
          "IF NOT in the Printer object's 'job-hold-until-
          supported' attribute ...") is value type
          considered?  Is a value of type
          'nameWithoutLanguage' considered equal to a value
          of type 'nameWithLanguage' if the default
          language for the context of the
          'nameWithoutLanguage' value is the same as the
          language explicit in the 'nameWithLanguage'
          value?  Can a 'name' match a 'keyword'?
          IF a 'nameWithoutLanguage' value in the
          appropriate natural language context CAN match a
          'nameWithLanguage' value, is there any harm
          (other than a negligible increase in network
          bandwidth consumption) in an application
          promoting ALL 'name' and 'text' attribute values
          to 'nameWithLanguage' and 'textWithLanguage'
          values?
                    Carl Kugler


































                                                                      37


IPP Issues List - Model only

Answer    The following text is to be added to make a new
9/30/199  section under 4.1.1 'text':
8
               4.1.1.3  Matching 'textWithLanguage' and
               'textWithoutLanguage'

               For purposes of matching 'text' values for
               equality in job validation, where a client-
               supplied value for attribute "xxx" is
               checked to see if the value is among the
               values of the Printer's corresponding "xxx-
               supported" attribute, the following match
               criteria apply:

               1.The attribute syntax and value of "xxx"
                 supplied by the client MUST be identical
                 to the attribute syntax and value of one
                 of the values of the corresponding
                 Printer's "xxx-supported" attribute.  For
                 example, the client-supplied 'keyword'
                 'iso-a4-white' does not match the
                 Printer's 'name' 'iso-a4-white', even if
                 the Printer's "natural-language-
                 configured" is 'us-en'.
               2.For purposes of matching 'text'
                 attributes, the attribute value comparison
                 SHOULD include a case-insensitive
                 algorithm and MAY include other
                 equivalencies, such as accent-insensitive
                 matching, depending on language and
                 implementation.
               3.For purposes of matching 'text'
                 attributes, the implicit or explicit
                 natural language of the "xxx" value
                 supplied by the client MUST be the same as
                 the implicit or explicit natural language
                 of the Printer's "xxx-supported"
                 attribute.  For example, a client's
                 nameWithoutLanguage value with an 'en'
                 "attributes-natural-language" will match
                 either a Printer's "xxx-supported value
                 which is (1) 'en' textWithLanguage or (2)
                 textWithoutLanguage with an 'en' "natural-
                 language-configured".  Similarly, a
                 client's 'en' textWithLanguage value will
                 match either a Printer's "xxx-supported
                 value which is (1) 'en' textWithLanguage
                 or (2) textWithoutLanguage with an 'en'
                 "natural-language-configured".
               4.Whether the country part of the natural
                 language has to match depends on
                 implementation.  So a client's 'en' MAY or
                 MAY NOT match a Printer's 'en-us' or 'en-
                 gb'.  Similarly, a client's 'en-us' MAY or
                 MAY NOT match a Printer's 'en'.  A
                 client's 'en-gb' SHOULD NOT match a
                                                                      38
                 Printer's 'en-us'.


IPP Issues List - Model only

Answer    and add the following as a new section 4.1.2.3:
cont.
               4.1.2.3  Matching 'nameWithLanguage' and
               'nameWithoutLanguage'

               For purposes of matching 'name' values for
               equality in job validation, where a client-
               supplied value for attribute "xxx" is
               checked to see if the value is among the
               values of the Printer's corresponding "xxx-
               supported" attribute, the analogous rules
               apply to 'name' attribute values as
               described in Section 4.1.1.3 for 'text'
               attribute values.










































                                                                      39


IPP Issues List - Model only


Question
          1.34 Equality between .natural language. tags?

          Is natural language considered when comparing
          'name' attributes (e.g., "job-originating-user-
          name", "media", "job-hold-until-supported")?
          [Assertion:  ALL 'text' and 'name' attributes
          have an associated natural language, either
          explicitly or implicitly.]  If so, how strict is
          the comparison?  Does "en" match "en-us", for
          example?
                    Carl Kugler

Answer    If the country part of the natural language
9/30/199  differ then they don't match.  If one country
8         part is omitted and the other is explicit, then
          whether they match depends on implementation.
          See answer to 1.33.


Question
          1.35 Names for enums?

          Section 14 (Appendix B) of the "Model and
          Semantics" document includes the following: "The
          name of the enum is the suggested status message
          for US English"

          The name of the enum for unqualified success
          (0x0000) is 'successful-ok'.  Shouldn't its
          corresponding status message be "successful-ok"?
          If so, there is another discrepancy in Appendix A
          of the "Encoding and Transport" document where
          "OK" is used as the status-message for
          'successful-ok'.
                    Hugo Parra

Answer    No change to MOD.  Make the editorial change to
9/30/199  PRO to change the status message from 'OK' to
8         'successful-ok'.



















                                                                      40


IPP Issues List - Model only


Question
          1.36 Request-id in response when validation
          fails?

          Suppose the Printer object, while parsing an IPP
          requests, fails to validate the "request-id" in
          the incoming payload (because the packet was
          incomplete or because the value is not between 1
          and 2**31-1).  The documents indicates that the
          Printer object should return a 'client-error-bad-
          request' status code.  That's fine; now my
          question: What request-id should the Printer
          object include in the response (I'm assuming that
          responses with error status codes must also
          include version, request-id, charset, etc.)?
          Should 0 be used to handle this cases?
                    Hugo Parra







































                                                                      41


IPP Issues List - Model only

Answer    Change the 2nd paragraph of Section 3.1.2:
9/30/199       In addition, every invocation of an
8              operation is identified by a "request-id"
               value. For each request, the client chooses
               the "request-id" which is an integer
               (possibly unique depending on client
               requirements) in the range from 1 to 2**31 -
               1 (inclusive). This "request-id" allows
               clients to manage multiple outstanding
               requests. The receiving IPP object copies
               the client supplied "request-id" attribute
               into the response so that the client can
               match the response with the correct
               outstanding request.

          to:
               In addition, every invocation of an
               operation is identified by a "request-id"
               value. For each request, the client chooses
               the "request-id" which MUST be an integer
               (possibly unique depending on client
               requirements) in the range from 1 to 2**31 -
               1 (inclusive). This "request-id" allows
               clients to manage multiple outstanding
               requests. The receiving IPP object copies
               all 32 bits of the client supplied "request-
               id" attribute into the response so that the
               client can match the response with the
               correct outstanding request, even if the
               "request-id" is out of range.  If the
               request is terminated before the four octets
               of "request-id" are received, the IPP object
               returns a response with a "request-id" of 0.

          Also change 16.3.3 Validate the request
          identifier from:

               The Printer object checks to see if the
               "request-id" attribute supplied by the
               client is in range.  If the value is not
               between 1 and 2**31 - 1 (inclusive), the
               Printer object REJECTS the request and
               returns the 'client-error-bad-request'
               status code in the response.

          to:

               The Printer object SHOULD NOT checks to see
               if the "request-id" attribute supplied by
               the client is in range: between 1 and 2**31
               - 1 (inclusive), but copies all 32 bits.





                                                                      42


IPP Issues List - Model only


Question
          1.37 None value for empty sets

          I have discovered what I consider to be an
          unfortunate decision with regard to the "none"
          value for empty sets?
          The model documens states that the "none" value
          should be used as the value of a 1SetOf when the
          set is empty. In most cases, sets that are
          potentially empty contain keywords so the keyword
          "none" is used, but for the 3 finishings
          attributes, the values are enums and thus the
          empty set is
          represented by the enum 3.  Currently there are
          no other attributes with
          1SetOf values which can be empty and can contain
          values that are not
          keywords.  This exception requires special code
          and is a potential place for bugs. It would have
          been better if we had chosen an out-of-band
          value,
          either "no-value" or some new value, such as
          "none". At this late date, it
          is probably too late to change this, though I
          wonder if other
          implementations have dealt with this special case
          properly.
                    Bob Herriot

Answer    No change to MOD.  A 'none' value for enums is
9/30/199  different than 'none' in keywords. Put a note in
8         the IIG about this difference in handling 'none'
          depending on the attribute syntax.


Question
          1.38 Syntax for boolean?

          In section 4.1.11 the words say that "The
          'boolean' attribute syntax
          is similar to an enum with only two values:
          'true' and 'false'. "
          And in section 4.1.4 the words says "The 'enum'
          attribute syntax is an
          enumerated integer value that is in the range
          from 1 to 2**31 - 1 (MAX)."
          Does this mean, that a boolean attribute got a 32
          bit size value?
          In the protocol document, it says that a boolean
          is a byte size!
                    Henrik Holst







                                                                      43


IPP Issues List - Model only

Answer    Change the description for 'boolean' in Section
9/30/199  4.1.11 from:
8         The 'boolean' attribute syntax is similar to an
          enum with only two values:  'true' and 'false'.

          to:
          The 'boolean' attribute syntax has only two
          values:  'true' and 'false'.
















































                                                                      44


IPP Issues List - Model only


Question
          1.39 Get-Jobs, my-jobs='true', and 'requesting-
          user-name'?

          In section 3.2.6.1 'Get-Jobs Request' I wondered,
          if the attribute
          'my-jobs' is present and set to TRUE, MUST the
          'requesting-user-name' attribute be there to, and
          if it's not present what should the IPP printer
          do?
                    Henrik Holst

Answer    No change to MOD.  Section 8.3 describes the
9/30/199  various cases of "requesting-user-name" being
8         present and not for any operation.  Add question
          to the FAQ with a pointer to Section 8.3.









































                                                                      45


IPP Issues List - Model only

Question
          1.40 HTTP server resource?

          We've established that the "HTTP server resource"
          referred to in the
          document is either 1)  an IPP Printer, or 2) an
          IPP Job. If we
          substitute the words "IPP Printer (or IPP Job)"
          for "HTTP Server
          resource" in the original sentence, we get:

          > Once the IPP Printer (or IPP Job) begins to
          process the HTTP request, it might get the
          reference to the appropriate IPP Printer object
          from either the HTTP URI (using to the context of
          the HTTP server for relative URLs) or from the
          URI within the operation request;  the choice is
          up to the implementation.

          I cannot understand this sentence.  What are the
          words "appropriate IPP
          Printer object" referring to in this sentence?
          Why would a Printer or
          Job object processing an IPP request need a
          "reference to the
          appropriate IPP Printer object"?  What is the
          Printer or Job supposed to
          do with the reference?

          Note:  I realize that the sentence in the
          document says "begins to
          process the HTTP request", not "IPP request".
          However, if the "HTTP
          server resource" processes only the HTTP part of
          the request (and not
          the IPP), then there is no choice to use the URI
          within the IPP
          operation request, so the sentence makes no
          sense.
                    Carl Kugler

Answer    Duplicates Issue 2.14.  This is a PRO issue, not
9/30/199  a MOD issue.
8


Question
          1.41 Empty attribute and delimiter?

          Some server implementations do not add delimiters
          for empty attribute
          group, and some client implementations assumed
          delimiters will always be there even if the
          attribute group is empty. We should make it clear
          if
          delimiter is required if the corresponding
          attribute group is empty.
                    Yuji Sasaki

                                                                      46


IPP Issues List - Model only

Answer    Duplicate of Issue 1.17.
9/30/199
8





















































                                                                      47


IPP Issues List - Model only


Question
          1.42 Spooling jobs?

          Many "print server" products...such as Intel
          NetPort or HP JetDirect...
          has limited resource(i.e memory or HDD capacity),
          so it is impossible to
          "spool" job document. They can support job
          commands(Get-jobs, Get-job-
          attributes, etc), however because of lack of
          spooling capabilities, they
          can handle only one job at a time. Until the
          first job is complete, the
          following jobs cannot be processed. But many IPP
          test suite assumed
          the server can "spool" jobs, so caused many
          errors on my (JCI) IPP print
          server implementation, which has only 128Kbyte
          RAM and of course no HDD.

          Is it required for all IPP servers to MUST be
          able to spool jobs?
                    Yuji Sasaki

Answer    No change to MOD.  It is not required for an
9/30/199  implementation to spool.  Don't run spooling
8         tests on non-spooling printers.  Some of the
          scripts can be fixed so that they do not require
          multiple jobs.



Question
          1.43 Target URI?

          The IPP specification says the "third" operation
          attribute MUST be the
          target URI, however some implementation does not
          include target URI at all, and some others
          includes the URI but not at "third" place.
                    Yuji Sasaki

Answer    REQUIRED for clients to supply in the request and
9/30/199  in the proper place.  Change Section 16 so that
8         the IPP object is NOT REQUIRED to check the
          request for the target URI.  See answer for Issue
          1.22.












                                                                      48


IPP Issues List - Model only

Question
          1.44 Target URI  and HTTP URI?

          When issuing JOB related commands, the target URI
          could be a printer-URI with a job-ID or simply a
          job-URI. But the relation between target URI and
          HTTP URI seems to be unclear. For example,
          sending a Cancel-job request to a JOB-URI(as HTTP
          URI) with a printer-URI and a job-ID as the
          target URI is OK?
                    Yuji Sasaki

Answer    Same as Issue 2.14.
9/30/199
8



Question
          1.45 text/name with language?

          Many IPP implementations did not support
          text/name with language attributes, and some were
          crashed when they received "with language"
          attributes.

          Should we have another "-supported" attribute,
          like "text-or-name-with-
          language-attributes-supported" (maybe too long ;-
          )?
                    Yuji Sasaki

Answer    No new attribute is needed.  Implementations
9/30/199  should be fixed to support both textWithLanguage
8         and textWithoutLanguage as specified in Section
          4.1.1 and 4.1.2 2nd paragraph; same for
          nameWithLanguage and nameWithoutLanguage.  Need
          to write a script to test this.






















                                                                      49





More information about the Ipp mailing list