Subject: IPP> MOD - RE: Status codes

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 25 Apr 1997 11:39:57 PDT

At 10:17 AM 4/25/97 PDT, [email-masked] 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
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: [email-masked]

---

From: JK Martin <[email-masked]>
Date: Fri, 25 Apr 1997 15:35:45 -0400 (EDT)

I've remained pretty mute on this issue, but since Carl-Uno has

> possible future mismatches betwen client and server versions.

I couldn't agree more.  For every network protocol I have developed in
the past that didn't contain some sort of version identification, I
have seriously regretted it.  And precisely for the reasons so well
stated by Carl-Uno above.

Version information is good.  Version information is your friend.

Just keep the implementation simple, concise and succinct, please.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------