Re: [core] CoAP requirements and HTTP iwf

Robert Cragie <robert.cragie@gridmerge.com> Fri, 26 March 2010 14:51 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4243A6827 for <core@core3.amsl.com>; Fri, 26 Mar 2010 07:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.132
X-Spam-Level:
X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 wnig3JtSgHt0 for <core@core3.amsl.com>; Fri, 26 Mar 2010 07:51:34 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 5E4A13A680F for <core@ietf.org>; Fri, 26 Mar 2010 07:51:33 -0700 (PDT)
Received: from 72-254-61-93.client.stsn.net ([72.254.61.93] helo=[10.7.39.29]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NvAt2-0002Ua-Ce; Fri, 26 Mar 2010 14:51:51 +0000
Message-ID: <4BACC9FF.1010606@gridmerge.com>
Date: Fri, 26 Mar 2010 07:51:43 -0700
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: d.sturek@att.net
References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net>
In-Reply-To: <009601caccea$e0443360$a0cc9a20$@sturek@att.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms060204060609050305030601"
Cc: core@ietf.org
Subject: Re: [core] CoAP requirements and HTTP iwf
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2010 14:51:35 -0000

I guess there are two approaches:

   1. Do a clean-room protocol design specification based on the
      specific requirements for CoAP
   2. Analyse existing relevant protocols, i.e. HTTP and others (such as
      those listed by Adrian) and distil the essence of them into the
      design specification

You could summarise these approaches as (1) purist and (2) practical 
approach.

The main issue with (1) is that we could end up with a protocol which 
doesn't map cleanly to anything. This in itself may not be a problem if 
mapping essentially always means proxying at an application gateway.
The main issue with (2) is what Don says below, i.e. it may be a 
compromise which doesn't meet the primary requirements. On the other 
hand, if done correctly, it could provide the optimum protocol for 
mapping onto a few key existing protocols.

One advantage of the RESTful style is that it does provide constraints 
on a protocol usage, so any existing protocol which can be used 
RESTfully is probably going to end up mapping at least fairly cleanly to 
whatever is developed for CoAP.

Regarding HTTP specifically: due to its proliferation, I cannot see how 
we can avoid putting emphasis on mapping to it, so I actually think what 
we are doing now is right, i.e. providing a mapping to HTTP as mandatory 
and making mappings to other protocols optional and in separate documents.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>


On 26/03/2010 6:47 AM, Don Sturek wrote:
> If I recall, the CoRE charter removed the mapping devices (CoGII is what I
> think they were back in the original CoAP charter).  I think CoRE only
> focused on development of a RESTful architecture implementation over
> transports that are not constrained to be TCP (ie, UDP is supported).
>
> I think we will make a mistake by having a discussion on mapping to HTTP
> since the discussion below will take place ("what about XMPP mappings",
> "what about SIP mappings", etc.).
>
> If we architect CoRE for mappings to all of these other standards I am
> doubtful it ever achieves it primary goal of a simple RESTful protocol
> implementation for constrained devices.
>
> Don
>
>
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
> Adriano Pezzuto (apezzuto)
> Sent: Friday, March 26, 2010 2:09 AM
> To: core@ietf.org
> Subject: [core] CoAP requirements and HTTP iwf
>
> Hello,
> a great session in Anaheim!
>
> For what concerns CoAP and HTTP mapping (REQ7: of
> draft-shelby-core-coap-req-00), I understood that there is not "the"
> CoAP-HTTP mapping but more possible ways to do the mapping are possible.
> Also, further mappings, e.g.  CoAP-XMPP,   CoAP-SIP, ..  might be
> defined in the future, if required.
>
> What about to split the CoAP specs from the  CoaP-*P mapping specs? I
> mean to have different specs for CoAP core protocol, CoAP-HTTP mapping,
> CoAP-XMPP mapping, CoAP-*P mapping and so on.
>
> Not sure if this make sense ...
>
> regards,
> Adriano
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>