IPP> MOD - Status codes

IPP> MOD - Status codes

IPP> MOD - Status codes

Keith_Carter at aussmtp.austin.ibm.com Keith_Carter at aussmtp.austin.ibm.com
Fri Apr 25 13:17:47 EDT 1997


  Tom,


  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



More information about the Ipp mailing list