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