Subject: [core] Fwd: New Version Notification for draft-castellani-core-http-coap-mapping-00

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 25 Jan 2011 22:33:38 +0100

All,
we have submitted a draft discussing the best practices of the
HTTP/CoAP mapping.

Unfortunately this document was based upon CoAP-03; after the release
of CoAP-04, Section 2 (at least) needs a major editing (planned).

Nevertheless we believe that a good part of the concepts present is
the document are still interesting.

We submit it anyway in order to open discussion on the open issues outlined.

We look forward to any feedback from the group.

Angelo & Salvatore

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[email-masked]>
Date: Tue, Jan 25, 2011 at 22:28
Subject: New Version Notification for
draft-castellani-core-http-coap-mapping-00
To: [email-masked]
Cc: [email-masked]

A new version of I-D, draft-castellani-core-http-coap-mapping-00.txt
has been successfully submitted by Angelo P. Castellani and posted to
the IETF repository.

Filename:        draft-castellani-core-http-coap-mapping
Revision:        00
Title:           Best Practice to map HTTP to COAP and viceversa
Creation_date:   2011-01-25
WG ID:           Independent Submission
Number_of_pages: 20

Abstract:
This draft aims at being a simple guide to the use of CoAP REST
interface, to show how it can be mapped to and from HTTP, and at
being a base reference documentation for CoAP/HTTP proxy
implementors.

The IETF Secretariat.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 25 Jan 2011 22:54:28 +0100

The document is available here:
http://www.ietf.org/id/draft-castellani-core-http-coap-mapping-00.txt

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jan 2011 07:55:16 +0100

Angelo,

I think it is a great idea to have such a draft, because much of the information here will be informative, and the protocol definition should only contain those things that are normative (i.e., that we expect from every HTTP/CoAP intermediary).

The most important aspect here is what can such a mapper do independently of knowledge about the application, and where do we need genuine knowledge of that (i.e., the mapper becomes an application gateway).

E.g., it would be nice if we came up with a convention for collecting the resource representations returned to the HTTP world from a CoAP multicast request.  Such as a generic table/hash/dictionary thing (maybe we could use JSON?).  But some mappers will want to use more knowledge about the application to generate a more concise result (e.g., turning multicast into anycast).

Looking forward to a detailed review...

Will you be in today's phone call?

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 26 Jan 2011 11:14:44 +0100

Thanks for the quick feedback.

> I think it is a great idea to have such a draft, because much of the information here will be informative, and the protocol definition should only contain those things that are normative (i.e., tha…

We agree that the draft should be informational, and if a normative
part is required should be kept separate from this document.

> The most important aspect here is what can such a mapper do independently of knowledge about the application, and where do we need genuine knowledge of that (i.e., the mapper becomes an application…

My opinion is that a transparent proxy can be realized, if this
scenario/requirement is considered in the design of CoAP.

Probably right now some issues are present in the current CoAP
release,  we will try to insert a more detailed analysis/discussion on
this in the next planned version.

> E.g., it would be nice if we came up with a convention for collecting the resource representations returned to the HTTP world from a CoAP multicast request.  Such as a generic table/hash/dictionary…

Multicast is a very important feature required for a constrained
crowded environment.

> Looking forward to a detailed review...

We look forward for a review, e.g. about Section 4 on multicast.

> Will you be in today's phone call?

Sure, we will be there.

Best,
Angelo & Salvatore

---

From: tianlinyi 00175029 <[email-masked]>
Date: Wed, 26 Jan 2011 23:01:52 +0800

LOL. I planed to work on this mapping weeks ago. But you are much faster than me. I will definitly interested in reviewing this draft. I will provide comments later:)

Cheers,
Linyi

----- 原邮件 -----
发件人: "Angelo P. Castellani" <[email-masked]>
日期: 星期三, 一月 26日, 2011 下午6:15
主题: Re: [core] New Version Notification for draft-castellani-core-http-coap-mapping-00
收件人: Carsten Bormann <[email-masked]>
抄送: Michele Zorzi <[email-masked]>, Nicola Bui <[email-masked]>, core <[email-masked]>

> > I think it is a great idea to have such a draft, because much of 
> the information here will be informative, and the protocol 
> definition should only contain those things that are normative 
> (i.e., that we expect from every HTTP/CoAP intermediary).
> 
> > The most important aspect here is what can such a mapper do 
> independently of knowledge about the application, and where do we 
> need genuine knowledge of that (i.e., the mapper becomes an 
> application gateway).
> 
> > E.g., it would be nice if we came up with a convention for 
> collecting the resource representations returned to the HTTP world 
> from a CoAP multicast request. ?Such as a generic 
> table/hash/dictionary thing (maybe we could use JSON?). ?But some 
> mappers will want to use more knowledge about the application to 
> generate a more concise result (e.g., turning multicast into anycast).
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>