Good feedback. My answers to your questions and issues are inline as
KC>>.
Keith
--- snip ---
> Status = "000" ; OK
> | "001" ; OK Attribute Substitution/
> Attribute Ignored
(1) I suggest that this be two separate success codes, since the user
has to do different things depending on which condition to figure out
what went wrong. Also need to make the description optionally plural,
since there could be one or more:
| "001" ; Unimplemented Attribute(s) Ignored
| "002" ; Unsupported Attribute Value(s) Substituted
KC>> I combined these conditions into a single status code since both
KC>> conditions can occur in the same request.
KC>> For the message, how about: "OK Attribute(s) Substituted/
KC>> Attribute(s) Ignored".
--- snip ---
> | "109" ; Attribute Not Implemented/
> Attribute Value Not Supported
(2) I suggest that these be two separate codes. How about:
| "109" ; Some Attribute(s) Unimplemented
| "110" ; Some Attribute Value(s) Unsupported
KC>> I combined these conditions into a single status code since both
KC>> conditions can occur in the same request.
KC>> For the message, how about: "Attribute(s) Not Implemented/
KC>> Attribute(s) Not Supported".
--- snip ---
> | "202" ; IPP Version Not Supported
(3) I thought we had been counseled by Larry Masinter and the HTTP crowd to
design the protocol so that new versions were upwards compatible with
older versions. Therefore, this error should not be an error. The operation
not implemented might be the error if a newer client tries to work with
an older server.
Alternatively, we could include this error, but with the text that
a conforming server shall NOT return it. It is there just in case,
a future verson of the standard needs a conforming Printer to return it
to an older client. At that time this sentence will be change to allow
a conforming Printer to return this error code.
KC>> The HTTP 1.1 RFC includes status "505 HTTP Version Not Supported".
KC>> The description of this status references another section in the
KC>> HTTP 1.1 RFC that explains how an HTTP version is defined and
KC>> identified. This same section is in the HTTP 1.0 internet draft
KC>> although the "505" status is not in the internet draft. "505"
KC>> is returned when the server does not support the <major> version
KC>> of the protocol as indicated in the request. Here is an excerpt
KC>> from the HTTP 1.1 RFC:
KC>>
KC>> "HTTP uses a <major>.<minor> numbering scheme to indicate
KC>> versions of the protocol. ... The <minor> number is incremented
KC>> when the changes made to the protocol add features which do not
KC>> change the general message parsing algorithm... The <major> number
KC>> is incremented when the format of a message within the protocol
KC>> is changed."
KC>>
KC>> I think we need a similar section in the Model spec and that we
KC>> should adopt the HTTP <major>.<minor> numbering scheme. i.e.
KC>> IPP 1.0 is designated as "IPP/1.0". Do you and others agree?
KC>> If so, I'll write the section.
KC>>
KC>> The Model spec can state the following for "505":
KC>>
KC>> "This status code is reserved for future use. A conforming IPP
KC>> client shall specify an IPP version of IPP/1.0 in each request.
KC>> A conforming IPP server shall not return this status code to a
KC>> conforming IPP client."
KC>>
KC>> This last sentence covers the case where a non-conforming IPP client
KC>> sends the wrong <major> number to a conforming IPP server and
KC>> hopefully influences IPP servers to handle this situation gracefully
KC>> if future IPP clients support new <major> versions of IPP.
KC>> Your thoughts?
> | "203" ; Operation Not Implemented
> | "204" ; Printer Error
> | "300" ; Communications Error
> | extension-code
>
> extension-code = 3DIGIT
>
> Message = *<TEXT, excluding CR, LF>
>
>IPP status codes are extensible. IPP applications are not
(4) I think we need to make them type 2 keywords, correct?
KC>> Yes, we need to make status codes type 2 keywords. I'll change
KC>> "extension-code = 3DIGIT" to "extension-code = type 2 keyword".
(5) ISSUE: Do we also need a way to allow implementors to have private
error codes as well?
KC>> Does this mean we need another status class for private error
KC>> codes? If so, IPP applications must be told to treat all such
KC>> error codes as "errors". Are these type 4 keywords?
--- snip ---
>4.4.1.2 001 OK Attribute Substitution/Attribute Ignored
>The operation has succeeded. On a Print operation, the request
>specifies substitute-as-needed for the best-effort attribute. In
>response to the Print operation, the IPP Printer substituted a
>value for at least one attribute value that is not supported
>and/or ignored at least one attribute that is not implemented.
(1') See above discussion on making this two separate warnings:
001 Unimplemented Attribute(s) Ignored
002 Unsuppored Attribute Value(s) Substituted
KC>> Please see my answer to (1).
>
>An IPP application may examine the attributes and/or attribute values
>in the response to determine which attributes are not implemented
>and/or which attribute values are not supported by a Printer.
(6a) This previous paragraph only applies to Gets, not Print operation.
Need to clarify. The previous paragraph specifies the Print operation.
KC>> I agree. Here is revised text:
KC>>
KC>> "An IPP application may issue a Get-Attributes operation and
KC>> specify the job-template group in the request to a Printer and
KC>> then examine the attributes and/or attribute values in the
KC>> response to determine which attributes are not implemented and/or
KC>> which attribute values are not supported by the Printer."
--- snip ---
>
>4.4.2.10 109 Attribute Not Implemented/Attribute Value Not Supported
>
>For a Print operation, if the IPP Printer does not implement at
>least one attribute and/or at least one attribute value in the
>request and either the request specifies do-not-substitute for
>the best-effort attribute or the Printer cannot process the
>request correctly, the Printer shall return this status [ and
>indicate in the response which attributes and/or attribute values
>are not supported by the Printer].
(2') See discusson above that suggests that we need two errors here:
109 Some Attribute(s) Not Implemented
110 Some Attribute Value(s) Not Supported
KC>> Please see my answer to (2).
(6) Again, while this is good for the user, the group has agreed to require
the Printer to return the attributes in question in the response
to a Print operation. But its easy for a query response.
KC>> I believe the group has agreed NOT to require the Printer to
KC>> return the attributes in question in the response to a Print
KC>> operation. Rather, an IPP application can issue the
KC>> Get-Attributes operation on the Printer to get this information.
KC>> I'll remove the phrase bounded by [] in the 1st paragraph of "109"
(7) Here is a case where the description needs to be clarified for Print
vs Get-Attributes/Get-Jobs operations.
KC>> Per the conformance section, I do not believe a conforming IPP
KC>> server can return this status code on a Get-Attributes operation.
KC>> A conforming IPP server can only return this status code on a
KC>> Get-Jobs operation in the situation already documented in the
KC>> paragraph that follows prefixed with "*".
>
>For example, if an IPP Printer can only support 1 Document per
>Job and the Printer receives multiple documents in a Print
>operation, the Printer shall return this status.
(8) ISSUE:
Since multiple documents isn't indicated by an attribute, but rather
by the content that is sent, we need a distinct error code:
multiple-documents-not-supported
(if we allow a conforming Printer to reject a multiple document
job in a Print operation.)
KC>> The description of number-of-documents states the following:
KC>> "The printer shall reject a job if the number of documents is
KC>> not in the range of this attribute." So, currently we require a
KC>> conforming Printer to reject a multiple document job in a Print
KC>> operation.
KC>>
KC>> Based on the Model spec, I understand that a Printer must detect
KC>> document boundaries in the Print request to set number-of-documents.
KC>> It seems if a Printer detects a document boundary for the "n+1"
KC>> document (where "n" is the maximum value of number-of-documents
KC>> supported by the Printer), then the Printer shall delete any spool
KC>> space (if the Printer has a spooler) and any job configuration
KC>> information (e.g. job id) used so far for the Job and reject the
KC>> Print request.
KC>>
KC>> Ideally, it would be better if the IPP client set number-of-documents
KC>> on a Print request so the target Printer can reject the Print
KC>> request BEFORE spooling part of the job and/or setting up other
KC>> information about the job (such as a job id). I expect a GUI or a
KC>> command line (both IPP applications) will allow an end-user to
KC>> select one or more documents and then submit the Print request so
KC>> the IPP application could specify number-of-documents on the Print
KC>> request (assuming the application didn't validate this value before
KC>> submitting the request). If we require the client to specify
KC>> number-of-documents (i.e. we make this attribute MANDATORY), then
KC>> number-of-documents becomes just another attribute specified by
KC>> the IPP client and so this status code applies. Your thoughts?
>For another example, if the Print operation specifies do-not-substitute,
>the request requires A4 paper and that paper size is not
>available on the Printer, the Printer shall return this status.
(9) The word "available" has not been defined and has caused a lot of
confusing in the past as to whether it means "supported" (which could
be ready or not ready) or "ready" (can be used without human intervention).
KC>> I'll change the phrase "available on" to "supported by".
*>For a Get-Jobs operation, if the IPP Printer does not support at
*>least one attribute value for Job Owner and/or Job States in
*>the request, the Printer shall return this status and indicate
*>in the response which attributes and/or attribute values are not
*>supported by the Printer.
>An IPP application may examine the attributes and/or attribute values
>in the response to determine which attributes are not implemented
>and/or which attribute values are not supported by a Printer.
KC>> I'll reword the above paragraph to match the answer to 6a.
--- snip ---
>4.4.3.3 202 IPP Version Not Supported
>
>The IPP Printer does not support, or refuses to support, the IPP
>protocol version that was used in the request message. The IPP
>Printer is indicating that it is unable or unwilling to complete
>the request using the same major version as the client other than
>with this error message. The response should contain a Message
>describing why that version is not supported and what other
>versions are supported by that IPP Printer.
(3') See discussion above that we shouldn't have such an error, unless
we make an incompatible change between versions of the protocol.
KC>> Please see my answer to (3).
--- snip ---
end of note