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

Arjun Roychowdhury <arjun.lists@hsc.com> Mon, 02 November 2009 16:17 UTC

Return-Path: <arjunrc@gmail.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 D5E443A680B for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 08:17:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 SH7hppkzeHwR for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 08:17:06 -0800 (PST)
Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 0B39F3A67AF for <6lowapp@ietf.org>; Mon, 2 Nov 2009 08:17:05 -0800 (PST)
Received: by qyk41 with SMTP id 41so2617792qyk.29 for <6lowapp@ietf.org>; Mon, 02 Nov 2009 08:17:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=/X2IbJzy+gZPrONnMRXGw5k3GHbYEfxyi8QUIFd/UnQ=; b=tI6a1prUUQSLySeVfrr3lQLsMbzB98ZbWSjoGSPP+1RoaxGIvhuQk40tQuSsIpb1Xm 0wqt2N67VAmp4Btz6vUKU7uWCFzouMPiOIEhR2OD9ItfR7xU+LvHHfi6z5nelDvh6uih YsolhVYE8MuNIUaeJ79aIPNw4EAlTir/2EEAs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=x6oXwvxM5cAYRSLwuzvPGmT/QyIxj0dl6GTxutgIvVGJC/gp3tQkJcZD3aM4UseMEc mP5o/xt6x3DEjQ+9LrK1GuTvRYLVHRQ2CQ9MiGDl7jDwgS9t5MLZqy4obJtxSy1Pwl+d zh/aKJ9tP9auDBExxvd1sGYVr1wQ+Nqu1P7L0=
MIME-Version: 1.0
Sender: arjunrc@gmail.com
Received: by 10.224.96.100 with SMTP id g36mr2930730qan.384.1257178643277; Mon, 02 Nov 2009 08:17:23 -0800 (PST)
In-Reply-To: <4AEF01B5.7020208@cisco.com>
References: <B27B00F8-1A4F-4258-86FC-C02E78778E45@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> <4AEDC3FD.3040801@cisco.com> <a9994e940911011309o6287b0d5r116bcf5329a1035c@mail.gmail.com> <a9994e940911011312g22582a3dpcbf0978755758aa@mail.gmail.com> <00FC4AA684E90E4DA2FF71021CD5A6CA010444@XMB-RCD-101.cisco.com> <4AEF01B5.7020208@cisco.com>
From: Arjun Roychowdhury <arjun.lists@hsc.com>
Date: Mon, 2 Nov 2009 11:17:03 -0500
X-Google-Sender-Auth: 9b5ffe6b847c97fb
Message-ID: <a9994e940911020817i6222eeb9xa9b9398a6e19317e@mail.gmail.com>
To: paduffy@cisco.com
Content-Type: multipart/alternative; boundary=00c09f9c98fd73aec7047765b6e2
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: arjun.lists@hsc.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: Mon, 02 Nov 2009 16:17:06 -0000

Some notes:

HAN will need req/resp,

ARC> SIP: MESSAGE/OK, OPTIONS/OK
In addition, SIP can exchange these as part of a session, or out of it.


pub/sub,

ARC> SIP: SUBSCRIBE/NOTIFY/PUBLISH

async one way messaging patterns, etc..

ARC> SIP: Implicit notifications (3GPP uses it, for example), but yes, specs
do require an OK in response. I am interested in this part. When you mean
one way, you mean no return acknowledgement from the peer at the application
level? What sort of scenarios is that required for?

 Req/resp RPC starts to get pretty weird over SIP.  Whereas it is a fully
supported pattern in XMPP world.

ARC> Only if you tag the word RPC after request response :) On the other
hand if one views it as a SIP message with an XML payload, then it fits
perfectly.

regds
arjun