Re: version 1.3 of xAP documents

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

I have another question:

For new designs that don't need the additional features provided by xAP
v1.3, could we still use the old v1.2 format (with shorter UID's and v=12)
or should we switch to v1.3 anyway?

Thanks again,

Daniel.


--- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
> 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
> >
> >
> >
> >
> >
>




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