RE: MSGFMT

I hear what you're saying - again, my only motivation for supporting change
of any kind to MSGFMT is to:

1) Make the MSGFMT document shorter and simpler (eliminate much of the
format specification in Sections 2 and 3), and therefore more likely to pass
2) Rely on a pre-existing syntax rather than something that still needs to
pass the IESG (something that has an RFC number, rather than something that
could be controversial - I don't want people to ask us why we didn't reuse
something that is already out there, etc)

If there were another format that we could select that met those criteria, I
suspect it would actually make our work here more likely to succeed in the
short term. If there is no acceptable format that meets these criteria, I
think we should proceed with the existing MSGFMT format.

Understanding the origin of MSGFMT in the 822/XML work is helpful - but in
my mind, the litmus test for the quality 'new' is whether or not we have to
get the format past the IESG. In that sense the 822/XML work is 'new'.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Graham Klyne [mailto:[email protected]]
> Sent: Thursday, November 14, 2002 6:45 AM
> To: Peterson, Jon
> Cc: [email protected]
> Subject: Re: MSGFMT
> 
> 
> I am not by this message seeking to change anything, but I'd like to set 
> the record straight about something.
> 
> The design of the current format came about as a rendering into a 
> restricted form of what is allowed by RFC822 of an XML format that WAS 
> previously designed and offered as a candidate, drawing many lessons and 
> semantic details from RFC822, but also drawing upon identified advantages 
> of XML.
> 
> So, the current design is a second generation derivation from a previous 
> XML design -- very little here is truly new.
> 
> #g
> --
> 
> At 03:55 AM 11/14/02 -0500, Peterson, Jon wrote:
> 
> >The only concern I have with the current specification of 
> MSGFMT is that it
> >defines something new (and expends quite a bit of space in 
> the draft doing
> >so, pretty much Section 2 and 3 and much of Section 4), when 
> it might have
> >been possible to reuse something that already exists. From 
> my perspective,
> >this is a standards process issue, not a technology issue - 
> I really doubt
> >that any analysis of the processing time or implementation 
> difficulty of
> >alternative formats would really be material.
> >
> >While I would be happy to cite some pre-existing RFC as the 
> format that will
> >be used for CPIM MSGFMT, I'm not interested in inventing (or 
> even merely
> >finishing) some other format - I feel the format described 
> in the MSGFMT
> >draft today is adequate, and I would rather continue with 
> that format than
> >substitute in something else for which we would incur new 
> development time.
> >I would therefore prefer the existing format to any 
> XML-based format we
> >might define.
> >
> >Jon Peterson
> >NeuStar, Inc.
> >
> >
> >
> >   [reminder: [email protected] for non-technical 
> discussions, please]
> 
> -------------------
> Graham Klyne
> <[email protected]>
> 



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