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

From: [email-masked]
Date: Wed, 3 Aug 2005 09:35:55 -0500

It's a hard pill to swallow, but I'm lining up in agreement with Scott: the
standard is gonna have to come down to one encoding to be effective.

Rob

-----Original Message-----
From: Scott Barvick [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2005 4:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Rfid] XML vs. Text vs. Binary

Rob and Bud raise a topic that has not yet been fully addressed in the
midst of this discussion - the notion of multiple representations of the
protocol.   

This is even different from the carrying the PDUs over multiple
transports (e.g. TCP, serial, ethernet).  As raised in a previous
thread, the concept of supporting transport of SLRRP PDUs over a non-TCP
(serial) transport, while not currently in the initial SLRRP scope, does
not seem to pose a significant burden in terms of specifying,
implementing, or testing.  All of the differences are isolated in the
transport, and the same core protocol code is executed regardless of how
you transport the PDUs to a particular peer.   

However, the idea of specifying different encodings (profiles),
particularly in the case of human readable vs. binary is something that
I feel would not result in an efficient standard nor an efficient
standard development experience.  You end up with not a single protocol,
but as many protocols as you have representations, and the only thing
common about them may be an initial capabilities exchange.  Each
representation then needs the full round of functional, system, and
interoperability testing that would go with any new protocol.  Of
course, interoperability in this sense means only between
implementations of the same encoding, not implicitly for the all
encodings of the protocol.  The base goals to date have been to focus on
a single representation that would have the widest applicability so that
a standard could be developed and deployed as quickly as possible. 

My thoughts only, of course.  I'm sure there are others out there.

Scott  

On Tue, 2005-08-02 at 15:50, Bud Biswas wrote:
> I see the usefullness of both XML and binary to different vendors.
> Altho' it is true that programmers will generally prefer binary to
> work with, XML is also useful to a different user community (non
> programmers). My preference would be to see that Readers support
> binary as mandatory and XML as optional along with the Middleware
> supports binary as input from reader (mandatory) and XML input as
> optional. This will allow us to build both "thin" readers as well as
> "heavy duty" readers where the readers support XML also and may
> include the middleware software.
>  
> Bud Biswas
> 
> [email-masked] wrote:
>         Viewpoint from another hardware vendor: 
>         
>         If SLRRP gains traction we'll probably want to adapt it to a
>         reader module
>         with a serial interface to maintain a common interface between
>         readers.
>         However, if SLRRP is XML-based I don't think it will be viable
>         for serial
>         I/O. A minimal text protocol is marginal over serial. Adding
>         XML (even if
>         minimal) pushes the bandwidth over the top.
>         
>         I agree with the human readable arguments of text vs binary.
>         With text
>         we've experienced lower training and support costs, faster
>         time-to-market,
>         etc. However, I foresee RFID development becoming more
>         specialized with the
>         proliferation of readers in the supply chain. It's likely that
>         vertical
>         application developers will only concern themselves with a
>         high-level
>         ALE-like interface. RFID middleware developers will grapple
>         with the
>         low-level interfaces. We have a! group of network programmers
>         that tell me
>         they prefer a binary interface. They have tools (LAN
>         analyzers, etc.) to
>         work with binary so they're not concerned with human readable.
>         They argue
>         that programming to a binary interface is easier/higher
>         performance than
>         parsing text.
>         
>         Rob Buck
>         RFID Software Architect
>         Intermec Technologies, Corp.
>         Ofc: 641-472-3082
>         Cell: 319-573-5294
>         
>         -----Original Message-----
>         From: [email-masked]
>         [mailto:[email-masked]] On
>         Behalf Of Margaret Wasserman
>         Sent: Saturday, July 23, 2005 8:15 AM
>         To: Marshall Rose
>         Cc: [email-masked]
>         Subject: Re: [Rfid] XML vs. Text vs. Binary
>         
>         
>         Hi Marshall,
>         
>         I think we are mostly in agreement about the technical
>         trade-offs, 
>         but for some reason that doesn't lead us to the same
>         conclusion...
>         
>         At 9:16 AM +0530 7/23/05, Marshall Rose wrote:
>         >this brings us back full circle: as soon as you have any
>         level of 
>         >nesting, human! type-in becomes problematic. as soon as you
>         decide 
>         >that human type-in isn't mandatory, it is trivial to include
>         a 
>         >standard library to do the heavy lifting while the humans
>         invoke the 
>         >tool using textual commands.
>         
>         Yes, if there is any significant nesting, I agree that a human
>         will 
>         not be able to type the commands in from memory and/or by
>         glancing at 
>         a reference sheet. However, I don't see any reason why this
>         protocol 
>         would require significant nesting, at least for the types of
>         commands 
>         that a human is likely to use directly.
>         
>         With a text encoding, a human could also have certain prepared
>         commands and be able to cut and paste them into the interface
>         -- a 
>         command to reset autonomous operation, for example, or to set
>         a 
>         reader to its default state. Or they could write simple
>         scripts that 
>         would send specific commands or command sequences.
>         
>         >in other words, from where i sit, XML, cXML, etc., enjoy all
>         the 
>         >drawbacks of both purist approaches.
>         
>         Correct, from a "human typing" standpoint, XML, cXML and a 
>         specialized text encoding are all roughly equivalent. However,
>         in my 
>         opinion, they are all much better than a binary encoding.
>         
>         There are two factors involved here, and all three of these
>         choices 
>         (XML, binary or specialized encodings) are fundamentally
>         different 
>         WRT these factors:
>         
>         (1) Can the incoming stream be parsed by a widely available
>         parser, 
>         or is a specialized parser necessary. XML parsers are
>         available for 
>         all likely client systems, but a specialized text encoding or
>         a 
>         binary encoding would require a specialized parser. BTW,
>         subsetting 
>         XML _does not_ require a specialized parser. Reader vendors
>         might 
>         want to includes a specialized (smaller or faster) parser and
>         simply 
>         reject XML constructs that are not included in the subset, but
>         clients could use a regular XML parser for this purpose.
>         
>         (2) Can ! text processing tools be used to send control
>         messages and 
>         interpret the responses, or would binary processing be
>         required. 
>         Both XML and a specialized text encoding would allow text
>         processing 
>         of the messages and results, while a binary encoding would
>         require 
>         binary processing.
>         
>         You've indicated that it is possible, with a binary encoding,
>         for 
>         clients to run a tool that gives them text-based access.
>         That's 
>         true, but users would need to _get_ that tool from
>         somewhere... So, 
>         we are back to requiring specialized code on the client side
>         to 
>         access this protocol.
>         
>         This isn't a religious issue with me -- I've just learned the 
>         benefits of text-based encoding the hard way, and I don't want
>         to 
>         deal with another binary protocol... So, for the moment, we
>         may have 
>         to just agree to disagree. We'd obviously need to resolve this
>         before we can move ahead, though.
>         
>         Only a few of us have expressed any opinion on this subject.
>         Are there others out there that have an opinion? There are two
>         questions 
>         that I'd especially like to hear answered by specific other
>         people on 
>         this list:
>         
>         (1) I'd like to hear from other reader vendors about whether
>         they 
>         think that XML would place a prohibitive burden on their
>         readers. It 
>         has been asserted that XML would have prohibitive system
>         requirements 
>         for the reader. That certainly isn't true of ThingMagic's
>         networked 
>         readers. In fact, using a standard parser, like XML, would
>         reduce 
>         our development (especially debugging) and testing costs 
>         substantially, and would make it more likely that we would
>         implement 
>         this protocol.
>         
>         (2) It would be very interesting to know if RFID users would
>         see any 
>         benefit to a text-based encoding. Are there folks on this list
>         who 
>         have RFID installed in real-world or even pilot installations
>         (not 
>         just a few units in a test lab)? Do you have any opinions
>         about 
>         whether the ability to access t! he reader using text-based
>         tools from 
>         a client system that doesn't have a specialized client (or
>         library) 
>         installed would be useful? Or do you see this as having
>         little/no 
>         value?
>         
>         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." 
>         
>         _______________________________________________
>         Rfid mailing list
>         [email-masked]
>         https://www1.ietf.org/mailman/listinfo/rfid
> 
> 
> Polaris Networks
> your source for rfid test tools
> 
> ______________________________________________________________________
> _______________________________________________
> 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."  

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

---

From: "Suresh Bhaskaran" <[email-masked]>
Date: Wed, 3 Aug 2005 09:39:53 -0700

What attracted me (us) about SLRRP from the beginning are the following:

You might say that it "met" certain requirements that were important to us:

1.  A "minimal" "full" reader that is networked, and yet exposes enough air
interface parameters to allow useful "RF subsystem management" at a
multi-reader level
	a.  by "full", I mean basic RFID functionality: read EPC numbers,
read/write memory, etc., as well as the basic management functionality: e.g.
set reader config, get reader info (e.g. status, health, etc.), as well as
some basic asynchronous messages (e.g. Reader Status Report that is sent
asynchronously).
	b.  Multi-reader RF subsystem management is going to be (is already)
a *very* important part of scalable RFID deployments

2.  I liked the way the TLV's "tiled" together: very conceptually easy,
clean, and easily extensible.

3.  The fact that the "networking" part of it was standard: i.e. TCP/IP, can
draw on existing TCP/IP security, and other internet technology

4.  Also, it (meaning a low-level reader) can be abstracted to a higher
level, if desired (e.g. ALE or portions thereof).  It is much easier to go
from a "low-level" abstraction to a higher-level.  Much harder to do the
other way around (since the important elements have already been abstracted
away).

5.  The read/modify/write timing (provided by the Access specs in SLRRP) is
very attractive.  The read/modify/write time is one of *the* critical timing
requirements for an effective reader.  We can't abstract away the
"tightness" of this loop -- it directly affects overall read rate.

6.  There is some thinking in the SLRRP spec about sensors and memory (very
important future extensions RFID, it seems to me).

7.  It has thought about scalability and discovery (although discovery may
move to a separate topic, as might the "management" part?!).  I like the
"integrated" nature of SLRRP (i.e. *not* a separate standard for
operational, and management, and discovery, etc. -- that "splinters" it, in
my view).

8.  Basic triggering, and filtering is included (not the type of filtering
necessary at ALE level, but nonetheless, some *basic* filtering: e.g.
eliminating duplicates, matching a set of EPC numbers, etc. (refer to the
Access Spec of SLRRP).

In Summary, I think the SLRRP is a *very well* thought out spec, at the
"right level" that it needs to be.

Hopefully, some of the points I shared could also serve as the basis of a
"requirements", and a "charter focus" for SLRRP. 

SLRRP is an excellent balance  beween "real-time", and "abstraction", and
"networked" and "full reader" and "simple".

Suresh Bhaskaran
Intelleflex.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, August 03, 2005 7:36 AM
To: [email-masked]
Subject: RE: [Rfid] XML vs. Text vs. Binary

Rob

-----Original Message-----
From: Scott Barvick [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2005 4:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Rfid] XML vs. Text vs. Binary

Scott