> 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
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?
>
I am still in disagreement with Tom about protocol version numbers - sorry
Tom.
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
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@cp10.es.xerox.com