Subject: [core] http-coap draft

From: "Stok, Peter van der" <[email-masked]>
Date: Tue, 1 May 2012 07:18:06 +0000

Hi Angelo, Salvatore, Akbar, Thomas, and Esko,

I have read the latest mapping-03 draft with colors because I think the subject is important.
May I suggest a completely different presentation from the one you are doing.
The draft makes a great effort at being comprehensive, my approach would be more use case directed and less complete form a technology possibility point of view.

In a first introduction the draft should outline what it wants to do and what not:

In my opinion the first priority is the access from http in notebooks, telephones to the coap servers in the mesh network via reverse http/coap proxy.
The proxy should try to avoid to maintain complex tables, and automatic translations should be provided from http uri to coap uri.
Consequently, the clients should know the destination addresses of the proxies for given services.
A possible approach for automatic translation is:
DNS (RD) can be filled with the server names and destination addresses. This approach assumes that the proxy has access to DNS or RD.
The proxy decodes the uri, translates it to coap and finds the corresponding entry and IP address. I thought Salvatore had developed a protocol for that.
Block, multicast and observe aspects should be mentioned.

The second priority is access from coap in mesh network to http anywhere. To be filled in......

Lower priority is forward proxies, possibly consider it future work.

This approach is more "simple"  (application) oriented than technology oriented.

Is this reasonable?

Greetings,

peter

Peter van der Stok
Kamperfoelie 8
5708 DM Helmond, The Netherlands
phone +31 492 474673
mailto: [email-masked]

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 2 May 2012 11:47:46 -0400

Hi Peter,

Thank you very much for your detailed comments.  Please see below my
feedback.

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stok, Peter van der
Sent: Tuesday, May 01, 2012 3:18 AM
To: [email-masked]
Subject: [core] http-coap draft

I have read the latest mapping-03 draft with colors because I think the
subject is important.

May I suggest a completely different presentation from the one you are
doing.

The draft makes a great effort at being comprehensive, my approach would
be more use case directed and less complete form a technology
possibility point of view.

** AKBAR - OKAY.  IN GENERAL, THIS IS WHAT WE ALSO UNDERSTOOD TO BE THE
GENERAL DIRECTION FROM THE WG IN THE IETF PARIS MEETING.  FOR EXAMPLE,
WE PROPOSED TO REMOVE A LOT OF THE EXISTING TEXT AND CONCENTRATE
PRIMARILY (BUT NOT EXCLUSIVELY) ON THE REVERSE PROXY CASE (HTTP->COAP).
WE WERE ALSO GOING TO DELETE THE MULTIPLE MESSAGE EXCAHNGE MAPPING FROM
THE REVERSE PROXY CASE.  WE WERE PROPOSING TO LEAVE SOME MINIMAL TEXT
FOR THE FORWARD PROXY CASE (COAP->HTTP) BUT I GUESS FROM YOUR SUGGESTION
WE SHOULD CONSIDER REMOVING THAT AS WELL, AND MAKE THIS DRAFT ONLY
CONCENTRATE ON THE REVERSE PROXY USE CASE. 

In a first introduction the draft should outline what it wants to do and
what not:

** AKBAR - OKAY.

In my opinion the first priority is the access from http in notebooks,
telephones to the coap servers in the mesh network via reverse http/coap
proxy.

** AKBAR - YES (SEE ABOVE DISCUSSION).

The proxy should try to avoid to maintain complex tables, and automatic
translations should be provided from http uri to coap uri.

Consequently, the clients should know the destination addresses of the
proxies for given services.

DNS (RD) can be filled with the server names and destination addresses.
This approach assumes that the proxy has access to DNS or RD.

The proxy decodes the uri, translates it to coap and finds the
corresponding entry and IP address. I thought Salvatore had developed a
protocol for that.

** AKBAR - I HAVE TO THINK ABOUT THIS AND TALK TO THE OTHER CO-AUTHORS.
WE WILL GET BACK TO YOU.

The second priority is access from coap in mesh network to http
anywhere. To be filled in......

** AKBAR - WHAT IS THE DIFFERENCE BETWEEN THIS AND FORWARD PROXIES?
MAYBE I AM NOT UNDERSTANDING WHAT YOU MEAN BY "COAP IN MESH NETWORKS"? 

** AKBAR - YES.

This approach is more "simple"  (application) oriented than technology
oriented.

Is this reasonable?

** AKBAR - YES, THIS IS VERY USEFUL FEEDBACK.  THANK YOU.  IF YOU COULD
JUST ANSWER MY REMAINING OPEN QUESTIONS ABOVE IT WOULD BE VERY USEFUL.

Greetings,

peter

Peter van der Stok

Kamperfoelie 8

phone +31 492 474673            

 

The information contained in this message may be confidential and
legally protected under applicable law. The message is intended solely
for the addressee(s). If you are not the intended recipient, you are
hereby notified that any use, forwarding, dissemination, or reproduction
of this message is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender by return e-mail
and destroy all copies of the original message.

---

From: "Stok, Peter van der" <[email-masked]>
Date: Thu, 3 May 2012 06:47:47 +0000

Hi Akbar,

A clarification to your question.
------------------------------------------------------------------------------------------------

** AKBAR - WHAT IS THE DIFFERENCE BETWEEN THIS AND FORWARD PROXIES?  MAYBE I AM NOT UNDERSTANDING WHAT YOU MEAN BY "COAP IN MESH NETWORKS"

I saw two cases:

1)      Access mostly from outside the lowpan by PC and human oriented devices using http passing through http/coap proxy to coap devices.

2)      Access from coap devices in lowpan via coap/http proxy to http device also mostly outside the lowpan. Actually, this latter may be more important given all the legacy http web services and back hand services.

Greetings,

peter

From: Rahman, Akbar [mailto:[email-masked]]
Sent: Wednesday 2 May 2012 17:48
To: Stok, Peter van der
Cc: [email-masked]
Subject: RE: [core] http-coap draft

Hi Peter,

Thank you very much for your detailed comments.  Please see below my feedback.

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stok, Peter van der
Sent: Tuesday, May 01, 2012 3:18 AM
To: [email-masked]
Subject: [core] http-coap draft

** AKBAR - OKAY.  IN GENERAL, THIS IS WHAT WE ALSO UNDERSTOOD TO BE THE GENERAL DIRECTION FROM THE WG IN THE IETF PARIS MEETING.  FOR EXAMPLE, WE PROPOSED TO REMOVE A LOT OF THE EXISTING TEXT AND CONCENTRATE PRIMARILY (BUT NOT EXCLUSIVELY) ON THE REVERSE PROXY CASE (HTTP->COAP).  WE WERE ALSO GOING TO DELETE THE MULTIPLE MESSAGE EXCAHNGE MAPPING FROM THE REVERSE PROXY CASE.  WE WERE PROPOSING TO LEAVE SOME MINIMAL TEXT FOR THE FORWARD PROXY CASE (COAP->HTTP) BUT I GUESS FROM YOUR SUGGESTION WE SHOULD CONSIDER REMOVING THAT AS WELL, AND MAKE THIS DRAFT ONLY CONCENTRATE ON THE REVERSE PROXY USE CASE.

** AKBAR - OKAY.

** AKBAR - I HAVE TO THINK ABOUT THIS AND TALK TO THE OTHER CO-AUTHORS.  WE WILL GET BACK TO YOU.

** AKBAR - WHAT IS THE DIFFERENCE BETWEEN THIS AND FORWARD PROXIES?  MAYBE I AM NOT UNDERSTANDING WHAT YOU MEAN BY "COAP IN MESH NETWORKS"?

** AKBAR - YES.

Is this reasonable?

** AKBAR - YES, THIS IS VERY USEFUL FEEDBACK.  THANK YOU.  IF YOU COULD JUST ANSWER MY REMAINING OPEN QUESTIONS ABOVE IT WOULD BE VERY USEFUL.

Greetings,

peter

Peter van der Stok
Kamperfoelie 8

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 May 2012 04:53:02 -0600

I'm not necessarily suggesting this but just as a random option to keep in mind ... if people felt that this draft was better split into two drafts, one for the when the server was HTTP and the client was COAP, and another draft for the opposite direction, we could split the draft into two drafts. Thoughts on if this would help or just make things more confusing ? 

On May 3, 2012, at 12:47 AM, Stok, Peter van der wrote:

> The second priority is access from coap in mesh network to http anywhere. To be filled in……
>  
> ** AKBAR – WHAT IS THE DIFFERENCE BETWEEN THIS AND FORWARD PROXIES?  MAYBE I AM NOT UNDERSTANDING WHAT YOU MEAN BY “COAP IN MESH NETWORKS”
>  
>  
>  
> I saw two cases:
>  
> ** AKBAR – OKAY.  IN GENERAL, THIS IS WHAT WE ALSO UNDERSTOOD TO BE THE GENERAL DIRECTION FROM THE WG IN THE IETF PARIS MEETING.  FOR EXAMPLE, WE PROPOSED TO REMOVE A LOT OF THE EXISTING TEXT AND CONCENTRATE PRIMARILY (BUT NOT EXCLUSIVELY) ON THE REVERSE PROXY CASE (HTTP->COAP).  WE WERE ALSO GOING TO DELETE THE MULTIPLE MESSAGE EXCAHNGE MAPPING FROM THE REVERSE PROXY CASE.  WE WERE PROPOSING TO LEAVE SOME MINIMAL TEXT FOR THE FORWARD PROXY CASE (COAP->HTTP) BUT I GUESS FROM YOUR SUGGESTION WE SHOULD CONSIDER REMOVING THAT AS WELL, AND MAKE THIS DRAFT ONLY CONCENTRATE ON THE REVERSE PROXY USE CASE.
>  
>  
> ** AKBAR – OKAY.
> ** AKBAR – YES (SEE ABOVE DISCUSSION).
>  
> ** AKBAR – I HAVE TO THINK ABOUT THIS AND TALK TO THE OTHER CO-AUTHORS.  WE WILL GET BACK TO YOU.
>  
> The second priority is access from coap in mesh network to http anywhere. To be filled in……
>  
> ** AKBAR – WHAT IS THE DIFFERENCE BETWEEN THIS AND FORWARD PROXIES?  MAYBE I AM NOT UNDERSTANDING WHAT YOU MEAN BY “COAP IN MESH NETWORKS”?
>  
> ** AKBAR – YES.
> This approach is more “simple”  (application) oriented than technology oriented.
>  
> Is this reasonable?
>  
> ** AKBAR – YES, THIS IS VERY USEFUL FEEDBACK.  THANK YOU.  IF YOU COULD JUST ANSWER MY REMAINING OPEN QUESTIONS ABOVE IT WOULD BE VERY USEFUL.
>  
> Greetings,
>  
> peter
>  
>  
>  
> Peter van der Stok
> Kamperfoelie 8
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 11 May 2012 10:05:28 -0400

> translations should be provided from http uri to coap uri.****
>
> proxies for given services.****
>
> A possible approach for automatic translation is:****
>
> This approach assumes that the proxy has access to DNS or RD.****
>
> protocol for that.****
> Block, multicast and observe aspects should be mentioned.****
>
>  ****
>
> ** AKBAR – I HAVE TO THINK ABOUT THIS AND TALK TO THE OTHER CO-AUTHORS.
> WE WILL GET BACK TO YOU.****
>
> **
>
One possibly translation mechanism, which I believe we discussed in the -dna
draft, is to go from http: to coap+srv: schemes.  This is based on an
expired
draft of Cullen's.  The way it would work is that the http client would
access the
proxy just like it's a web server (DNS name resolution of the host A or AAAA
record into an IP address; the port, if not 80, is given in the URI).  The
proxy
then replaces http: with coap_srv: and instead of resolving the AAAA record
of the origin server, it resolves an SRV record which gives the hostname and
port of the origin server.  This could be done with RD by taking the host
name
of the proxy to be the endpoint name of the origin server and resolving that
into {IP, port}.

This approach has some challenges.  For one, it depends on a proxy that
provides name-based virtual hosting (a different name for each origin
server).
This has knock-on effects for security, like needing the Server Name
Indication
of TLS1.2:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Support_for_name-based_virtual_servers
It would reduce the mapping burden at the proxy and move it to DNS or RD.

Thoughts?  -K-

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 18 May 2012 10:54:32 +0200

Hi Kerry, thank you very much for this and sorry for the ultra late response.

Let me check if I've understood your proposal correctly.

On May 11, 2012, at 4:05 PM, Kerry Lynn wrote:
> draft, is to go from http: to coap+srv: schemes.  This is based on an expired
> draft of Cullen's.  The way it would work is that the http client would access the
> record into an IP address; the port, if not 80, is given in the URI).  The proxy
> port of the origin server.  This could be done with RD by taking the host name

It seems that the coap+srv scheme is completely implicit, in that the proxy arbitrarily decides to interpret the virtual host name as an http alias of the real coap origin, is it right ?

The DNS would be used to lookup the origin that owns the resource in the coap namespace, allowing us to go from http://v1.example.com/path/to/resource to coap://[2001:db8::1]:1234/path/to/resource through the chain:
  v1.example.com =>
    _coap._udp.v1.example.com =>
      a-coap-origin.example.com 1234 =>
        2001:db8::1 1234
correct ?

> provides name-based virtual hosting (a different name for each origin server).
> This has knock-on effects for security, like needing the Server Name Indication
> of TLS1.2:

I have a couple of questions:
What happens if the virtual host name has a port in it ?
What if we need to map the resource path (and not just the URI authority) ?

Thanks, Thomas.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sat, 19 May 2012 00:02:46 -0400

Hi Cullen,

Yes.  In general, the direction we got from the Paris IETF (and the
subsequent emails from Peter, Kerry and others) is similar to your
proposal.  Specifically:

- Focus on the "reverse proxy case" (HTTP client -> CoAP server)

- Split out the "forward proxy case" (CoAP client -> HTTP server) and
some other information from the I-D, but we could definitely put it in a
second draft if the WG thought it worthwhile.

- Angelo had made the detailed proposal for the draft restructuring
(reflecting the above points) in the original email that trigger this
chain http://www.ietf.org/mail-archive/web/core/current/msg02940.html

We plan starting to implement the comments and the feedback received
from the WG in a 2 weeks time. If you and/or the WG have any further
comment, can you please provide it before that time?

Thanks,

Akbar

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Friday, May 11, 2012 6:53 AM
To: Stok, Peter van der
Cc: Rahman, Akbar; [email-masked]
Subject: Re: [core] http-coap draft

I'm not necessarily suggesting this but just as a random option to keep
in mind ... if people felt that this draft was better split into two
drafts, one for the when the server was HTTP and the client was COAP,
and another draft for the opposite direction, we could split the draft
into two drafts. Thoughts on if this would help or just make things more
confusing ? 

> A clarification to your question.
------------------------------------------------------------------------
------------------------
> ** AKBAR - WHAT IS THE DIFFERENCE BETWEEN THIS AND FORWARD PROXIES?
MAYBE I AM NOT UNDERSTANDING WHAT YOU MEAN BY "COAP IN MESH NETWORKS"
>  
>  
>  
> I saw two cases:
>  
> 1)      Access mostly from outside the lowpan by PC and human oriented
devices using http passing through http/coap proxy to coap devices.
> 2)      Access from coap devices in lowpan via coap/http proxy to http
device also mostly outside the lowpan. Actually, this latter may be more
important given all the legacy http web services and back hand services.
feedback.
doing.
> The draft makes a great effort at being comprehensive, my approach
would be more use case directed and less complete form a technology
possibility point of view.
>  
> ** AKBAR - OKAY.  IN GENERAL, THIS IS WHAT WE ALSO UNDERSTOOD TO BE
THE GENERAL DIRECTION FROM THE WG IN THE IETF PARIS MEETING.  FOR
EXAMPLE, WE PROPOSED TO REMOVE A LOT OF THE EXISTING TEXT AND
CONCENTRATE PRIMARILY (BUT NOT EXCLUSIVELY) ON THE REVERSE PROXY CASE
(HTTP->COAP).  WE WERE ALSO GOING TO DELETE THE MULTIPLE MESSAGE
EXCAHNGE MAPPING FROM THE REVERSE PROXY CASE.  WE WERE PROPOSING TO
LEAVE SOME MINIMAL TEXT FOR THE FORWARD PROXY CASE (COAP->HTTP) BUT I
GUESS FROM YOUR SUGGESTION WE SHOULD CONSIDER REMOVING THAT AS WELL, AND
MAKE THIS DRAFT ONLY CONCENTRATE ON THE REVERSE PROXY USE CASE.
> The proxy should try to avoid to maintain complex tables, and
automatic translations should be provided from http uri to coap uri.
> DNS (RD) can be filled with the server names and destination
addresses. This approach assumes that the proxy has access to DNS or RD.
oriented.
>  
> Is this reasonable?
>  
> ** AKBAR - YES, THIS IS VERY USEFUL FEEDBACK.  THANK YOU.  IF YOU
COULD JUST ANSWER MY REMAINING OPEN QUESTIONS ABOVE IT WOULD BE VERY
USEFUL.

---

From: Kerry Lynn <[email-masked]>
Date: Sun, 20 May 2012 21:44:31 -0400

Hi Thomas,

Responses inline...

On Fri, May 18, 2012 at 1:54 AM, Thomas Fossati <[email-masked]> wrote:

> It seems that the coap+srv scheme is completely implicit, in that the
> proxy arbitrarily decides to interpret the virtual host name as an http
> alias of the real coap origin, is it right ?
>
> I'd say the answer to this question is "yes" insofar as a second URI of the
form "coap+srv://<host>:<port>/<path>" never actually appears on the wire.
However, it would be good to document this scheme in a normative document
such that it could be used, e.g. to persist URIs that use dynamic ports (as
a coap server may if it decides to use the compressible IPHC port range).

The essential idea is that the http: URI explicitly identifies the http
proxy, and
that the <host> field is also used to name a *reference* to the origin
server.
In this case, the proxy would re-resolve <host> to an {IP, port} using
either
DNS-SD (in which case <host> is interpreted to mean the name of an SRV
record in the specified DNS zone) or RD (in which case <host> is interpreted
as an endpoint name)..  A precedence order should be defined in order to
break ties when both resolutions are possible, and to this extent the
behavior
of the proxy is not "arbitrary".  I would rank DNS resolution ahead of RD as
the former is already defined by standards track RFCs.

My position in keeping DNS in front of the CoRE WG is not to mandate its
use for name resolution and discovery, but rather to keep viable the option
of
using DNS for these operations at least to the function set (REST interface)
level of granularity.

The DNS would be used to lookup the origin that owns the resource in the
> coap namespace, allowing us to go from
> http://v1.example.com/path/to/resource to
> coap://[2001:db8::1]:1234/path/to/resource through the chain:
>  v1.example.com =>
> I would state this differently:

http: (or https:) v1.example.com => DNS lookup for A/AAAA record named "v1"
in
DNS zone "example.com" => IPv4/IPv6 address of proxy.  If the port of the
proxy
is not 80 (or 443) then it is explicitly stated in the URI of the proxy.

The proxy may then (according to the defined precedence) do:

a) DNS lookup for SRV record named "v1" in "example.com".  The result of
this
lookup is a <host> and port; <host> names an A/AAAA RR in example.com.
Lookup A/AAAA record named <host> in example.com => {IP, port}

or b) treat "v1" as an end-point identifier and resolve this to an {IP,
port}.

The latest
http://tools.ietf.org/pdf/draft-shelby-core-resource-directory-03.pdf
states:  An end-point is a web server associated with a port,
thus a physical node may host one or more end-points.

This implies to me that port is used to demux different coap servers hosted
on the same device.   The most recent
http://tools.ietf.org/pdf/draft-shelby-core-resource-directory
doesn't have a specific endpoint lookup example (?ep=node5) but the example
below seems to return {IP, port} for a given endpoint name:

Client                                                  RD

  |                                                     |

  | ----- GET /rd-lookup/ep?rt=PowerNode -------------> |

  |                                                     |

  |                                                     |

  | <-- 2.05 Content "<coap://{ip:port}>;ep="node5" --- |

  |                                                     |

> What happens if the virtual host name has a port in it ?

Port in the http: URI refers to the proxy.  Port for the origin server
comes from
DNS or RD.

> This point of this approach is to reduce mapping requirements on the proxy,
and it assumes /<path> in the original URI does not require mapping (i.e. it
identifies the proxied resource as well as the resource on the origin
server.

One could consider proxies where the far side is some legacy protocol that
does
not support URI semantics, e.g. BACnet.  In this case, it would be required
to
define a deterministic URI-to-legacy mapping, e.g. /<objectId>/<propertyId>/
in the case of BACnet.

Let me know if this all makes sense (or not).

-K-

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 21 May 2012 12:42:50 +0200

Hi Kerry,

> Responses inline...

a very clear and sound explication, thanks.

> identifies the proxied resource as well as the resource on the origin server.

I agree with you that offloading the URI mapping to a different functional entity than the proxy is a good thing; I'm a little bit disappointed that such a clean solution (i.e. use of the SRV RR) leaves an open end to the URI mapping machinery -- namely the path mapping -- which could be of practical interest for deployments that need to completely separate the public (http) from the private (coap) name-spaces.

Bye, Thomas.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 21 May 2012 07:33:32 -0400

On Mon, May 21, 2012 at 6:42 AM, Thomas Fossati <[email-masked]> wrote:

> I agree with you that offloading the URI mapping to a different functional
> entity than the proxy is a good thing; I'm a little bit disappointed that
> such a clean solution (i.e. use of the SRV RR) leaves an open end to the
> URI mapping machinery -- namely the path mapping -- which could be of
> practical interest for deployments that need to completely separate the
> public (http) from the private (coap) name-spaces.
>
> Every SRV RR has an identically named TXT RR that can contain
<key>=<value> pairs.  The practical size limit of this record is a few
hundred octets.  It could be used to hold, say, a substitution string
but in general DNS is not well suited to perform 1:1 re-mapping of
arbitrary strings.

DNS-based Service Discovery can be pressed into service to answer
?rt=<function set> style queries with a path to a corresponding REST
interface returned in a TXT record, but this is a different problem (with
different semantics) from the one you describe.

-K-

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 21 May 2012 14:42:37 +0200

Hi Kerry,

> hundred octets.  It could be used to hold, say, a substitution string

Documenting the use of TXT records for path remapping could be really useful and would definitely close the circle.

> but in general DNS is not well suited to perform 1:1 re-mapping of

Provided that I'm not a DNS hacker -- and therefore the following may sound completely silly: have you already explored the usage of NAPTR RRs in the HTTP/CoAP context ?

---

From: Antonio Jara <[email-masked]>
Date: Mon, 21 May 2012 15:16:57 +0200

The main problem for this purpose is that although the TXT record allows to
store a full URI or path for the remapping, face to carry out the discovery
in a local level via mDNS or similar, this TXT record will mean a lot of
overload inside of the 6LoWPAN network.

So, my question is, who will use those TXT entries, e,g, clients out of the
6LoWPAN network?

How are you going to filter the type of TXT entry?, for example, we are
defining some design issues and an implementation focused on be able in the
query to specify the kind of tuple from the TXT record which are you
interested, since the original DNS protocol is limited to ask for AAAA,
SRV, TXT, but you are not able to indicate inside the TXT records from all
the available if your are interested in the rt=, if=, mapping=, or whatever
tuple.

Therefore, if we are able to specify the kind of entry that we are
interested in a detailed level, i.e. not only TXT, else also TXT and the
type of value, then we can apply these solutions, since we will not receive
all the TXT records with the different entries or a very long TXT in link
format, else only the specific TXTs records with the values that really we
are interested.

Find enclosed a work from side with some initial conclusions and design
issues about how to extend DNS in order to make feasible its introduction
into the 6LoWPAN side of the network.

Best regards,
Antonio J. Jara

On Mon, May 21, 2012 at 2:42 PM, Thomas Fossati <[email-masked]> wrote:

> Documenting the use of TXT records for path remapping could be really
> useful and would definitely close the circle.
>
> Provided that I'm not a DNS hacker -- and therefore the following may
> sound completely silly: have you already explored the usage of NAPTR RRs in
> the HTTP/CoAP context ?

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 21 May 2012 15:55:36 +0200

Hi Antonio,

On May 21, 2012, at 3:16 PM, Antonio Jara wrote:
> The main problem for this purpose is that although the TXT record allows to store a full URI or path for the remapping, face to carry out the discovery in a local level via mDNS or similar, this TXT record will mean a lot of overload inside of the 6LoWPAN network.
> 
> So, my question is, who will use those TXT entries, e,g, clients out of the 6LoWPAN network?
> How are you going to filter the type of TXT entry?,
> for example, we are defining some design issues and an implementation focused on be able in the query to specify the kind of tuple from the TXT record which are you interested, since the original DNS protocol is limited to ask for AAAA, SRV, TXT, but you are not able to indicate inside the TXT records from all the available if your are interested in the rt=, if=, mapping=, or whatever tuple. 
> 
> Therefore, if we are able to specify the kind of entry that we are interested in a detailed level, i.e. not only TXT, else also TXT and the type of value, then we can apply these solutions, since we will not receive all the TXT records with the different entries or a very long TXT in link format, else only the specific TXTs records with the values that really we are interested.

Kerry has for sure a better insight than me about the whole mechanism, but at a first glance it seems to me that the SRV and TXT records that are manipulated by the proxy for handling URI mapping are related to domain names that will not be queried by other entities in the constrained network.  So the TXT filtering problem (an interesting topic in itself though) doesn't seem to apply here.

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 23 May 2012 15:41:04 +0000

Hello Peter,

thanks again for your input! There were still some topics unanswered from your previous email; see below.

> Block, multicast and observe aspects should be mentioned.

We (authors) agree on specifying default / preferable ways of translation. Also the use of DNS, DNS-SD and RD for URI translation can be added, if this supports our specific use cases. (These use cases will be included in the next update of the draft as confirmed by Akbar earlier.)  The next version will probably not have all the details related to DNS-SD and RD yet so we aim to add that later.
Note - HTTP-to-CoAP multicast will not be addressed anymore; as part of the simplification of the draft.

> The second priority is access from coap in mesh network to http anywhere. To be filled in......

That is now to be addressed in a separate draft (see email by Akbar http://www.ietf.org/mail-archive/web/core/current/msg03352.html ), also based on use cases. Currently we assume that for typical use cases the proxy is a forward proxy - i.e. CoAP clients use the Proxy-URI field to request to an HTTP server. This still allows going from CoAP in mesh networks to HTTP legacy services anywhere. Is there any reason here why you ask for a reverse proxy (CoAP-to-HTTP) for this case?
In other words, if there's a reason or use case to not want a forward C2H proxy, but, instead, want a reverse C2H proxy. In that case a CoAP client can just request to coap://httpserver.example.com, not using any Proxy-URI field in the request. Then, through some (DNS and/or DNS-SD) configuration this request ends up with the C2H proxy, which performs the actual http://httpserver.example.com connecting to httpserver.
Our splitting proposal so far considered only the C2H forward-proxy case.

regards, (on behalf of all authors)
Esko

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stok, Peter van der
Sent: Tuesday 1 May 2012 9:18
To: [email-masked]
Subject: [core] http-coap draft

Is this reasonable?

Greetings,

peter

Peter van der Stok
Kamperfoelie 8