Subject: [Rfid] XML vs. Text vs. Binary

From: Margaret Wasserman <[email-masked]>
Date: Wed, 20 Jul 2005 22:19:17 -0400

We've had some discussion on this list about XML encoding vs. binary 
encoding...

I'm not sure that we are in agreement on all of the related points, 
but the concerns with XML seem to be code size on the reader and 
protocol overhead on the wire.  These concerns can be minimized by 
the use of a restricted XML subset, such as canonical XML (see RFC 
3076).  However, there still seem to be some concerns along those 
lines.

The only advantages that I remember being discussed for a binary 
encoding were the complement to the concerns with XML:  smaller code 
size on the reader and less protocol overhead.

I think, though, that our discussions have missed a major benefit of 
any text-based encoding (whether a protocol-specific text encoding or 
canonical XML):  the ability to access the device using text 
processing tools (such as Perl scripts) and/or for a human to 
interact with the device directly.

In 2002, the IAB held a Network Management workshop that is 
documented in RFC 3535.  I would suggest that folks on this list read 
this report which can be found at:

http://www.ietf.org/rfc/rfc3535.txt?number=3535

One of the interesting findings of that workshop was that one of the 
significant barriers to the use of SNMP as a configuration or control 
protocol is that it uses a binary encoding, which means that 
SNMP-specific client software (an SNMP browser or manager) is needed 
to interact with the device via SNMP.  This prevents SNMP access 
using text processing tools or via human interaction.

I would not like to see the industry create the same problem with an 
RFID control protocol.

If there is real evidence that canonical XML would require too much 
code size on the reader and/or would result in an unacceptable level 
of protocol overhead, perhaps we could consider a protocol-specific 
text-based encoding (similar to FTP, SMTP and HTTP)?  I don't believe 
that parsing a well-defined text-based encoding would require much 
more code than processing a binary encoding.  And, in some cases a 
text based encoding would actually result in less data on the wire -- 
for instance a 32 bit integer with the value of 3 would be encoded in 
one byte of text ("3"), while it would require 4 bytes in binary 
encoding ("0x00000003').

Personally I like canonical XML, because I think it strikes a good 
balance between being human readable and machine-parsable.  I also 
like the fact that the syntax is already well-defined.  However, I 
think that well-defined, protocol-specific textual encodings could 
also achieve that balance, perhaps with less impact in the areas of 
concern (code size and protocol overhead).

What do others think?  Should we at least consider a text-based encoding?

Margaret

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: "Frederico, Gustavo" <[email-masked]>
Date: Thu, 21 Jul 2005 08:55:25 -0400

XML is already the de facto standard for interaction between disparate
systems. That is clear to people that work in software and systems
integration. Perhaps it's not so obvious to folks that work mostly with
hardware. I would be concerned to used a protocol that is not XML-based
and defines software interface. The size of XML does not have to be so
much of a concern. It will probably be x % of what it would be if it
were not XML-based anyway. The human-readability of XML is not a problem
either, with a plethora of XML tools that facilitate editing and
generation. There are lots of packages for parsing in Java, Perl and
.NET compact framework. There's NanoXML, for instance, a light-weight
Java xml parser that requires 6K. There is work on W3C on a binary
representation of XML  ( http://www.w3.org/XML/Binary/ ), but it doesn't
seem to be finalized, and maybe it isn't necessary in this case either.
XML brings many benefits that are well-documented. What the group may
also consider is the use of RDF or OWL-Lite, for strong semantics and
scalability, that I think would fit configuration management very well.

Regards,
Gustavo Frederico
Allstream

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Margaret Wasserman
Sent: Wednesday, July 20, 2005 10:19 PM
To: [email-masked]
Subject: [Rfid] XML vs. Text vs. Binary

What do others think?  Should we at least consider a text-based
encoding?

Margaret

---

From: [email-masked]
Date: Thu, 21 Jul 2005 17:44:15 -0500

FYI: I view SLRRP/binary or SLRRP/text(non-XML) as a viable protocol that
can be adapted to a serial device.  However, I wouldn't try to put SLRRP/XML
on a serial device.

I realize that SLRRP is intended to be a network protocol.  However, in my
evaluation of SLRRP I'm factoring in legacy serial devices I want to
support.  A serial adaptation of SLRRP will be required if I adopt SLRRP.

Rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Frederico, Gustavo
Sent: Thursday, July 21, 2005 7:55 AM
To: [email-masked]
Subject: RE: [Rfid] XML vs. Text vs. Binary

Regards,
Gustavo Frederico
Allstream

-----Original Message-----

Margaret

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."

---

From: "Howard Kapustein" <[email-masked]>
Date: Fri, 22 Jul 2005 09:46:34 -0400

>therefore the cost of XML is negligible?

Cost has several dimensions, not just cpu.
For instance, memory utilization can also be a significant factor.

I have no idea how XML vs. TLS stack up on that front.
But we should be clear when we're discussing such things we clearly
understand what we're referring to, and not lumping disparate things
together under one jambalaya umbrella.

	- Howard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephane Bortzmeyer
Sent: Friday, July 22, 2005 7:43 AM
To: Scott Barvick
Cc: [email-masked]
Subject: [Rfid] Re: XML vs. Text vs. Binary

On Fri, Jul 22, 2005 at 06:56:14AM -0400,
 Scott Barvick <[email-masked]> wrote 
 a message of 121 lines which said:

> the protocol processing is layered on top of standard security
> mechanisms as discussed in Section 4.2 of the draft.

Section 4.2 is nice but it just says that TLS MUST be present, not
that it MUST be used, no?

> Therefore, the implementation can safely access fields in payload as
> efficiently as possible.

It seems to me quite contradictory to say (David Husak's message) "We
will use fixed-length encoding because it is faster" and "security is
not an issue, since we use TLS". Surely, TLS processing is much more
costly than XML processing and therefore the cost of XML is
negligible?

---

From: "Howard Kapustein" <[email-masked]>
Date: Fri, 22 Jul 2005 10:12:54 -0400

>it's certainly better than binary if you're going to type-in commands  
>via telnet or ssh. the moment you have to start matching elements,  
>and are typing more than a few of them, you need to have a tool do  
>the typing.

a) Who said "text" means "xml" ?
XML is an option, but in a 3-way fight 'binary' goes down early in the
fight, and the real question is if XML or non-xml-text format should be
the basis for the syntax.

Syntax.
That's all XML buys you 'for free'.
[Well, that plus a lotta tools, but also some drawbacks]

The magic XML wand doesn't inherently solve Vocabulary nor Semantics.
Just syntax.

Ditto for Text.

And points made by both Marshall + Margaret, IMO, also emphasize the
need for a good non-XML textual format.

Check out HTTP.
Now SOAP and XML-RPC.
Now go sniff a wire for DCOM, or IIOP, or NDR.
Hey, go play with some ASN.1.

Text vs. XML vs. Binary.

XML's nice in some ways, but less desirable than text for human reasons.
[And tools; there are many XML tools, but even more 'structured text
handling' options]

And both are far superior to Binary.

IMNSHO, of course :-)

	- Howard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Marshall Rose
Sent: Thursday, July 21, 2005 10:48 PM
To: Margaret Wasserman
Cc: [email-masked]
Subject: Re: [Rfid] XML vs. Text vs. Binary

> So, I will restate my opinion that we should not lightly develop an  
> RFID reader management protocol that can only be access from a  
> specialized client.

i guess we'd need to agree on the meaning of specialized before  
agreeing on this point.

> To your point about enumerated types, etc.... There is no reason  
> why a text interface couldn't allow well-defined strings to be used  
> for those enumerations (EPC0, EPC1, EPCG2, etc...), rather than  
> requiring the client (whether it is a piece of middleware, a Perl  
> script or a human typing at an SSH prompt) to send numerical values.

the problem, i think, is that the XML compromise, like most  
compromises, doesn't really solve anything; further, like most  
compromises, it works worse than most purist approaches.

it's certainly better than binary if you're going to type-in commands  
via telnet or ssh. the moment you have to start matching elements,  
and are typing more than a few of them, you need to have a tool do  
the typing.

as soon as you have tool do it, you've lost the text advantage  
because it's just as easy for a tool, perl-based or not, to spit out  
binary as xml.

my experience, which admittedly is dated, is that text works for  
debugging simple protocols like smtp. as soon as you introduce  
nesting, you lose the type-in advantage.

/mtr

ps: people who complain about the binary nature of snmp are actually  
complaining, whether they know it or not, about ASN.1/BER, which  
define how to describe and encode SNMP packets. i really should have  
listened more to chuck davin 20 years ago...

---

From: "Howard Kapustein" <[email-masked]>
Date: Fri, 22 Jul 2005 10:06:05 -0400

>So designing for human readability in what is inherently
machine-to-machine
>operation does not seem like a requirement,

I'd agree, except there's one flaw in your statement:

	Humans *are* involved.

Unless you've found a way for machines to build the machines to talk to
machines, but I thought SkyNet wasn't operational yet.

I've worked with a variety of protocols and formats, and to be honest if
I have to deal with one more friggin' binary protocol I'm going to have
the urge (yet again) to kill something.

The efficiency tradeoff is largely a red herring.
*Pragmatically* speaking, it's a wash.
There are some minor perturbations each way, but they're not
significant. Not in this space.

I've seen various encodings.
I've done the math.
I've written code, both high and level level, to build and parse such
data streams.
I've even shipped products.
***It's a wash.***

A *well-designed* text format is equivalent to a *well-designed* binary
format, in terms of size, memory utilization, parse efficiency and so
forth, for these needs.

But...when it comes to *using* the format, TEXT IS ALWAYS SUPERIOR TO
BINARY.

Unless someone knows a way to take the 'human' factor out of it.

Text formats are far more amenable to lower effort to use, to
troubleshoot and to do so correctly. They lower the barrier to entry.
The encourage more exploration more easily.

Given the technical delta is effectively nil, and the *human* factor is
significantly tilted in favor of a textual/non-binary format, I fail to
see how a 'binary' format is compelling over 'text'.

On the efficiency side, I would love to see someone challenge my
assertion -- WITH NUMBERS.

No anecdotes.
No opinions.
Cold hard clear factual values.

	- Howard

P.S. When I say 'text' I mean non-binary, in the traditional senses of
the words. XML is textual, but often fails the bandwidth/size issue vs.
other (esp. more specialized) text formats, designed for more efficient
size + utilization. XML is great for data not because it's inherently
great, but because everyone (esp. every vendor) agreed "it's good
enough". The *everyone* part is why XML is successful. YAML, JSON and
other formats are superior in some technical ways, but given the breadth
acceptance ("even if we don't love it, we don't hate it") it's often a
good solution. In this case? That's up for debate.

But ignore XML; it's a subset of 'text'.

In the 'binary' vs. 'text' Steel Cage Deathmatch, both will be bloodied,
both will be weary, and **the audience** will come on stage and crown
'text' the champion.

---

From: "Howard Kapustein" <[email-masked]>
Date: Fri, 22 Jul 2005 10:48:16 -0400

>basic Perl, Python or Ruby

Which of these is not like the others? :->