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

Bob Wyman Bob Wyman" <bobwyman@earthlink.net
Fri, 19 Jan 2001 09:36:48 -0800


This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C081FB.586803C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    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.=20
    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=3D'1.0.0.0'>
    L:    <profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: </greeting>
=20
    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


------=_NextPart_000_001A_01C081FB.586803C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; A practice followed =
by many=20
protocols, is to provide version information as part of the initial =
handshake.=20
However, there seems to be no way to determine what version of BXXP one =
is=20
talking to. Admittedly, once finalized, the first version will be the =
only=20
version, however, we can anticipate that someday someone is going to =
raise=20
enough support for an idea that one will wish to extend the protocol =
through=20
something other than Features. I might, for instance, get lucky and =
convince=20
folk to support the redirect methods that I recently proposed. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Features, since they =

are&nbsp;supported in the Greetings message, may be enough to handle =
extensions=20
that only impact post-greetings protocol elements such as Start, End, =
etc. as=20
long as extensions are built in a backwards compatible manner. However, =
it seems=20
to me that Features would NOT be a good way to handle modifications to =
the=20
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=20
mess.&nbsp; Also, a Feature advertised in a Greetings message =
</FONT><FONT=20
face=3DArial size=3D2>can't be relied upon to introduce protocol =
elements that might=20
one day need to appear before the Greetings message (these are =
admittedly=20
unlikely to appear and can probably be ignored as a =
problem.)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; While profiles exist =
for the=20
various application level&nbsp;exchanges that can flow over BXXP (I=20
assume&nbsp;profiles can be versioned), the underlying protocol has no =
way of=20
advertising its own profile...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Are there existing =
plans to=20
handle version advertisement if a BXXP V1.1 or V2.0 is ever=20
defined?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; May I suggest that =
the Greetings=20
message should have a "Version" attribute? i.e. the following would then =
be a=20
valid greeting:</FONT></DIV>
<DIV><FONT face=3DArial><BR><FONT face=3D"Courier New" =
size=3D2>&nbsp;&nbsp;&nbsp; L:=20
&lt;greeting ver=3D'1.0.0.0'&gt;<BR>&nbsp;&nbsp;&nbsp; =
L:&nbsp;&nbsp;&nbsp;=20
&lt;profile uri=3D'http://xml.resource.org/profiles/TLS'=20
/&gt;<BR>&nbsp;&nbsp;&nbsp; L: =
&lt;/greeting&gt;<BR></FONT>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Yes, I realize that =
a version=20
identifier can be introduced in a later version and that one could write =
a rule=20
that says that if no version is present then it must be V1.0. However, =
we=20
recently went through this with HTTP and it was a real pain. The problem =
was=20
people who had&nbsp;clients&nbsp;or servers&nbsp;that weren't =
anticipating=20
versions in the headers they were receiving. It was quickly fixed since =
there=20
weren't that many bits of code around at the time, but it would have =
been=20
avoided if people knew up front that they would have to handle versions. =

</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; In BXXP, the server =
sends its=20
Greetings first. Given that there will be many more clients than =
servers, what=20
we have here is a case where a change to a small number of servers is =
going to=20
need to be handled by a very large number of clients. It is inevitable =
that some=20
idiot is going to code at least one or more of those clients in a way =
that it=20
can't handle a version advertisement in an elegant way. Let's hope that =
whatever=20
that&nbsp;client is, it isn't for some popular service. Otherwise, BXXP=20
evolution could be blocked by the stupid implementation. This is not =
goodness=20
and it certainly wouldn't seem to address the BXXP goal of incorporating =
the=20
best practices of protocol design into a single, reusable=20
framework.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
bob=20
wyman</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001A_01C081FB.586803C0--