Re: Re: version 1.3 of xAP documents

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

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
>
>
>
>
>



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