Re: Proposal / RFC: Change xAP wire format

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

Kevin, I too think that the BSC schema has been one of the best
promoters of xAP along these years. My respects for a schema that has
proven to be so flexible, powerful and durable. I just meant that BSC can
not cover all needs in terms of modern M2M techniques but the lack of a
complementary schema forced us to blow up BSC beyond its natural limits.

> > Secondly, if you were working on the assumption of TCP based
networking
> > (and it must be that 99.999% of working implementations are..),
would you
> > use the UDP broadcast mechanism as-is, without some form of
assured
> > delivery? Whilst rare, UDP packet loss, can cause significant
issues when
> > xAP is being used for heating control, lighting,
sprinklers/irrigation,
> > etc., where there is M2M interaction. Wireless only exacerbates
this. So at
> > some level, I feel, this needs addressing as part of a next
generation xAP.
> >
>
> RFC3208 (Pragmatic general multicast) is one way to assure UDP
delivery.
> Simpler schemes, such as a sequential sequence number would also work,
but
> would probably end up evolving into something similar to PGM
eventually.
> (Reliable delivery over non-TCP wireless is whole different ball game,
and
> would be better addressed at the link-layer IMO.)

I agree with Patrick here. Maybe not in the scope of an Application
Protocol like xAP. On the other hand and always application-side, many
protocols provide their own mechanisms to acknowledge packets. BSC for
example, with its command/event and query/info duality has acted as a nice
mechanism to check receptions.

> Which of course comes down to how should any evolution be managed? Who
> > should manage this? Should there be a committee? An RFC like
process? Should
> > non-standard implementations be 'jumped on', to maximise long
term
> > interoperability? Is there any appetite for this amongst the
developer
> > community?

I'm pretty sure that a hypothetic evolution of xAP towards the adoption of
JSON or any other language superstructure will not change things
drastically in terms of popularity. However, we'd be able to open some new
doors that are currently closed.

How to manage the creation of a new specification? Well, we have a huge
advantage compared to other open organizations: we are likely just a dozen
of people willing to work on a new spec. I've been following the work of
the CORE (M2M app layer over 6LowPAN) group for some months and it seems
obvious that the time spent in the definition of the specifications is
directly proportional to the amount of people participating in the work
group.

When the time arrives we may try to mimic other organizations and even
propose the creation of a working group in the IETF if necessary (too
overkilled IMO but it's a possibility). At the moment, we may still listen
to other developers before taking further decisions. By the way, a lack of
interest usually means that thinks need to change in some way.

Patrick, since you suggested this evolution, I think that you could
moderate this topic until we decide whether to work or not to work on the
new specification. What do you think?

Finally, apart from the pure technical work, we must consider that a
structural modification of the protocol like this one will require us to do
some extra work in other areas, most of them currently (and exclusively)
undertaken by Kevin H (thanks again Kevin):

- Creation of new documentation
- Update of the current wiki pages
- New efforts on promoting xAP with its new implementation

--
Daniel Berenguer
http://www.usapiens.com
http://www.opnode.org
http://panstamp.blogspot.com



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