Subject: [core] CoAP requirements and HTTP iwf

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 26 Mar 2010 10:09:25 +0100

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

---

From: "Stuber, Michael" <[email-masked]>
Date: Fri, 26 Mar 2010 06:37:33 -0700

A well defined mapping between CoAP and HTTP is a core requirement.
>From a document structure standpoint, either way is fine, but I wouldn't
want to split it out only to have it languish.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adriano Pezzuto (apezzuto)
Sent: Friday, March 26, 2010 2:09 AM
To: [email-masked]
Subject: [core] CoAP requirements and HTTP iwf

Hello,

regards,
Adriano
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 26 Mar 2010 06:47:27 -0700

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

Hello,

regards,
Adriano

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Mar 2010 07:19:40 -0700

On Mar 26, 2010, at 06:47, Don Sturek wrote:

> think they were back in the original CoAP charter).  

Indeed, we got rid of the "CoGII" term, because we don't need to name the devices that perform this function.  However,
http://datatracker.ietf.org/wg/core/charter/
says:

> The WG will define a
> mapping from CoAP to an HTTP REST API; this mapping will not depend on a
> specific application.

In other words:
-- HTTP mapping in scope
-- XMPP etc. mapping out of scope

With a view to achieving good protocol quality for CoAP itself, I would not mind if an individual or group contributed, say, an XMPP mapping document, and we can spend working group time to discuss how this informs the development of CoAP.  The mapping itself is just not a deliverable of the WG.  Note that the charter also says we can look for additional items to work on once the current deliverables are done (Jan 2011), and if we already have such a document and like it, completing it would be a natural additional work item.

Gruesse, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Fri, 26 Mar 2010 07:51:43 -0700

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

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 26 Mar 2010 07:54:02 -0700

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:[email-masked]] 
Sent: Friday, March 26, 2010 7:52 AM
To: [email-masked]
Cc: 'Adriano Pezzuto (apezzuto)'; [email-masked]
Subject: Re: [core] CoAP requirements and HTTP iwf

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

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

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

 

Don

-----Original Message-----
 
Hello,

 
 
regards,
Adriano

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Mar 2010 12:08:27 -0400

Given the rather awkward ways that HTTP provides event notification, I think the technically sensible notion is to have a combination of an event-based mechanism (SIP, XMPP) with a get/set protocol (HTTP).

Henning

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 26 Mar 2010 17:12:26 +0100

> 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:[email-masked]] 
Sent: venerdì 26 marzo 2010 15.52
To: [email-masked]
Cc: Adriano Pezzuto (apezzuto); [email-masked]
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
http://www.gridmerge.com

-----Original Message-----

Don

-----Original Message-----

Hello,

regards,
Adriano