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

[Margaret Wasserman <[e-mail]>]

Hi David,

At 7:56 PM -0400 7/21/05, David Husak wrote:
>I'll suggest that the
>latency variation incurred by a text-based encoding, especially on a
>modest processor, is a real problem in the context of a protocol, like
>SLRRP, with real-time control requirements.

We've been around this block before, but without reaching a clear 
answer.  What are the real-time requirements for RFID reader 
control/management?  And, what are the minimum system requirements 
that we need to consider?  If we can't answer this for the entire 
industry, I think we at least need to reach a mutual understanding of 
the range of devices that we are planning to support with this 
protocol.

The stringency of the real-time requirements, and whether they exist 
at all, may be a function of the paradigm that we use for reader 
control/management.  As I stated in my earlier message, I would 
prefer a paradigm where a reader operates autonomously based on 
configured filters and policies, similar to an IP switch or router. 
I think that such a paradigm would be much more practical, much more 
scalable and much more in-line with the RFID reader applications I've 
seen, than a scenario where a large set of readers are micro-managed 
on a real-time basis by a centralized network controller.

Most of your real-time and scaling requirements seem to derive from 
your fundamental assumption that there will be a single controller 
providing real-time control for 1000's of readers, and I see no 
reason to build our protocol (or an RFID network) so that a single 
real-time controller is necessary in large-scale installations.

>At the risk of crossing the streams, it's important to recognize that
>SLRRP is not a management and configuration protocol. It is a control
>and data transport protocol for a real-time data acquisition device.

If this is the case, why do you believe that the IETF has any special 
expertise to offer here?  We don't have any experience (that I'm 
aware of, anyway) in developing real-time control protocols for data 
acquisition devices (although I'm sure that someone has used SNMP for 
this purpose).  We generally develop higher-level management and 
control protocols for devices (almost exclusively network 
infrastructure devices) that perform their main functions 
independently based on filters and policies, without consulting a 
controlling entity in real-time.

I think that RFID readers could be controlled and managed at the same 
level as most networking equipment, perhaps using some of the same 
mechanisms.  You seem to thinks so, too, since you mentioned that 
COPS-PR could be an interesting solution in this space.

IMO, though, it's not consistent to argue that these devices will be 
controlled and managed like networking equipment (which is the 
primary argument for why the IETF has any pertinent expertise here), 
AND to argue that these will be very minimal devices (without enough 
processing power or memory to deal with a simple text encoding) that 
will be controlled top-down with all of their real-time decisions 
made by a network controller.  When you add the notion that the data 
and control may be communicated over a low-bandwidth serial link, you 
have completely departed from any territory in which the IETF has any 
special expertise, as far as I know.

So, which is it?

Regarding the need for specialized clients...  I understand that you, 
as a middleware vendor, prefer a worldview in which people purchase 
commercial middleware products to access RFID readers (or run 
substantial open source packages).  As a reader vendor, I obviously 
don't want my product to require a high-priced commercial middleware 
package to be useful.  And, today we certainly see a large number of 
customers who prefer to write their own clients to access RFID 
readers, often using text processing languages like Perl, or even 
shell scripts.

Even in installations that use middleware, it could be extremely 
valuable to access the reader interface directly using test and 
debugging scripts, in order to determine if there is a reader failure 
or if the problem lies elsewhere in the system.

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.

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.

Margaret

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