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