LLRP 1.1 is in progress. Since this is a minor version change only, I'd expect
that backward compatibility is required in the LLRP binary (by backward
compatibility I mean that any old packet is valid against the new packet binary
definitions). Because of this, I suspect the following rules will apply to
their changes
1) The following shall be avoided by a compatible version 1.1
a. New mandatory parameters
b. New fields
c. Changing any existing field
d. Changing any enumerations
2) New functionality will be added in 1.1 via
a. New optional parameters
b. Extending enumerated types
c. Using reserved bits
d. Adding new messages
e. Using custom extensions
For the LTK, we've clearly got a new definition file and *LTK-XML schema* to
consider. To parallel the 1.1 effort, we'd want this new schema to be backward
compatible with the old schema. That is "any XML file that is valid against the
old schema shall also be valid against the new schema." The opposite is
clearly not true.
I think we can quickly ascertain that 2a, 2b, 2d, and 2e are not likely to
cause any backward compatibility issues with LTK-XML. However, 2c is a
definite problem. Although it won't cause incompatibility in the binary
protocol, it will break backward compatibility in LTK-XML.
For example, suppose LLRP 1.1 adds a new capabilities bit to the
GeneralDeviceCapabilities parameter. Currently, its defined as
<field type="u16" name="MaxNumberOfAntennaSupported"/>
<field type="u1" name="CanSetAntennaProperties"/>
<field type="u1" name="HasUTCClockCapability"/>
<reserved bitCount="14"/>
Etc.
In the new version, it may very well be defined as
<field type="u16" name="MaxNumberOfAntennaSupported"/>
<field type="u1" name="CanSetAntennaProperties"/>
<field type="u1" name="HasUTCClockCapability"/>
<field type="u1" name="HasSomeNewLLRP1p1Capability"/>
<reserved bitCount="13"/>
Etc.
Since these are "fields" according to LTK-XML they are mandatory schema
elements.
<xs:element name="MaxNumberOfAntennaSupported" type="xs:unsignedShort" />
<xs:element name="CanSetAntennaProperties" type="xs:boolean" />
<xs:element name="HasUTCClockCapability" type="xs:boolean" />
<xs:element name=" HasSomeNewLLRP1p1Capability " type="xs:boolean" />
And the addition of a new one would clearly break backward compatibility as
defined above. That is, an old GET_READER_CAPABILITIES_RESPONSE would not be a
valid packet according to the new schema
Comments? Questions? Advice?
Regards
Paul
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
