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@yahoogroups.com, 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@yahoogroups.com, 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
>
>
>
>
>