I've remained pretty mute on this issue, but since Carl-Uno has
become so passionate in this matter, I'll add my 2 cents worth:
> 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.
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: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------