Re: draft-ietf-impp-cpim-msgfmt syntax

Greg,

Tuesday, November 12, 2002, 10:56:53 AM, you wrote:
Greg> savings of 1K may not matter, but a savings of half a megabit might.

Once again:  if you are seriously worried about bit inefficiencies, you need
to pay attention to much larger issues.

The entire approach to designing Internet application protocols optimizes
concerns other than bit-efficiency. You are falling victim to the problem of
choosing arbitrary portions of the system to optimize, without attending to
the overall inefficiencies.


Greg>   * header:value is more readable than XML when nesting is not required.

Fine.  Then make the presence format also use this new syntax.


Greg>   * header:value takes very little code to implement.

Please take note of the difficulty folks seem to be having in attending to
the larger aspects of achieving adoption and interoperability.  The point is
now being repeatedly ignored and that should bother folks a lot.


Greg>   (RFC 822 takes a
Greg> lot of code to implement, because it is remarkably permissive.

You need to take heed of this fact rather more deeply.  It did not become
permissive only because the spec was permissive.  Therefore anything that we
can do to ensure tighter conformance should appeal to us a lot.   A new
syntax runs contrary to that goal.


Greg> XML wastes space to no particular end.

An excellent reason for switching presence over to this same syntax.


Greg>   * (Not a new argument.)  This working group appears to be nearing
Greg> completion, and these drafts have been around for long enough to have
Greg> been implemented.  Changing the encoding would be disruptive.

Does it not bother anyone to see a working group flounder for 4 years and
then be subject to arguments against improvements because they would be
"disruptive"?

Plain fact:  The market gave up on this effort 3 years ago.  For the effort
to have an effect, it needs to pay very close attention to the future
adoption, not the history of work done to formulate the standard.

One more time:  Anyone doing an implementation from an I-D has already
bought into the requirement to make changes when the spec is finally
published as a standards-track RFC.

d/
-- 
 Dave Crocker  <mailto:[email protected]>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850




  [reminder: [email protected] for non-technical discussions, please]