Subject: [BXXPwg] Will there be only one beep? What about Versions?

From: "Bob Wyman" <[email-masked]>
Date: Fri, 19 Jan 2001 09:36:48 -0800

A practice followed by many protocols, is to provide version information as part of the initial handshake. However, there seems to be no way to determine what version of BXXP one is talking to. Admittedly, once finalized, the first version will be the only version, however, we can anticipate that someday someone is going to raise enough support for an idea that one will wish to extend the protocol through something other than Features. I might, for instance, get lucky and convince folk to support the redirect methods that I recently proposed. 
    Features, since they are supported in the Greetings message, may be enough to handle extensions that only impact post-greetings protocol elements such as Start, End, etc. as long as extensions are built in a backwards compatible manner. However, it seems to me that Features would NOT be a good way to handle modifications to the Greetings message itself. Thus, it would be difficult to add support for redirect in the Greetings message in the future without making a bit of a mess.  Also, a Feature advertised in a Greetings message can't be relied upon to introduce protocol elements that might one day need to appear before the Greetings message (these are admittedly unlikely to appear and can probably be ignored as a problem.)
    While profiles exist for the various application level exchanges that can flow over BXXP (I assume profiles can be versioned), the underlying protocol has no way of advertising its own profile...
    Are there existing plans to handle version advertisement if a BXXP V1.1 or V2.0 is ever defined?
    May I suggest that the Greetings message should have a "Version" attribute? i.e. the following would then be a valid greeting:

    L: <greeting ver='1.0.0.0'>
    L:    <profile uri='http://xml.resource.org/profiles/TLS' />
    L: </greeting>
 
    Yes, I realize that a version identifier can be introduced in a later version and that one could write a rule that says that if no version is present then it must be V1.0. However, we recently went through this with HTTP and it was a real pain. The problem was people who had clients or servers that weren't anticipating versions in the headers they were receiving. It was quickly fixed since there weren't that many bits of code around at the time, but it would have been avoided if people knew up front that they would have to handle versions. 
    In BXXP, the server sends its Greetings first. Given that there will be many more clients than servers, what we have here is a case where a change to a small number of servers is going to need to be handled by a very large number of clients. It is inevitable that some idiot is going to code at least one or more of those clients in a way that it can't handle a version advertisement in an elegant way. Let's hope that whatever that client is, it isn't for some popular service. Otherwise, BXXP evolution could be blocked by the stupid implementation. This is not goodness and it certainly wouldn't seem to address the BXXP goal of incorporating the best practices of protocol design into a single, reusable framework.

        bob wyman

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 19 Jan 2001 11:03:54 -0800

the problem is that there is no such thing as an application protocol that
has successfully done version evolution. if anyone disagrees, then step
forward and name the counter-example.

i think we should err towards simplicity, above all else. if someone wants a
different way of doing greetings, they can do that, they just can't call it
beep.

if they want small deltas to the channel management profile, they can use
the feature attribute (as you suggested for redirection).

if they want to do different versions of other profiles, each side can
advertise different URIs in their greetings. this gives you a versioning
capability very inexpensively.

/mtr
  ----- Original Message -----
  From: Bob Wyman
  To: [email-masked]
  Sent: Friday, January 19, 2001 09:36
  Subject: [BXXPwg] Will there be only one beep? What about Versions?

      A practice followed by many protocols, is to provide version
information as part of the initial handshake. However, there seems to be no
way to determine what version of BXXP one is talking to. Admittedly, once
finalized, the first version will be the only version, however, we can
anticipate that someday someone is going to raise enough support for an idea
that one will wish to extend the protocol through something other than
Features. I might, for instance, get lucky and convince folk to support the
redirect methods that I recently proposed.
      Features, since they are supported in the Greetings message, may be
enough to handle extensions that only impact post-greetings protocol
elements such as Start, End, etc. as long as extensions are built in a
backwards compatible manner. However, it seems to me that Features would NOT
be a good way to handle modifications to the Greetings message itself. Thus,
it would be difficult to add support for redirect in the Greetings message
in the future without making a bit of a mess.  Also, a Feature advertised in
a Greetings message can't be relied upon to introduce protocol elements that
might one day need to appear before the Greetings message (these are
admittedly unlikely to appear and can probably be ignored as a problem.)
      While profiles exist for the various application level exchanges that
can flow over BXXP (I assume profiles can be versioned), the underlying
protocol has no way of advertising its own profile...
      Are there existing plans to handle version advertisement if a BXXP
V1.1 or V2.0 is ever defined?
      May I suggest that the Greetings message should have a "Version"
attribute? i.e. the following would then be a valid greeting:

      Yes, I realize that a version identifier can be introduced in a later
version and that one could write a rule that says that if no version is
present then it must be V1.0. However, we recently went through this with
HTTP and it was a real pain. The problem was people who had clients or
servers that weren't anticipating versions in the headers they were
receiving. It was quickly fixed since there weren't that many bits of code
around at the time, but it would have been avoided if people knew up front
that they would have to handle versions.
      In BXXP, the server sends its Greetings first. Given that there will
be many more clients than servers, what we have here is a case where a
change to a small number of servers is going to need to be handled by a very
large number of clients. It is inevitable that some idiot is going to code
at least one or more of those clients in a way that it can't handle a
version advertisement in an elegant way. Let's hope that whatever that
client is, it isn't for some popular service. Otherwise, BXXP evolution
could be blocked by the stupid implementation. This is not goodness and it
certainly wouldn't seem to address the BXXP goal of incorporating the best
practices of protocol design into a single, reusable framework.

          bob wyman