As we head toward interoperability of LTK Extension support between the different LTK Toolkits, it occurs to me that things would be more clear on the testing side if we reserve a few custom message and subparameter IDs for testing within the llrp.org namespace (PEN).
We can use those to design interesting custom messages and parameters which thoroughly exercise the extension infrastructure. This would result in an extension def file, an xsd and corpus of LTK-XML message instances, and analogous binary encoded format. Thoughts? The main thing is to come up with a set of fictitious custom messages and parameters that really exercise LTK Extension support. PEN conflict: Note that if another organization donated some IDs under their PEN as well, then we would also be in a position to test extension point support for the case that a single reader supports extensions drawn from multiple vendors. Unfortunately it doesn't appear that the IANA reserved any PENs for testing purposes, so using real ones with reserved ranges for this is the only way I can see to 100% safely do this. We could instead "borrow" numbers from the higher ranges since IANA seems to grant them from low numbers up. It would be very unlikely that we could ever conflict that way. -- John R. Hogerhuis http://devwrights.com/blog ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
