<font size=2 face="sans-serif">Just to clarify, the reason I believe it
is important to lay out</font>
<br><font size=2 face="sans-serif">high-level design alternatives and their
implications is because it</font>
<br><font size=2 face="sans-serif">will help in making decisions about
how the Message class is to be</font>
<br><font size=2 face="sans-serif">changed.  In other words, the requirements
for a class's behavior</font>
<br><font size=2 face="sans-serif">might be drastically different, depending
on whether it is a</font>
<br><font size=2 face="sans-serif">replacement for an existing type (in
which case all the possible</font>
<br><font size=2 face="sans-serif">use-cases of the existing vs. new type
need to be taken into</font>
<br><font size=2 face="sans-serif">account) or it is going to be used in
a new context, where adherence</font>
<br><font size=2 face="sans-serif">to existing behaviors is not a factor.</font>
<br>
<br><font size=2 face="sans-serif">My hope was that the design alternatives
might be discussed,</font>
<br><font size=2 face="sans-serif">possibly other alternatives proposed,
and finally an alternative</font>
<br><font size=2 face="sans-serif">chosen before proceeding with discussions
about implementation</font>
<br><font size=2 face="sans-serif">details.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,<br>
<br>
John Warren</font>