Subject: Re: TSP version 03

From: "David P. Kemp" <[email-masked]>
Date: Thu, 23 Sep 1999 17:48:13 -0400 (EDT)

> From: Ronald Tschalär <[email-masked]>
> 
> There is a serious difference between being able to detect a version
> mismatch and trying to parse the packet using the wrong version. In
> the first case I send back a useful error message, in the second case
> I can't.

Referring to Paul's example of 100 new packet formats not requiring
a new version number, please give an example of new functionality
that might be required in TSP-over-TCP which would force the protocol
to be unparsable by current software.  There are 249 unused "flag"
values, only one of which would be needed to introduce an infinitely
expandable protocol layer.  The example I gave earlier was a DER-encoded
value with syntax "Extensions".  You could burn one more flag value
to represent any MIME object and still have 247 values left.
These are over-the-top examples; it's far more likely that new
functionality could be accommodated within the existing DER-encoded
TSP messages or with a few new top-level messages identified by new
"flag" numbers.

Do you agree with Paul and me that a new version number is needed only
if new data cannot be properly parsed by old software?  After parsing,
you might silently discard unrecognized data, or you might fail with an
error, or you could use a critical flag to specify discard/fail at
runtime, but in all cases you are able to recognize what has happened
and send back a useful error message: "unsupported packet format 09h
from joe".  This is more useful than "unsupported version 5 connection
from joe" because a packet format number or an extension OID provides
finer-grained information than a socket protocol version number.

---

From: Ronald Tschal�r <[email-masked]>
Date: Thu, 23 Sep 1999 16:13:46 -0700 (PDT)

First off: I don't care whether you use the new CMP-over-TCP protocol 
for TSP or not. That's up to you. My argument was against the blanket
statement that version numbers are not of any use, and against the
arguments used to support that statement which seemed to based on A)
badly designed protocols, and B) the use versions in static data
structures (as opposed to a networking situation that allows negotiation).
I apologize if I misunderstood you.

Note: the choice of the term "flag" for the message-type in the spec is
a bit unfortunate - I will use "message-type" instead, and use "flag" to
mean a flag in the more general sense.

> expandable protocol layer.

You can certainly do this. So, to introduce a new connection-close flag
you now define a new message-type which allows that flag to be set and
encapsulates all the other message types. To get this working in general
(i.e. to allow a client a server to negotiate the message-types they
understand), all you now need is an error message which allows the
server to specify what message-types it understands (otherwise all an
older server can do is reject the message, w/o giving sufficient
information for the client to decide why it was rejected, and whether
to retry the request using a different message-type). At this point
you're using the message-type as a kind of version indicator.

> The example I gave earlier was a DER-encoded

Whether the functionality goes into the transport protocol or into TSP
itself depends on what it affects. Yes, in most cases you want to
extend TSP; but in some cases, such as adding a connection-close flag
or adding new message-types, you need to change the underlying protocol
itself. Nothing new here.

> if new data cannot be properly parsed by old software?

No. It all depends on how negotiation you want to allow. At the one end
you could say "If I can't parse it I'll just abort" - this doesn't
"need" any versioning. At the other end you want to fully negotiate the
capabilities of each side.  This can be done either with version
numbers, extensible options, or some combination thereof. If your
extension mechanism is flexible enough you'll never need to change the
parser (you may want to for reasons of efficiency, or something, but
it's not necessary).

> After parsing,

The argument is not really about version numbers, but about how to allow
for negotiation. If you want to do that with options, fine. If you want
to do that with a version number, fine too. Which you want to use
depends a lot on how flexible the protocol needs to be, how fine grained
the negotiation should be, how much complexity you want to stick into
the basic parser, etc. The problem with the "direct TCP-based message"
protocols as defined in rfc-2510 and the TSP draft is that they don't
allow any negotiation: if the client wants to use a new feature
(message-type) which the server does not understand then all it gets
back is an errorMsgRep (hopefully - the spec doesn't even specify that),
and that does not have a machine parseable syntax defined to be able to
let the client figure out why exactly the error happened and possibly
how to correct it. This can be fixed by adjusting the errorMsgRep
syntax. Also, client can't advertise that it, say, understands new
response messages. This can be fixed by either adding a version number
or by adding new message-types. In CMP-over-TCP we fixed the errorMsgRep,
and chose to use a version number for simplicity. This gives the basic
framework to allow automatic negotiation should new features be added.

Enough said...

  Cheers,

  Ronald

---

From: Rich Salz <[email-masked]>
Date: Fri, 24 Sep 1999 00:15:43 -0400 (EDT)

> if new data cannot be properly parsed by old software?

No.  There might be semantic changes in existing pdu's.  E.g., multiple
"revoke me" requests return an error or ignore replay.  This kind of
thing happens when you find that most implementations of a spec didn't
do wghat was "obvisouly" intended.  E.g., closing connection during EE/RA
communications.

>  "unsupported packet format 09h
> from joe"

Are you speaking from experience or theory?

My experience (revving the DCE RPC protocol) is the exact opposite.
Very strongly so.
	/r$

---

From: Paul Koning <[email-masked]>
Date: Fri, 24 Sep 1999 11:09:07 -0400

>>>>> "Ronald" == Ronald Tschalär <[email-masked]> writes:

 >> Do you agree with Paul and me that a new version number is needed
 >> only if new data cannot be properly parsed by old software?

 Ronald> No. It all depends on how negotiation you want to allow. At
 Ronald> the one end you could say "If I can't parse it I'll just
 Ronald> abort" - this doesn't "need" any versioning.

I would consider that a rather bad idea; I don't think anyone proposed 
such a rule.

 Ronald> At the other end
 Ronald> you want to fully negotiate the capabilities of each side.
 Ronald> This can be done either with version numbers, extensible
 Ronald> options, or some combination thereof. 

No.  Version numbers are not the way to "fully negotiate the
capabilities of each side".  The reason is that version numbers are
scalars, while capabilities are sets.  If you actually want to
exchange information about the capabilities of the two ends (as
opposed to simply asking for something and observing the request isn't 
granted) then you must use an encoding that expresses for each
capability whether it's supported or not.  Version numbers do NOT work 
for this.  They have been used for that in some protocols, always with 
miserable failure.

>>>>> "Rich" == Rich Salz <[email-masked]> writes:

 >> Do you agree with Paul and me that a new version number is needed
 >> only if new data cannot be properly parsed by old software?

 Rich> No.  There might be semantic changes in existing pdu's.  E.g.,
 Rich> multiple "revoke me" requests return an error or ignore replay.
 Rich> This kind of thing happens when you find that most
 Rich> implementations of a spec didn't do wghat was "obvisouly"
 Rich> intended.  E.g., closing connection during EE/RA
 Rich> communications.

That's a good point.  But another way to do this that doesn't require
incrementing the version number is to say "new semantics means a new
message".  I.e., don't change message semantics, but rather create new 
messages when new semantics are needed.

Which of these is chosen is a matter of taste.  I do agree that you
can't pick the approach you mentioned if you don't have version
numbers; that's a good reason to throw one in, as I suggested.

	paul