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

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Fri, 19 Jan 2001 11:03:54 -0800


This is a multi-part message in MIME format.

------=_NextPart_000_0123_01C08207.834DCD70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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: bxxpwg@lists.invisibleworlds.com
  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:

      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


------=_NextPart_000_0123_01C08207.834DCD70
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.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>the problem is that there is no such thing as an =
application=20
protocol that has successfully done version evolution. if anyone =
disagrees, then=20
step forward and name the counter-example.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>i think we should err towards simplicity, above all =
else. if=20
someone wants a different way of doing greetings, they can do that, they =
just=20
can't call it beep.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>if they want small deltas to the channel management =
profile,=20
they can use the feature attribute (as you suggested for=20
redirection).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>if they want to do different versions of other =
profiles, each=20
side can advertise different URIs in their greetings. this gives you a=20
versioning capability very inexpensively.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>/mtr</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dbobwyman@earthlink.net =
href=3D"mailto:bobwyman@earthlink.net">Bob=20
  Wyman</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=3Dbxxpwg@lists.invisibleworlds.com=20
  =
href=3D"mailto:bxxpwg@lists.invisibleworlds.com">bxxpwg@lists.invisiblewo=
rlds.com</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, January 19, 2001=20
09:36</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [BXXPwg] Will there be =
only one=20
  beep? What about Versions?</DIV>
  <DIV><BR></DIV>
  <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=20
  are&nbsp;supported in the Greetings message, may be enough to handle=20
  extensions that only impact post-greetings protocol elements such as =
Start,=20
  End, etc. as long as extensions are built in a backwards compatible =
manner.=20
  However, it seems to me that Features would NOT be a good way to =
handle=20
  modifications to the Greetings message itself. Thus, it would be =
difficult to=20
  add support for redirect in the Greetings message in the future =
without making=20
  a bit of a mess.&nbsp; Also, a Feature advertised in a Greetings =
message=20
  </FONT><FONT face=3DArial size=3D2>can't be relied upon to introduce =
protocol=20
  elements that might one day need to appear before the Greetings =
message (these=20
  are admittedly unlikely to appear and can probably be ignored as a=20
  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=20
  Greetings message should have a "Version" attribute? i.e. the =
following would=20
  then be a valid greeting:</FONT></DIV>
  <DIV><FONT face=3DArial><BR><FONT face=3D"Courier New" =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  L: &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=20
  rule 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.=20
  </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=20
  some idiot is going to code at least one or more of those clients in a =
way=20
  that it can't handle a version advertisement in an elegant way. Let's =
hope=20
  that whatever that&nbsp;client is, it isn't for some popular service.=20
  Otherwise, BXXP evolution could be blocked by the stupid =
implementation. This=20
  is not goodness and it certainly wouldn't seem to address the BXXP =
goal of=20
  incorporating the 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></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0123_01C08207.834DCD70--