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]