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

Paul Duffy <paduffy@cisco.com> Sun, 01 November 2009 17:22 UTC

Return-Path: <paduffy@cisco.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB3C3A68B4 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glbkVaBnYhnt for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:22:52 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8F16F3A6896 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 09:22:52 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAP9S7UpAZnwM/2dsb2JhbADCAIEaCAGVL4Q5BA
X-IronPort-AV: E=Sophos;i="4.44,662,1249257600"; d="scan'208";a="65912267"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Nov 2009 17:23:11 +0000
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA1HNBU0004974; Sun, 1 Nov 2009 17:23:11 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 12:23:11 -0500
Received: from [10.86.248.248] ([10.86.248.248]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 12:23:10 -0500
Message-ID: <4AEDC3FD.3040801@cisco.com>
Date: Sun, 01 Nov 2009 12:23:09 -0500
From: Paul Duffy <paduffy@cisco.com>
Organization: Cisco Systems
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: d.sturek@att.net
References: <B27B00F8-1A4F-4258-86FC-C02E78778E45@cisco.com> <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <CE5B892A-3699-4CBF-8B6A-588F5A7DE99A@cisco.com> <EB735931-0D15-4017-94F1-3B10A0EC814D@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <A4C590B945EF374AB02BB6A2EAA4485808B4C76271@EXMBX01.apps4rent.net> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net>
In-Reply-To: <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Nov 2009 17:23:10.0594 (UTC) FILETIME=[FC21F620:01CA5B17]
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: paduffy@cisco.com
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2009 17:22:53 -0000

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