Re: FW: [Rfid] SLRRP Vendor Extensions

[Peter Spreadborough <[e-mail]>]

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


On Thu, 2005-07-21 at 13:19, Suresh Bhaskaran wrote:
> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Peter Spreadborough
> Sent: Wednesday, July 20, 2005 3:44 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rfid
> 
> 
> _______________________________________________
> Rfid mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rfid


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