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
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.