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

Greg,


Thursday, November 14, 2002, 11:57:27 AM, you wrote:
Greg> I did this, and (in addition to finding that one of my messages didn't
Greg> make it through) I found that you haven't stated any concrete concerns
Greg> other than "people will have to write code to parse this syntax."

i said rather more than that.  that folks have not noticed that fact is at
the core of this disconnect.  i said that writing code was the minor part of
the task.  internet standards involve scaling.  that means lots of people
writing the code for lots of different platforms.  that means lots of people having to get those different
code bases interoperating.  that means lots of people having to field and
run those many different systems.

all of that is the classic scaling effect, applied to the "traffic" of
fielding a new standard, rather than to the traffic of bits flowing through
the network.

Folks are paying attention only to the one-programmer issues.  That is a
good place to start and a terrible place to end.


>> 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> Presence requires nesting.

It's just fine that requirements for presence drove the decision towards
XML.  What is peculiar is that the group then rejected using the same parser
for messaging.

Especially since the group had already been given a msgfmt spec that was in
xml.

it says that folks need to pay more attention to incremental cost.


>> 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> I can't make sense of this comment.  It's frustrating that you have
Greg> devolved into the abstract when faced with a key argument:

it's frustrating that you keep devovling to the single-programmer
perspective.


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

it takes more interoperability testing.


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

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

i recommend paying more attention to the history of actual behavior.  you
are exactly the same technical discipline yet you want to ignore a long
history of implementation behavior and user demands.


Greg> That's even more permissive, largely because of Postel's "be liberal in
Greg> what you accept" policy which parts of the IETF have adopted as dogma. 
Greg> And because RFC 822 is poorly specified and complicated.  (2822 is much
Greg> 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.

Greg> You ensure tight conformance with unforgiving popular implementations.

You ensure tight conformance with minimalist specifications.  Specifications
invent nothing that is not absolutely required for the task.  A new syntax
is not required.


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

I apologize for saying that I think the emperor is showing rather more skin
that is necessary or appropriate.  yes, that is being disruptive.  given the
brief and smooth history of this working group, i do apologize for engaging
in such an unusual action.



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]