The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: version 1.3 of xAP documents


  • Subject: Re: version 1.3 of xAP documents
  • From: "stevejbauer" <Steve.Bauer@xxxxxxxxx>
  • Date: Mon, 18 May 2009 05:36:12 -0000

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




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


xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.