[Standards-JIG] JEP-0017 Framing: Why was it rejected?
trejkaz at xaoza.net
Thu Oct 21 12:53:03 UTC 2004
On Thu, 21 Oct 2004 10:18, David Waite wrote:
> 2. Easier message validation and rejection.
I'm not convinced. If I have to write a parser for some custom protocol, how
is that any easier than using a library which already works?
> 4. You can actually use off the shelf XML tools, rather than having to
> hunt down or cobble together a push/pull parser that doesn't do
> internal buffering, writing your own DOM or cobbling together creation
> code based on the push/pull parser events, writing your own
> serialization code to deal with the namespace funkiness...
You can already use off-the-shelf XML tools if you're in the client
development market. The developers working on servers will probably have a
slightly harder time of things, though... for them, it's unwise to have one
thread per connection, so they would need to do tricks with select(). So
they would need a parser which can partially-consume tokens.
> 6. If the routing information is on the frame rather than in the
> message, you can have clear separation of user content and routing
> requirements/values (rather than embedding extra routing information
> as an extension within message bodies)
The current issue with extra routing information going inside message bodies
is more an issue with needing to be backwards compatible, than a limitation
<frame to="..." from="..." size="...">
<!-- Other routing information -->
<!-- User content -->
I think that would be a clear enough separation, no? Or do you want a
<routing> element in there alongside the message to make it cleaner?
> 7. If the body is treated opaque, you could actually support in-band
> digital signatures and encryption for 'standard' xml end-to-end
> encryption (without base-64 encoding, as you usually have to do now,
> based on your transformation setup).
I'm actually more curious to know why we didn't just inherit XMLDSIG/XMLENC or
some other existing specification of how to sign and encrypt XML fragments.
I gather it was something about CPIM requirements, and if that's the case,
I'm sure we would have been damned to perform this transformation either way.
Email: Trejkaz Xaoza <trejkaz at xaoza.net>
Web site: http://xaoza.net/
Jabber ID: trejkaz at jabber.xaoza.net
GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards