W3C home > Mailing lists > Public > www-tag@w3.org > December 2002

binaryXML, marshalling, and and trust boundaries

From: Dan Connolly <connolly@w3.org>
Date: 02 Dec 2002 16:02:51 -0600
To: www-tag@w3.org
Message-Id: <1038866572.7112.11573.camel@dirk>

A thought on binary XML before I forget...

Here's a conversation I see repeated about
every 6 months:

A: XML is too verbose for low-bandwidth environments

B: so compress it

A: but we don't want to spend the battery/cpu/RAM
 to uncompress it; we just want a binary
 datastructure of the parse tree

B: oh bother. Go ahead, but don't ask
 the XML community to endorse it.

and it often stops there, at a stalemate.

It occured to me while brushing my teeth
or something that what B should have said is:

B: is this datastructure for use between
   mutually distrustful parties? e.g.
   arbitrary clients and servers in the Internet?

A: well, our application is just between
   our wireless towers and handsets, which
   trust each other.

B: well, what you do in the privacy of
   your own home/trusted-net is your business.
   If this isn't about interoperability
   between arbitrary parties in the net/web,
   then you really don't need our endorsement,
   do you?

A: well, surely there are other applications
   of this technology that involve
   interoperability between distrustful
   parties.

B: well, then the client has to bytecode-verify
   the datastructure on receipt. is that
   really much less work than ungzipping
   and/or XML parsing?

A: it sure seems like a lot less work.

B: well, after >10 years, security bugs
   in sunRPC unmarshalling code are still
   being found. Are you sure?

Subject: NetBSD Security Advisory 2002-011: Sun RPC XDR decoder contains
buffer overflow
Date: Tue, 17 Sep 2002 17:53:15 -0700 
http://www.mail-archive.com/bugtraq@securityfocus.com/msg09084.html


A: hm... maybe you're right that when
   you need to cross trust boundaries,
   you might as well use XML
   or gzip'd XML.




-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 2 December 2002 17:02:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:14 GMT