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

[Margaret Wasserman <[e-mail]>]

Hi Marshall,

At 8:17 AM +0530 7/22/05, Marshall Rose wrote:
>i guess we'd need to agree on the meaning of specialized before 
>agreeing on this point.

Yes, absolutely.

The distinction I would make is that "specialized" == written 
specifically for this protocol.

A TCP/IP stack, an SSL client and a canonical XML parser aren't 
specialized, because those are widely deployed technologies that are 
used for things other than this specific reader control protocol. 
They are already available for most OS's and HW platforms, there are 
embedded and non-embedded versions of them available, etc.

A parser for a SLRRP-specific text or binary protocol and/or a 
library that understands how to break higher level functions into 
specific SLRRP commands would be "specialized", by my definition.

As an example...
If SNMP's subset of ASN.1 and/or it's BER encoding had been more 
widely used, then there might have been widely deployed, 
non-specialized tools that could encode/decode SNMP PDUs (there 
aren't, unfortunately).  However, SNMP's PDU structure is specific to 
SNMP and requires a specialized tool to parse incoming messages 
and/or format outgoing messages.

IMO, the more we can leverage non-specialized, widely deployed 
technology (such as TCP/IP, SSH or TLS, XML, etc.) on both the client 
and reader sides, the better.  People will be able to build clients 
and/or readers that are stable and robust in much less time if they 
can use tools/libraries for this purpose that have already been 
written and debugged.  It lowers the barrier for entry and (most 
importantly, IMO) makes it possible for anyone with basic Perl, 
Python or Ruby programming skills to interact with a reader using our 
protocol and widely-available tools and libraries.

My preference for using canonical XML is based on three things:

(1) I think that we should focus only on network-connected RFID 
readers.  There are very limited, low-cost DSP-only readers available 
(including one from ThingMagic), but these are embedded modules that 
are accessed over serial lines from a host CPU, and they are included 
in devices like label printers and box folders.  If it is necessary 
to control the RFID reader portion of these devices over the network, 
that will have to be done through the host CPU, anyway.  It isn't 
practical to put TLS/TCP/IP on those embedded devices, so the fact 
that it isn't practical to run an XML parser on those devices is 
moot, IMO.

(2) There are embedded (or embeddable) XML parsers available (like 
expat) that can parse canonical XML using a SAX parser.  These 
parsers are neither CPU-intensive nor memory-intensive compared to a 
TCP/IP stack, DHCP, TFTP (or FTP or both), NTP, a DNS resolver, HTTP, 
TLS, OpenSSL (or your favorite encryption library), some web pages, 
SSH (or Telnet?), some command-line management/configuration tools, 
and all of the code necessary to implement EPC Global's Gen2 
specification including the anti-collision and dense reader mode 
features. I fully expect that all of this (and maybe more -- SNMP, 
MIB-2 and RFID MIBs?) will be available on every network-accessible 
Gen2 RFID reader.

(3) I do not believe that we should design RFID networks so that 
there is a real-time requirement for communication of control data 
between a controller and many readers.  But, even if we did, I cannot 
picture a world in which the XML parsing is a big latency factor in a 
system that involves network transmission of control information over 
TLS/TCP/IP on the same network that is used for the data 
communication.

I understand, though, that some people do not find XML acceptable 
because of its bandwidth requirements...  If that is a real concern 
(and I'd like to see some explanation of why it would be a real 
concern), then I'd like to see if we could address that concern 
through _how_ we encode the information in XML, or through a 
specialized text encoding.  Either approach would still maintain some 
of the benefits of XML -- like the ability to interact with the 
reader using text-processing tools without using a specialized (as 
defined above) parser on the client side.

Margaret




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