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

This discussion would be fine and dandy if we were having it a year ago, 
but we are not. The working group went through debates about syntax, and 
settled on the current solution which is documented in the draft. I 
personally prefer not to continuously re-open old issues, as this is 
merely a way to guarantee non-progress.

To me, the most important feature we need from the IMPP specs is 
FINISHED. Yes, finished is a feature, and its the most important one. 
Thats especially true from a group who was been working on these 
documents already for far too long.

I would submit that the cost of changing ones mind on old issues will 
frequently incur the highest cost. Like it or not, people implement 
I-Ds, especially ones that have been around for as long as CPIM-MSGFMT 
and PIDF. Making a major change, like converting to XML, this late in 
the game, results in people needing to implement BOTH the old draft (for 
compatibility with old implementations) and the new.

So, I propose we continue with what we have and put this document to bed.

-Jonathan R.

Dave Crocker wrote:
> Derek,
> 
> Monday, November 11, 2002, 7:30:41 AM, you wrote:
> Derek> The justification for MsgFmt,
> 
> I think that it is a Good Thing to have a MsgFmt specification. I initiated
> this thread to raise a question about the "strategy" of the syntax choice,
> not to raise any question at all about the basic utility of SOME MsgFmt
> specification.
> 
> (There can be a separate discussion about the role of this spec with respect
> to the IM service definition, particularly with respect to whether to
> mandate it. But that is a discussion about the service, not the format
> spec.)
> 
> Debating syntax can be pretty big waste of time. That is why I am trying to
> raise this in the context of *strategic* impact for the current choice.
> 
> There is nothing wrong with the current spec, from a computer science
> standpoint. And a desire to clean up and simplify an old, crufty syntax is a
> Good Thing. The real question is a kind of strategic make-vs-buy concern, in
> terms of global implementation and adoption.
> 
> This has nothing to do with the initial coding effort of an individual
> programmer. In fact, differences in initial coding effort are almost
> completely irrelevant to a question of global adoption and interoperability.
> However the difference between no coding, versus some coding, *is*
> significant.
> 
> The concern is for a) minimizing effort, and b) maximimizing
> interoperability with other systems.
> 
> Standards work suffers pretty serious multiplier effects.  Small bits of
> writing cause large amounts of programming (per programmer and then, of
> course, multiplied by the number of such efforts), and larger amounts of
> debugging, and even larger amounts of deployment hassle.  The less
> development, the lower the risk of a problem down the line.
> 
> Interoperability with other messaging systems argues for a semantic that
> directly maps to Internet Mail.  I think the current spec is well within
> that.  The things that prevent the syntax from being a strict subset of
> RFC2822 does not prevent it from being gatewayed (translated), I believe.
> 
> So, I think that it is particularly important for MsgFmt to use an existing
> syntax and a semantic that is a profile of Internet Mail.  I think the
> current spec does the latter.  That just leaves the *strategic* question of
> whether to make people write a brand new parser or whether to use an
> existing one.
> 
> Choosing an Internet Mail parser, and then profiling the semantic, is a very
> safe choice.  However I think that at this point it is the wrong choice.
> XML has made far too much real progress.  It now comes with a very rich base
> of software.
> 
> The concern for the space inefficiency of XML is reasonable, but I believe
> it is misplaced.  As I think I noted, it is particularly ironic to have the
> RFC733/822/2822 syntax considered to be a space-efficient choice.  This
> original reactions to it were rather different...
> 
> However the reality of the syntactic inefficiencies of XML for messaging
> turn out to be misplaced.
> 
> If a message is small, the percentage of "waste" is quite high.  But because
> the message is small, it doesn't matter.
> 
> If a message is large, the bulk of the space is the content, not the
> headers.  So, the inefficiencies of the header syntax won't matter.
> 
> d/

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




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