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: "Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>
  • Date: Wed, 15 Jul 2009 10:38:32 -0000

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




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


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.