Subject: [Rfid] SLRRP Vendor Extensions

From: Peter Spreadborough <[email-masked]>
Date: Wed, 20 Jul 2005 18:43:36 -0400

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

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 20 Jul 2005 20:55:45 -0400

Hi Peter,

Before deciding to add a vendor extensions mechanism to SLRRP, it 
might be useful to read the IESG document regarding vendor extensions:

http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt

This document is not a mandate against all forms of vendor extension, 
but it does make a good case that the use of vendor extensions should 
be extremely limited, as uncontrolled vendor extension mechanisms 
(such as the one you have described) tend to lead to incompatibility 
between different devices that can correctly claim to implement the 
same protocol.

If the group decides that vendor extensions are necessary, then it 
might be preferable to simply set aside a portion of the message type 
and parameter type values for IANA assignment with an appropriate 
level of documentation and/or review (as described in RFC 2434).

Margaret