Subject: FW: [Rfid] SLRRP Vendor Extensions

From: "Suresh Bhaskaran" <[email-masked]>
Date: Thu, 21 Jul 2005 10:19:18 -0700

-----Original Message-----
Oops.  Thanks for he reminder, Peter.  I had meant to send this to the
entire list.

Suresh

------------------------

From: Suresh Bhaskaran [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2005 4:42 PM
To: 'Peter Spreadborough'
Subject: RE: [Rfid] SLRRP Vendor Extensions

The way this is defined, the vendor ID is a required field for *all* message
headers now?  Is this the intention?  

Might there be a way to leave the messages the same, and only include the
vendor ID in the message header if it is a vendor extension?

The V-bit as stated, is only for the parameter.  If we had the equivalent of
a V-bit for the message, then we don't have to include the Vendor ID in all
message headers?

Suresh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Spreadborough
Sent: Wednesday, July 20, 2005 3:44 PM
To: [email-masked]
Subject: [Rfid] SLRRP Vendor Extensions

To facilitate the support of vendor specific extensions, prior to formal
inclusion into the protocol, the following solution is proposed:

1. The SLRRP message header will be extended to include a thirty two bit
vendor ID field:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |x|x|x|x|x| Ver |  Message Type |       Message Length          |      
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Message Seq Num         |x x x x x x x x x x x x x x x x|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Vendor ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 :                        Message Value                          :
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. For SLRRP parameters a bit from the "user" bits will be assigned as
the Vendor or V bit.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | A |V|User |  Parameter Type   |       Parameter Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 :                       Parameter Value                         :
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3. A block of unused message types will be reserved for vendor
extensions.
4. A block of parameter types will be reserved for vendor extensions. 

SLRRP implementations may choose to ignore:
        - Any message types that fall in to the vendor extension range.
        - Any parameter types that fall into the vendor extension range.
        - Any parameters that have the V bit set. 

If the V bit is set in a parameter header then the vendor ID used in the
encapsulating message will apply. The parameter may then be accepted or
ignored based on the vendor ID. This applies to both defined message
types and extended message types.

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

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

---

From: Peter Spreadborough <[email-masked]>
Date: Fri, 22 Jul 2005 10:28:45 -0400

Suresh,

Your suggestion sounds like an interesting one, my understanding of it
is that the message format would now be:

 0
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|V| Ver |  Message Type |       Message Length          |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Seq Num         |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           Vendor ID                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                        Message Value                          :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Setting the V bit will indicate the presence of the VendorID field in
the message header. If the V bit is not set then the VendorID will not
be present. On receipt of a message with the V bit set an implementation
may decide to accept or reject that message.

NOTE: The error codes should be expanded to include a reason code to
indicate the rejection of messages or parameters with vendor extensions.

How would a standard SLRRP message, say GET_READER_INFO, be interpreted
if the V bit where set? would the V bit indicate that the
GET_READER_INFO message header where non-standard or that the parameters
are non-standard? 

Would parameters header also include a V bit as per my original
suggestion? 

Pete

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 22 Jul 2005 12:11:05 -0400

>may decide to accept or reject that message.

BTW, once you start having binary fields that are or are not present 
based on the value of other bits, you lose one of the advantages that 
David Husak claimed for a binary format -- that you can just put the 
received buffer in memory and access fields directly without the need 
to parse anything

The "slap it in memory and just access it" plan also runs amok of 
other issues such as alignment constraints, data packing issues and 
endianness.  All of those can be worked around by proper coding, but 
it is an implementation consideration whether handling straight 
binary access will/won't be cheaper (in time, code size or runtime 
memory use) than parsing the binary data into internal structures 
upon receipt.  If you add variable-length or conditional fields, 
you'll quickly determine that parsing it once is much more efficient 
(and less prone to small incompatibility bugs all over your code).

Margaret