RE: Experimental TESTxx header usage.

[Kevin Hawkins]

Woooah.. Yes you seem to have missed a couple of points here Ian.. let me
quote from firstly your text..which in itself was a quote from the v1.2
spec

>Ian B said:-
> Quote
> A device should ignore all unknown name, value pairs included in the
> header.
> /Quote

Now assuming that you have incorporated this within your application then
nothing we are doing here will upset your firmware coding at all - the spec
says that you should ignore all the name/value pairs in the header that you
don't recognise and thus when a Test01 name/value pair is seen it will be
ignored. We actually thought very carefully about supporting expansion
within xAP 1.2 and this was one of the ways of doing that and ensuring
forward compatibility. Your implementation will remain a fully 1.2
compliant
and functional application.
As a related comment I would strongly suggest that the same approach
is taken with unknown or unexpected name/value pairs in the body. Just
gracefully ignore them - it stops you breaking.

Secondly - I'm going to quote again from your post and then my original
post

>Ian B said :-
> The word 'test' does not even occur in this document (according to
> Windows
> search) so to say I was surprised doesn't really cover it!

>Kevin Hawkins said :-

> The xAP specification committee agreed in the v1.2 spec release,
>(although we did not publish it), to allow the inclusion of TEST
headers
>within xAP messages

please note the bit that says "although we did not publish
it"....

So I'm sorry it was a surprise but I hope it's a pleasant one -
there is now the possibility of new feature experimentation in a way that
is
totally forward compatible with all v1.2 compliant implementations.
The new features that we are debating, and have been for a couple of
months now, are being looked at to support confirmed delivery of messages
and message integrity. The natural placement for such a feature is the
header. This feature is lacking in a general udp broadcast environment,
although I realise you are serial based with your product. Whether we
actually go to the conclusion of including this in a specification revision
to xAP and whether this is an optional or required feature for v1.3
compliance is still being evaluated. Hence the use of the
"Testxx"
name/value pairs. Whichever way you will remain with a v1.2 compliant
product and a V1.3 compliant product would be aware of any feature
shortages
of lower spec versions.
Just also to mention - I do not envisage v1.3 - should there ever be
such a version - invalidating v1.2, in the way that happened with our
revision from v1.1 to v1.2. The very fact that we have got this far, with
many applications and without any apparent rumblings about issues with v1.2
is testament to us getting it (mostly) right. Any future release should be
layered on top of the existing xAP spec, operating transparently to
existing
revisions or, as an alternative & wherever possible, by using
higher level
policy layers. This was a paramount design cornerstone we strived to
achieve
with our laborious discussions over v1.2 , it took a while but I feel we
achieved it.

Lastly..

Ian B said :-
> Having said this if I simply say in the supporting documentation that
> the
> unit only supports the following header format is this enough?

If you support the v1.2 spec as it stands with it's defined headers
and you have heeded the line in the spec that states "ignore unknown
headers" then you will be fine - you are v1.2 compliant. If you
abandon
message parsing when you receive a Test00=whatever pair then no it really
is
not v1.2 compliant. Of course you could identify this as an issue but I
feel
it's a deficiency and reflects badly, as it will make you deaf to certain
xAP v1.2 compliant senders.
As to how rigorously you validate you might want to consider this in
terms of what would happen if for example the version number changed from
v1.2 to say v1.3. How to handle this however is not clearcut. No-one can
predict the future. As an alternative to rigidly discarding al non v1.2
packets maybe somewhere you should maintain a known latest compatible
version number that is updateable in RAM/Flash somehow. Then you can move
forward in a controlled way if and when xAP evolves.

Kevin