Re: Re: version 1.3 of xAP documents

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

xAP v1.3 totally supports* xAP v1.2 so you can, should you wish still
write xAP v1.2 applications - but I would make them tolerant of xAP v1.3
applications that might be interacting with them.   It's not difficult
to switch from v1.2 to v1.3 though - you just change the v= parameter
and add a '.' and ':' into the UID.   The aspects of gracefully ignoring
extra parameters has always been promoted.

For example I found with my (v1.3) gateway that when I sent a
xAPBSC.query / xAPBSC.cmd message to a xAP v1.2 application it wasn't
responding which was dissapointing.  This was an xFX Framework based
v1.2 application being very fussy on message validation  I had to work
around this by keeping a record of which devices were xAP v1.2 and which
xAP v1.3 and originating the messages in the appropriate matching
format. This of course further necessitated me creating a dual heartbeat
device :-(

cheers Kevin

* xAP v1.3 does not support target= lines with bodies - but I am not
aware of any xAP app that used this (now deprecated) feature.



Daniel Berenguer wrote:
> I have another question:
>
> For new designs that don't need the additional features provided by
xAP v1.3, could we still use the old v1.2 format (with shorter UID's and
v=12) or should we switch to v1.3 anyway?
>
> Thanks again,
>
> Daniel.
>
>
> --- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
>> Hi Daniel,
>>
>>     Yes the ID field remains in BSC bodies - it can now be longer
of
>> course to support the longer sub addresses in v1.3 and should be
an even
>> number of uppercase hex digits, or a '*'.
>>
>>     Yes , all schema permit the multi-block  format, unless they
>> specifically forbid it , which allows for coincident changes to be
made
>> to several endpoints. Multi-block also guarantees that either all
>> changes or none are actioned (in the extremely unlikley event that
a
>> message be lost).  If the blocks are of the same type then you
should
>> index the blocknames ie block.1 block.2 etc as block names must be
>> unique within one xAP message.   A listener should therefore
recognise
>> either  'block' or 'block.1'  'block.2' etc.  This is especially
>> prevalent in the BSC schema as you mention.
>>
>>     One other thing that has changed in xAP v1.3 is that it is now
not
>> permitted to include target= lines within each of the different
>> multi-block bodies or indeed in any body.  A target= line is now
only
>> permitted in the xAP header.    In xAP v1.2 separately targeting
blocks
>> was permitted although AFAIK no-one every implemented it, or
handled it
>> correctly, because you had to logically AND the two target=
addresses,
>> which with wildcards was complex and messy.   So it's now
deprecated.
>>
>>     Just to recap also that in xAP v1.3 heartbeats can have
bodies,
>> bodies can be empty,  and you should gracefully ignore any
unexpected
>> parameter/values found within headers or bodies - which allows for
>> expansion of existing schema or headers.  Addresses used in
target= or
>> source= are case insensitive.
>>
>>     cheers Kevin
>>
>> Daniel Berenguer wrote:
>>
>>> Kevin,
>>>
>>> Do the xAP BSC commands still contain the "ID" field
in the body? Do these messages keep the multi-block body feature after the
new xAP spec?
>>>
>>> Thanks,
>>>
>>> Daniel.
>>>
>>>
>>> --- In xAP_developer@xxxxxxx, Kevin Hawkins
<yahoogroupskh@> wrote:
>>>
>>>
>>>> Steve, one more thing I forgot to mention....
>>>>
>>>> xAP v1.2 supported target= lines within the body(ies) of
messages -
>>>> effectively allowing the various body sections within a
single message
>>>> to be addressed to different devices.  This AFAIK has
never been used by
>>>> any applications and is awkward to implement as there are
then two
>>>> target filters in use. Nor do I know of any listener
application that
>>>> correctly handled it either. ......
>>>>
>>>> So... from xAP v1.3 this feature is now deprecated.
>>>>
>>>>    K
>>>>
>>>>   stevejbauer wrote:
>>>>
>>>>
>>>>> Thanks...  That's what I have been looking for!
>>>>>
>>>>> Steve
>>>>>
>>>>> --- In xAP_developer@xxxxxxx, Kevin Hawkins
<yahoogroupskh@> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Steven,
>>>>>>
>>>>>>     There's a formal spec, plus a rewrite of the
v1.2 spec imminent.
>>>>>> It's been delayed due to some aspects of the
specification that haven't
>>>>>> been finalised and so will now be deferred to a
future v1.4  (not
>>>>>> anytime soon).  The deferred aspects are not
impacting typical usage but
>>>>>> are desireable for some more demanding
applications  and include  long
>>>>>> messages, message continuations, sequencing,
acknowledges,
>>>>>> re-transmissions, authentication, security,
discovery and configuration
>>>>>> aspects.  These are essentially impemented using a
higher protocol layer
>>>>>> sitting on top of the v1.3 protocol and so will be
totally backward
>>>>>> compatible.   There are outline proposals for many
of these allowing for
>>>>>> experimentation within xAP v1.3.
>>>>>>
>>>>>>     The aspects that have been finalised for v1.3
include various header
>>>>>> and body flexibility changes - which are backwards
compatible with v1.2.
>>>>>>   The v1.3 UID format change however is mostly
compatible in that it is
>>>>>> transparent to nearly every existing xAP
application except those using
>>>>>> the xAP BSC or TSC schema which might need
updating.  Most affected
>>>>>> applications have already been updated .  A xAP
v1.3 application must
>>>>>> support existing v1.2  messages and UID formats
transparently so that
>>>>>> ensures forward compatibility.
>>>>>>
>>>>>>     Re the UID it has been changed from the v1.2
fixed length NNAAAASS
>>>>>> format to NN.AAAA:SS in v1.3.
>>>>>>     ie a '.' and ':' delimiting the three segments
has been added which
>>>>>> now allows any of these segments to be any (even)
length of uppercase
>>>>>> hex digits.
>>>>>>     The main reason for this was to allow
expansion of the sub address
>>>>>> field SS from the v1.2 two hex digits to longer as
many applications
>>>>>> required.
>>>>>>     In all segments values of all 0's or all F's
are reserved or have
>>>>>> special meaning.
>>>>>>
>>>>>> NN -  network number - usually the special all F's
representing the
>>>>>> local network
>>>>>> AA -  application/device ID (unique on the
network)
>>>>>> SS - sub address (if the application or device
implements multiple
>>>>>> endpoints) . All 0's represents the application
itself rather than an
>>>>>> endpoint within it.
>>>>>>
>>>>>>     Having previously said that any even number of
characters is now
>>>>>> permissable in any segment there are some
recommended formats that
>>>>>> suffice for most needs.
>>>>>> NN usually always two characters
>>>>>> AAAA usually four, six or rarely eight characters
>>>>>> SS usually  two, four, six or eight characters -
although some
>>>>>> implementations have used longer sub
addresses..(eg 1-wire 64bit 16chars)
>>>>>> All leading 0's must be included to maintain
consistent segment length
>>>>>> for the application
>>>>>>
>>>>>> A v1.2 UID of FF1234A2 is directly equivalent to a
v1.3 UID of FF.1234:A2
>>>>>>
>>>>>> Examples of v1.3 UID's:
>>>>>>
>>>>>> UID=FF.1234:00A6
>>>>>> UID=FF.AB34:67A203
>>>>>> UID=FF.000032:5C
>>>>>>
>>>>>> There are ramifications to the xAPBSC v1.3 Basic
Status and Control
>>>>>> schema (and xAPTSC)  but these are self evident I
hope as you read the
>>>>>> specification.
>>>>>>
>>>>>> Any questions .. ask away....
>>>>>>
>>>>>>   Cheers Kevin
>>>>>>
>>>>>>
>>>>>> Bauer, Steven J. wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Is there anyplace where a person can find
(even the draft spec) of the
>>>>>>> version 1.3 xAP??  I would like to support the
extended uid correctly
>>>>>>> in the programs that I am writing?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Steve Bauer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ------------------------------------
>>>>>
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>



------------------------------------