Subject: RE: [Rfid] Newcomer Thoughts on SLRRP

From: "P. Krishna" <[email-masked]>
Date: Wed, 23 Mar 2005 22:48:01 -0500

Hi Suresh,
Thank you for reading the document. I'm glad you find SLRRP attractive and useful. 
 
If you think all the points that you have made regarding SLRRP to be important to your product, then your choice is clear. 
 
> If I am implementing *now*, then one option is to "hedge" my bets by using the SLRRP "byte stream", but encapsulated in the XML format (for 
> EPC Global).  
 
First off, just because a protocol is encoded in XML format, it does not make it look like any other protocol which also happens to be implemented in XML. So simply encapsulating SLRRP in XML is not necessarily hedging - you have already picked your choice. I think fundamentally, you have to evaluate what your requirements are for the reader interface, and figure out which alternative satisfies your needs.
 
Viewing it as a bytestream versus XML issue trivializes the differences in capabilities of two protocol approaches. As you and others have realized that there are distinct differences in approaches which stems from differences in the goals of the protocol.
 
> So... the challenge is to pick an implementation (of the reader/host API) *now* that is least resistant to future change.  
 
I think if we work concertedly towards standardizing SLRRP in the IETF, it like innumerable other RFCs, would be future proof. For that, we need folks like you who see value in the design philosophy of SLRRP to support, participate and contribute. You with your Class3 tags problems can add significant value by writing the protocol parameter plugins to SLRRP. 
 
Thanks,
Krishna

________________________________

From: [email-masked] on behalf of Suresh Bhaskaran
Sent: Wed 3/23/2005 8:44 PM
To: [email-masked]
Subject: [Rfid] Newcomer Thoughts on SLRRP

Hello Group,

I am a recent "newcomer" to SLRRP - I just read the document in great detail yesterday.  I had a lot of "lights" go on when I read the document.  And wanted to share some thoughts.

I am with Intelleflex, a long-range tag (semi-active) and reader solution provider.  I am working *now* on putting in some new "class 3" features on our reader, and am leading a software team here.

I emphasize the "now", because that is where I find SLRRP very attractive (in terms of ideas and concrete specification, not necessarily as a standard - since waiting for a standard may take a *long* time).

The things I liked (first impression) about SLRRP:

-          easy to *understand* and to implement (58 pages of text vs. EPC global of 240 pages RP plus another 120 for RM).

-          Very cogent and coherent

-          At the "right" level (for us - Intelleflex): I like the fact that multi-reader coordination at the RF level is thought about in this interface

-          I like the fact that it supports C1G2

-          I like the technical tradeoff exchanges in this forum - seem to be at the right level for us.

-          I like the well thought-out "Select" command.  I have felt that this is a *key* command.  Also, I like the fact that there is thinking at the Q-value level for anti-collision

-          I like the fact that there has been some "sensor data" thinking in the spec.  

Having said that, I am facing some challenges/tradeoffs relating to the actual implementation.

If I am implementing *now*, then one option is to "hedge" my bets by using the SLRRP "byte stream", but encapsulated in the XML format (for EPC Global).  

All the middleware vendors we've talked to are so used to building "device connectors" onto a new reader interface that they are willing to proceed with a reader partner even if they are not (currently) EPC Global compliant.  

But the challenge is to pick an API implementation (between reader and host/middleware/rnc) so that a firmware upgrade on installed devices in the future will not force the middleware partners to redo their host software.

So... the challenge is to pick an implementation (of the reader/host API) *now* that is least resistant to future change.  

Any those are my thoughts and some of the issues I am struggling with.

Any feedback?

Suresh Bhaskaran

Software Manager

Intelleflex Corporation

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