Re: [core] CoAP requirements and HTTP iwf
"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com> Fri, 26 March 2010 16:13 UTC
Return-Path: <apezzuto@cisco.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 8B2043A6B78 for <core@core3.amsl.com>; Fri, 26 Mar 2010 09:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.169
X-Spam-Level:
X-Spam-Status: No, score=-8.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8]
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 9pYf4LFfKNv0 for <core@core3.amsl.com>; Fri, 26 Mar 2010 09:13:47 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3E08A3A6B9B for <core@ietf.org>; Fri, 26 Mar 2010 09:12:07 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvcAAPB5rEuQ/uCWe2dsb2JhbACbJhUBAQsLJAYcpyyZGIR+BA
X-IronPort-AV: E=Sophos;i="4.51,315,1267401600"; d="scan'208";a="58613149"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2010 16:12:29 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2QGCSZf003392; Fri, 26 Mar 2010 16:12:29 GMT
Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 17:12:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Mar 2010 17:12:26 +0100
Message-ID: <0D212BD466921646B58854FB79092CEC0196C6C9@XMB-AMS-106.cisco.com>
In-Reply-To: <4BACC9FF.1010606@gridmerge.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [core] CoAP requirements and HTTP iwf
Thread-Index: AcrM8+imKFo+hcInTxmJ7MsPLzaxLQAA/4+A
References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net> <4BACC9FF.1010606@gridmerge.com>
From: "Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com>
To: robert.cragie@gridmerge.com, core@ietf.org
X-OriginalArrivalTime: 26 Mar 2010 16:12:27.0986 (UTC) FILETIME=[213D1B20:01CACCFF]
Subject: Re: [core] CoAP requirements and HTTP iwf
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 16:13:53 -0000
> 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. Agree. Due to HTTP ubiquity, a good CoAP-HTTP mapping looks one of the key requirement for CoAP success. Other mappings are optional and not necessarily within this WG. Adriano -----Original Message----- From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: venerdì 26 marzo 2010 15.52 To: d.sturek@att.net Cc: Adriano Pezzuto (apezzuto); core@ietf.org Subject: Re: [core] CoAP requirements and HTTP iwf 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 -----Original Message----- 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
- [core] CoAP requirements and HTTP iwf Adriano Pezzuto (apezzuto)
- Re: [core] CoAP requirements and HTTP iwf Stuber, Michael
- Re: [core] CoAP requirements and HTTP iwf Don Sturek
- Re: [core] CoAP requirements and HTTP iwf Carsten Bormann
- Re: [core] CoAP requirements and HTTP iwf Robert Cragie
- Re: [core] CoAP requirements and HTTP iwf Don Sturek
- Re: [core] CoAP requirements and HTTP iwf Henning Schulzrinne
- Re: [core] CoAP requirements and HTTP iwf Adriano Pezzuto (apezzuto)