Subject: IPP> MOD - IPP Versioning

From: Keith Carter <[email-masked]>
Date: Wed, 21 May 1997 15:30:52 -0400

Attached is a proposed section in the Model document for IPP
versioning based on RFC 2068.  I've replaced "HTTP" with "IPP",
"1.1" with "1.0" and "MUST" with "shall". I retained all of
the remaining text from RFC 2068 so we can determine what we
want to keep or delete.

Question:  At the IPP working group meeting on Thursday, May 15,
did we decide how to distinguish compliance level 1 (i.e. Print-Job
and Validate for SWP) from compliance level 2 (i.e. all IPP operations)?
Will a minor version number be used to distinguish these compliance
levels (e.g. SWP = 1.0, Full = 1.1)?  If so, the attached text must
be modified to explain this.

Enjoy,

Keith

---- Start of Version Section ----

x.x IPP Version

IPP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
the sender to indicate the format of a message and its capacity for
understanding further IPP communication, rather than the features
obtained via that communication. No change is made to the version
number for the addition of message components which do not affect
communication behavior or which only add to extensible field values.
The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing
algorithm, but which may add to the message semantics and imply
additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is
changed.

The version of an IPP message is indicated by an IPP-Version field
in the first line of the message.

       IPP-Version   = "IPP" "/" 1*DIGIT "." 1*DIGIT

Note that the major and minor numbers shall be treated as separate
integers and that each may be incremented higher than a single digit.
Thus, IPP/2.4 is a lower version than IPP/2.13, which in turn is
lower than IPP/12.3. Leading zeros shall be ignored by recipients and
shall not be sent.

Applications sending Request or Response messages, as defined by this
specification, shall include an IPP-Version of "IPP/1.0". Use of
this version number indicates that the sending application is at
least conditionally compliant with this specification.

The IPP version of an application is the highest IPP version for
which the application is at least conditionally compliant.

NOTE TO REVIEWERS:  Do we want to remove the following paragraph?
<Proxy and gateway applications must be careful when forwarding
messages in protocol versions different from that of the application.
Since the protocol version indicates the protocol capability of the
sender, a proxy/gateway MUST never send a message with a version
indicator which is greater than its actual version; if a higher
version request is received, the proxy/gateway MUST either downgrade
the request version, respond with an error, or switch to tunnel
behavior. Requests with a version lower than that of the
proxy/gateway's version MAY be upgraded before being forwarded; the
proxy/gateway's response to that request MUST be in the same major
version as the request.>

Note: Converting between versions of IPP may involve modification
of header fields required or forbidden by the versions involved.

---- End of Version Section ----

---

From: Larry Masinter <[email-masked]>
Date: Wed, 21 May 1997 22:46:20 PDT

The HTTP/1.1 versioning language is a very poor model to
follow. It's been so troublesome that we had to issue
a separate Internet Draft (now to become an RFC) to clarify
the issue of use of version numbers between multiple
version clients and servers.

Given this history, I don't recommend using it in IPP.

I hate to question the fundamentals, but there are so many
other points of flexibility in what you're designing
that I might question the need for yet another verison
number.

What you're calling "IPP" is really an application profile
of a set of other protocols. By coding messages as 
attribute/values, establishing a registry of attributes,
and some notion of optional or manditory, you might
not need any other extensibility; if an attribute
semantics changes, give it a new attribute name.
And if you need something that is completely
incompatible, give it a new media type.

-- 

Larry
--
http://www.parc.xerox.com/masinter