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

[Well, bummer.  I sent this two days ago, but it's not in the archives,
I haven't received a reply (suggesting that Dave Crocker didn't get it),
and it's not in my local mail spool, so I think MIT's mail hubs
black-holed it.  I'll try again; while I'm here, I'll start with a
response to one of Dave Crocker's comments from today.]

On Thu, 2002-11-14 at 14:02, Dave Crocker wrote:
> and lest anyone think that the above comment is simply an emotional
> indulgence, folks should look over the archive of recent discussion.

I did this, and (in addition to finding that one of my messages didn't
make it through) I found that you haven't stated any concrete concerns
other than "people will have to write code to parse this syntax." 
Having to write code can affect interoperability, deployability, and
use, but only if the amount of code required is significant.

On Tue, 2002-11-12 at 15:06, Dave Crocker wrote:
> 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.

Perhaps.  You made the "2K isn't important" argument; I was simply
responding to it.

> Greg>   * header:value is more readable than XML when nesting is not required.
> 
> Fine.  Then make the presence format also use this new syntax.

Presence requires nesting.

> 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.

I can't make sense of this comment.  It's frustrating that you have
devolved into the abstract when faced with a key argument:

  It takes less code to implement header:value than it does to interface
  with an XML library to implement an XML string->string mapping.

I'll go further and say:

  It takes roughly equivalent verbiage to specify header:value as it
  does to specify a string->string mapping in XML.

> 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.

I was talking about RFC 822 as written, not the unwritten standard of
what MUAs must accept in email headers.

That's even more permissive, largely because of Postel's "be liberal in
what you accept" policy which parts of the IETF have adopted as dogma. 
And because RFC 822 is poorly specified and complicated.  (2822 is much
better, but the damage has been done.)

> Therefore anything that we can do to ensure tighter conformance should
> appeal to us a lot.   A new syntax runs contrary to that goal.

You ensure tight conformance with unforgiving popular implementations. 
It doesn't matter whether the encoding is old or new.  (Being
unforgiving is really easy--even natural--to do with the current
header:value syntax; it's harder to do with XML, though it's been done
in some implementations.)

> Greg> XML wastes space to no particular end.
> 
> An excellent reason for switching presence over to this same syntax.

I opposed the use of XML in presence.  I think XML has no place in
application protocols.  You can design a simpler syntax (more
complicated than header:value, because it needs to allow nesting, but
still an order of magnitude simpler than XML) in about five lines of
BNF, and you can implement it in about 70 lines of C code.  I proved
this back when this working group was first arguing about presence
formats, but the group still sided with XML.

Do you see me standing up now and saying that CPIM has to change away
from using XML for presence, notwithstanding working group consensus and
a long draft history?  No, that would be disruptive, just as you're
being disruptive now.

> 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"?

The working group floundered for four years because the IETF has no
mechanism for making progress on unconstrained problems.  The use of
header:value in CPIM has added very little to the flailing coefficient,
until now.

> Plain fact:  The market gave up on this effort 3 years ago.

The market is AOL, which was never genuinely interested in this effort,
for obvious reasons.

> 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.

You haven't presented a compelling argument that XML will make adoption
any more likely.  We can use XML all over the protocol, and AOL will
still control the market, and will still have no economic incentive to
interoperate with anyone else.




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