FW: [Rfid] SLRRP Vendor Extensions

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

Suresh

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

From: Suresh Bhaskaran [mailto:sbhaskaran@intelleflex.com] 
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: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On
Behalf Of Peter Spreadborough
Sent: Wednesday, July 20, 2005 3:44 PM
To: rfid@ietf.org
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
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid