Re: [6lowapp] SIP and 6LoWPAN & Some General Suggestions

[Shidan <[e-mail]>]

Sorry for the typo, I meant involve the WG responsible for SIGCOMP not the
conference.
---
Shidan Gouran

On Sat, Oct 17, 2009 at 5:00 PM, Shidan <[e-mail]> wrote:

> I don't think I have sufficient time to write anything other than a very
> high level motivation I-D on the merits of SIP, as defined by RFC 3261 &
> 3625, for ubiquitos computing and building automation. I will start this
> tonight and submit it sometime on Monday for sure. *
> *
> Here are some recommendations I have for this working group in general:
> *
> *
>
>    - With regards to the general 6LoWAPP problem statement, I suggest the
>    WG adopt the use cases of OpenHan as criteria for evaluating any application
>    protocol suitable for the 6LowAPP working group. Their use cases are the
>    most extensive that I have seen.
>
>
>    - I think before we consider any binary encoding, we must consider how
>    binary compression of application level protocols is done in current
>    bandwidth constrained communications networks like GSM. I certainly think we
>    would benefit from learning/involving SIGCOMM in making this decision. Power
>    contraint seems to me to be a much more unique issue this WG has to deal
>    with than bandwidth constraint.
>
> Now going back to the concepts of a specific binary encoding for SIP as a
> base protocol here are some ideas:
>
>    - Any method for binary compression of HTTP would work seamlessly with
>    SIP, so for example everything in section 2 of the Chopan I-D could be
>    applied to all SIP messages and follow the same request/response
>    model. Also, referring to the Chopan I-D, SIP already addresses sections  3,
>    4 and a significant portion of 5. For these purposes, no new extensions or
>    modifications to SIP need to be defined and it really becomes just a matter
>    of defining the message encoding. One area that needs to be addressed with
>    SIP is sleeping nodes and this is something we definitely need to think
>    about more.
>
>
>    - In addition, any type of binary encoding of XML, "ZigBee like" data
>    representations or anything else that can or will be transported by a binary
>    HTTP protocol, will also work with SIP as the mechanism is identical in
>    both.
>
>
>    - For security, relying solely on 802.15.4's AES is, in my opinion, not
>    a good idea. for example both SIP and, as Schmidt et al outlined, IPFIX
>    requires TLS and support of something like Tiny 3-TLS would also work well
>    for us*.*
>
>
>    - As I mentioned before, SIP as a base protocol can make gatewaying
>    with XMPP and some "real-time web" REST based protocols such as FeedSync or
>    ATOM Pub + PubHubSub, much more efficient. If we are defining all of this
>    using HTTP you are going to be defining heavier payloads than needed.
>    Describing this will take more time than I have for the motivational I-D,
>    this is something in the coming months I would be happy to expand on fully
>    if this WG considers it worthwhile.
>
>
>    - As much as possible, the 6LowPAN framework should be abstracted to
>    unify and fit commonalities in SNMP, SIP and "real time web" protocols. So
>    the way we define eventing, for example, should be done in a way that lends
>    to simple interfacing with systems that use any of the above.
>
> * *I would appreciate any comments or suggestions to this note before I
> start writing the motivational I-D later tonight EST.
> *
> *
> Shidan Gouran
>