[Standards-JIG] JEP-0017 Framing: Why was it rejected?

Trejkaz Xaoza 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 
with XML.

    <frame to="..." from="..." size="...">
        <!-- Other routing information -->
        <message>
            <!-- User content -->
        </message>
    </frame>

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.

TX


-- 
             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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20041021/b4510aa0/attachment.sig>


More information about the Standards mailing list