Re: [core] CoAP requirements and HTTP iwf

"Don Sturek" <d.sturek@att.net> Fri, 26 March 2010 14:53 UTC

Return-Path: <d.sturek@att.net>
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 CC31E3A6B11 for <core@core3.amsl.com>; Fri, 26 Mar 2010 07:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.869
X-Spam-Level: **
X-Spam-Status: No, score=2.869 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 sFokg90ARiu1 for <core@core3.amsl.com>; Fri, 26 Mar 2010 07:53:44 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3DAFD3A680F for <core@ietf.org>; Fri, 26 Mar 2010 07:53:44 -0700 (PDT)
Received: (qmail 7633 invoked from network); 26 Mar 2010 14:54:05 -0000
Received: from adsl-69-225-120-125.dsl.sndg02.pacbell.net (d.sturek@69.225.120.125 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2010 07:54:04 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: 8iKa1jUVM1kVEMzIDUHU_f8hHOhDiym_ZjpHcN0_0snZXjwguQXxpOtHdyr.SGN83RPOQLYJ8H4ucsKwu9IafSQOak8dCtNNqqA29rh3pF7QKHD76b7CpmvINCnefEoqpBaNinQsSiqPJlWCn3HRHDlTzXGT6K48Bn9CkwRxVOQE_qP8nYGpJCK9NjbNTBtzf2LT5FuMjen6yu_INWEAXe7o34VcXKAdJ3TxACX0ad5C2MyIKIhd3auZB4y74iySvd9jo0UmQsy.0DGFkr7t8mpv4FZSkFLlKc9RvoefR60HjbGB.A--
X-Yahoo-Newman-Property: ymail-3
From: Don Sturek <d.sturek@att.net>
To: robert.cragie@gridmerge.com
References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net> <4BACC9FF.1010606@gridmerge.com>
In-Reply-To: <4BACC9FF.1010606@gridmerge.com>
Date: Fri, 26 Mar 2010 07:54:02 -0700
Message-ID: <00c901caccf4$2d066200$87132600$@sturek>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CACCB9.80A78A00"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrM89/1ytwzZxXzRh+eeuO529OMNgAABOcA
Content-Language: en-us
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: d.sturek@att.net
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:53:50 -0000

Hi Robert,

 

I am fine with having the CoRE mapping to HTTP in the charter.  I forgot it
was still there after CoGII was removed.

 

My point is that I would not want to try to have mappings to HTTP, SIP, XMPP
as I don't think we would actually get anything done.

 

Don

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] 
Sent: Friday, March 26, 2010 7:52 AM
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 <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