Re: [6lowapp] Proposed charter for 6LoWAPP BOF

[Shidan <[e-mail]>]

Hi Vlad,  I think a good question to ask yourself is why all of these
patterns are being created on the web, whether comet, Ajax, PubHubSub, or
actually why there is a need by the web community and the IETF to create
whole new protocols like WebSockets and Adobe Flash's TCP sockets.

The reason is because this is how the web has evolved. If it wasn't for the
business competition and related politics, I really doubt the evolution of
the web browser to being a standardized OS would be the case, which is where
we are headed. Thankfully, right now we don't have this problem with the
"Internet of Things" and the truth is, this working group will be an
important influencer of the IoT's evolution.

If you choose to follow the architectures you specify, at some point it's
going to look more like XMPP or SIP,  the only difference being you will
actually be defining all these things in the body and with more complicated
call flows. This is why new trends of the real time web should not
necessarily be a model for everything else for everything else in IT.
So I think a good analogy is we can build a web browser in assembly
language, but that wouldn't be the best route to building a good product.

I think we have to realize, putting away the immense role it had for
circumventing bad politics,  the web's real technical contribution, and
probably one of the most important, was a practical implementation of linked
data and hyperlinks. I think this will remain a major enabler of any
pervasive and global M2M application and this higher layer will not be in
the scope of the IETF just as much a the DOM isn't.

On Sun, Nov 1, 2009 at 1:29 PM, Vlad Trifa <[e-mail]> wrote:

> Hello,
>
> I think for Web messaging there are very nice Web push patterns emerging
> (comet, pubsubhubbub, restms) that are worth considering. Sure, work is
> needed for reliability and security, but the entry barrier is much lower
> than xmpp, and its actually more suited for devices with similar features
> but less verbose which makes that solution appealing. I'm sending a paper to
> WWW about Web based messaging, hopefully I'll be able to share it with you
> soon (if I kick my butt enough to get back to work and finish it by
> tomorrow's deadline :)
>
> Vlad
>
>
> On Nov 1, 2009, at 6:23 PM, Paul Duffy wrote:
>
>  Hi Donn,
>>
>>  We welcome other suggestions like XMPP and SIP but we did look at those
>>> and
>>> ruled them out for reasons like:
>>> 1)  Verboseness (using text string exchanges for devices with very small
>>> transmit/receive packet sizes)
>>> 2)  Session management overhead
>>>
>>>
>>
>> SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered
>> intent.
>>
>> But XMPP gives me pause...
>>
>> - would not an EXI encoding go a long way to alleviate the verbosity
>> issues?
>>
>> - RESTful HTTP is a fine choice, but there are requirements for more than
>> just request/response messaging patterns in the Smart Grid HAN and NAN.
>>  XMPP would offer request/response (sensor reading), pub/sub (broadcast
>> announcements), one way async (scheduled reads), presence for endpoint
>> status, etc.
>>
>> - how is XMPP session management any more onerous that HTTP over TLS?
>>  This assuming of course that TCP is doable.
>>
>> Cheers
>>
>>
>>  Don
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
>>
>
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp
>