On 12 Apr 2017, at 12:38 pm, weigengyu
<weigengyu(_at_)bupt(_dot_)edu(_dot_)cn> wrote:
Hi Mark,
OK. Just curious -- is there a strong motivation here?
It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol
(COAP) over WebSockets over HTTP again,
rather than just using HTTP (which AIUI you already have a mapping to).
It is meaningful and interesting.
CoAP/UDP/IPv6 protocl stack can run well within CoRE environments.
But if CoAP/UDP is tried in the Internet, it will be blocked due to
NAT/firewall etcs based on tests done here a few years ago.
CoAP/TCP or CoAP/WSS could help CoAP messages and applications available
around Internet.
We have done some works about this topics.
The following are two abstracts of my master course students' theses, in
which may be interested.
THE RESEARCH AND DEVELOPMENT OF CoAP over TCP
ABSTRACT
The CoAP protocol is a restricted resource application protocol. In the CoAP
protocol research and application, the default CoAP protocol
stack use UDP as the transport layer。In the Ethernet environment, data
transmission will be affected because of the existence of the firewall .
For the reason that CoAP can be better applied to the current Internet
environment and cloud environment, IETF working group proposed CoAP over TCP,
CoAP protocol stack use TCP as the transport layer .In this context, CoAP
over TCP is studied and CoAP over TCP is implemented based on the
open source framework Californium. The CoAP over TCP is implemented as a
client in the real Internet environment and the function of the
implementation is evaluated. CoAP over TCP is the Internet of Things cloud
platform services, so AWS environment is used to achieve CoAP over TLS/TCP
and the default protocol stack performance comparison.
In this paper, the significance of CoAP over TCP is expatiated, and CoAP over
TCP is studied. After that, the overall architecture of Californium framework
is deeply analyzed, and the design scheme of CoAP over TCP is proposed. The
transport layer is extended on the basis of the original frame structure.
Based on the design scheme, the modules are designed and designed in detail.
On the core of the class through the class diagram describes the expansion
of the relationship between the various modules. The network layer, protocol
layer and application layer implementation process are analyzed in detail.
Afterwards, we study the proxy between CoAP over TCP and default protocol
stack, and propose the message type conversion problem and solution of
CoAPToCoAP proxy.
The paper concludes the relevant work, and puts forward the research
direction of the next step.
KEY WORDS: CoAP over TCP Proxy Californium Frame
THE DESIGN AND IMPLEMENTATION OF COAP OVER WEBSOCKET
ABSTRACT
The concept of Internet of Things (IoT) was originally proposed almost twenty
years ago. Over the past many years, IoT has gone through huge and rapid
development,
and the field of Wireless Sensor Network (WSN) has witnessed remarkable
advancement in particular. Compared to the progress of WSN, the practical
service
and application of IoT still has a very long way to go. Although current
industry standards can meet those equipments like smart phones, they are not
quite suitable
for constrained nodes which are often battery supported and has relatively
lower processing ability. Driven by such demands, the IETF set up CoRE
working group
to design a RESTful application protocol which can perform better among
constrained nodes in constrained environments.
The protocol was named Constrained Application Protocol (CoAP) and it was
later standardized as RFC 7252.
This paper analizes the features and defect of the HTTP/CoAP proxy proposed
in RFC 7252, and explains the CoAP over WebSocket proxy as well as its
advantages over
the HTTP/CoAP proxy. Then a design and implementation of CoAP over WebSocket
based on Californium open-source framework is given. Performance tests and
experiments have shown that the CoAP over WebSocket approach has some
significant advantages over HTTP/CoAP proxy in term of response time and high
concurrency
requests processing ability.
KEY WORDS: computer network, iot, coap, network proxy, websocket
Regards,
Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- From: Mark Nottingham
Sent: Tuesday, April 11, 2017 8:39 AM
To: Carsten Bormann
Cc: art(_at_)ietf(_dot_)org ;
draft-ietf-core-coap-tcp-tls(_dot_)all(_at_)ietf(_dot_)org ;
ietf(_at_)ietf(_dot_)org ; core(_at_)ietf(_dot_)org
Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
Hi Carsten,
Couple of quic responses below.
On 10 Apr 2017, at 7:46 pm, Carsten Bormann <cabo(_at_)tzi(_dot_)org> wrote:
I agree that the introduction should focus on the Browser use case and keep
out of the firewall traversal jungle.
OK. Just curious -- is there a strong motivation here? It seems very odd to
tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets
over HTTP again, rather than just using HTTP (which AIUI you already have a
mapping to).
Section 7 defines a number of new URI schemes for COAP protocols.
Syntactically, they use "+" to separate "coap" from the underlying
transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This
syntax is allowed by RFC3986, but is unprecedented, and implies a
sub-syntax convention similar to those used in media types, etc. Is
there an expectation that other URI schemes starting with "coap+" are
reserved?
There is no such expectation.
We did have the discussion about reserved URI scheme prefixes in the IETF,
and as I recall, the result was that there are none. While it would be a
bit weird to register a URI scheme starting with coap+ or coaps+ that is
unrelated to CoAP, only the slightly boggled response from an expert review
is in the way of that happening.
Would the scheme names be more palatable with a dash instead of a plus?
Careful choice of the scheme name mostly benefits the implementer, so it can
be changed in the spec (at the cost of changing existing implementations).
OK. I'm mostly noting this in case other folks feel that this is a bad
precedent for URI schemes; I think the bigger concern is the one below.
Defining URI schemes that switch transport protocol based upon their
name deserves wider review as well; this has been a contentious topic
in the past, and it would be good to understand what tradeoffs are
being made by doing so. Locking identifiers into a specific transport
protocol sacrifices much of the power of URLs.
The “siloing” of URIs along schemes is indeed a problem, which started for
CoAP with the separation of the coap:/coaps: name spaces. The CoRE WG did
not see it as its task to address this shortcoming. So, for now, we’ll have
to live with it; approaches such as
draft-silverajan-core-coap-protocol-negotiation are trying to address its
practicalities.
By defining multiple URI schemes for different transports of the same
protocol, the WG has taken a position as to what the solution is. I'm finding
it difficult to square this with the continuing characterisation of CORE as
"RESTful".
Furthermore, creating
"coap+ws" to denote a specific protocol over WebSockets (which has its
own URI scheme) is questionable; taken to its natural conclusion,
we'll have a proliferation of URI schemes for things over WebSockets.
I’m not sure that a proliferation will happen — WebSockets is mostly used
for tightly bound proprietary protocols between a JavaScript mobile code
client and a server that provides this mobile code client. On the other
hand, deciding to never use URIs to refer to resources available over a
WebSockets protocol strikes me as an unnecessary restriction.
Will COAP take the same approach for HTTP?
Not sure what this question is leading into.
(We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075.
But maybe this is about something different.)
I mean to ask whether there will be a need for a "coap+http" URI scheme; it
seems like a logical conclusion of the approach taken here.
I would suggest a wider discussion of these issues on art@ / uri@.
Indeed, a wider discussion of these longstanding issues would be useful.
I’m not sure that waiting for their resolution is blocking this spec.
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use.
This incorrect use of RFC 5785 is indeed embarrassing. More about that
later.
OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, but I
think that would take a separate RFC that updates their scheme registrations.
Not sure whether there would be any pushback in that community (but I can't
see any immediate reason why there would be).
Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.
Since it is the implementers who will decide whether they implement this,
this co-author could live with making implementing NoSec completely
optional. (It will be anyway, in practice, at the level of what is actually
configured.) The important point(*) from the WG perspective here is that
TLS is mandatory to implement, with the specifics depending on the security
mode needed (cf. RFC 7925). (Note also that there are other ways to provide
security with CoAP.)
Ack. Again, this was mostly a note to bring it to others' attention; the use
of the phrase "Mandatory to Implement" when applied to "no security" just
seems odd.
Cheers,
Grüße, Carsten
(*)
https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60
--
Mark Nottingham https://www.mnot.net/
_______________________________________________
core mailing list
core(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/core