RE: Experimental TESTxx header usage.

[Ian B]

I certainly did miss this line on the first pass. Even if I had seen it I
would probably have misunderstood it in its current context. I think it
should have had a section of its own rather than being tucked away in the
target section. Never mind though, it is there and I did miss it so water
under the bridge.

Now, how to fix it. Although I use C I am not a particularly accomplished
programmer and I honestly cannot think of a code space efficient algorithm
which will allow me to match against strings in flash or EEPROM (different
access methods) one character at a time and know the difference between a
valid segment, an unexpected segment and rubbish because something has gone
wrong. If for some reason I had corruption and missed the open and close
brackets in the middle of the message I would end up trying to evaluate the
body as a header and ignore all the pairs. If I then missed the <ETX>
this
would cause the unit to lock up as it would be continually trying to
analyse
a message header. I know this is a worst case scenario but this is the way
I
work - thorough (except when reading the spec it seems). Any advice here
would be very welcome.

As for the bit where the version number changes, this is a valid point and
one I had not thought of. I think the answer here is simply to ignore the
bit after the 'V' and not fail on this at all. This will effectively give
me
compatibility with all versions although it may fail elsewhere.

Ian (hoping for some wizzy C advice)

>-----Original Message-----
>From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=FmuLgzppZiYldd1E1l25Z5egHnops0RDfDqKWQgumdlasLFO29r3I8ILvED80nGdVm02oVNCI7Bt2hObIvjmOHY">lists@u...</a>]
>Sent: 05 August 2003 23:24
>To: <a
href="/group/xAP_developer/post?postID=3ydgYkR9PSQbpCNV3rkIYYRx1SIGEq9daA_o_Emr7RWbBuXV1RLpK-CGrBlbiuG3_6K3nPvaMjvJbUmsGN7RZWpJjQ">xAP_developer@xxxxxxx</a>
>Subject: RE: [xAP_developer] Experimental TESTxx header usage.
>
>
>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 &amp; 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
>
>
>
>
>
>
>
>
>To unsubscribe from this group, send an email to:
><a
href="/group/xAP_developer/post?postID=uVlnrOiojMS1iJNKLfgWHv1YjhVBLWf9E44_11n7DD7MPauxV1SO8HFaStG1gQFG4r7ucPA-4w4JoENHFe4TiKXaUeeuXclQ26iZuJ4Ifwu9iA">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
>Your use of Yahoo! Groups is subject to <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>
>
>
>