IPP> MOD - RE: Status codes

IPP> MOD - RE: Status codes

IPP> MOD - RE: Status codes

Carl-Uno Manros cmanros at cp10.es.xerox.com
Fri Apr 25 14:39:57 EDT 1997

At 10:17 AM 4/25/97 PDT, Keith_Carter at aussmtp.austin.ibm.com wrote:

>  Tom,
>  Good feedback.  My answers to your questions and issues are inline as
>  KC>>.
>  Keith
>  --- 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
>  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?

I am still in disagreement with Tom about protocol version numbers - sorry

If we want to add new operations or deprecicate older ones (over the next
20 - 50 years say) or make more attributes mandatory, we will need version
numbers for the protocol, even if we have a flexible schema for adding
attribute types and values.
Servers usually implement several version numbers for a cut-over period
that can be pretty long.  

History has shown that any group that has omitted this from their first
version of a protocol has regretted it, especially if the protocol was
commonly implemented in the marketplace (which we all assume will happen
with IPP :-).  Not having this error will mean that we paint ourselves into
a corner.  I feel strongly about this.

Hence, I support the idea that we should keep a version number error, for
possible future mismatches betwen client and server versions.


Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com

More information about the Ipp mailing list