Subject: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07

From: Mark Nottingham <[email-masked]>
Date: Sun, 09 Apr 2017 21:07:04 -0700

Reviewer: Mark Nottingham
Review result: Not Ready

First, a general comment. I have been concerned about the duplication
of effort that COAP represents for some time, and that concern grows
significantly upon reading this draft. COAP is now specifying multiple
"bindings" to underlying application and transport protocols,
re-inventing message framing,  congestion control in UDP, etc. The
introduction justifies this development over the reuse of HTTP/2 (and
presumably QUIC, once available) based upon the relative availability
of implementations for constrained devices. Whether that remains true
will only be judged by the market -- unfortunately after all of the
cost of development and standardisation is sunk.

The introduction motivates the layering of COAP over WebSockets to
allow it to be used in a network that only allows external access
through a HTTP proxy. In fact, it is not necessary to use WebSockets
to do so; HTTP CONNECT provides a tunnel in this scenario. WebSockets
is a specialised protocol that allows bidirectional, stream-based
transport from a Web browser -- it is effectively TCP wrapped into the
Web browser's security model, to make doing so safe. Using it for
other purposes (i.e., non-browser use cases) isn't really appropriate.
I'd suggest either removing the WebSockets binding, or changing its
motivation in the Introduction.

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? 

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. 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.
Will COAP take the same approach for HTTP?

I would suggest a wider discussion of these issues on art@ / uri@.

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. I'm not
sure how to address this, other than removing the WebSockets binding.

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.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Apr 2017 11:46:40 +0200

Hi Mark,

thank you for this thoughtful review.

This message will focus on a few technical points; I’ll leave aside the philosophical issues about whether the IETF should have a constrained node stack.

> WebSockets
> Web browser's security model, to make doing so safe.

Indeed, that is the use case that was motivating this part.

> Using it for

I agree that the introduction should focus on the Browser use case and keep out of the firewall traversal jungle.

> there an expectation that other URI schemes starting with "coap+" are

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

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

> Furthermore, creating

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

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

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

Grüße, Carsten

(*) https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Apr 2017 10:39:18 +1000

Hi Carsten,

Couple of quic responses below.

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

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

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

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

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

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

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

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,

--
Mark Nottingham   https://www.mnot.net/

---

From: "weigengyu" <[email-masked]>
Date: Wed, 12 Apr 2017 10:38:12 +0800

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: [email-masked] ; [email-masked] ; [email-masked] 
; [email-masked]
Subject: Re: [core] Artart last call review of 
draft-ietf-core-coap-tcp-tls-07

Hi Carsten,

On 10 Apr 2017, at 7:46 pm, Carsten Bormann <[email-masked]> 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).

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

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

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

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.

> This incorrect use of RFC 5785 is indeed embarrassing.  More about that 

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

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Apr 2017 12:42:16 +1000

So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.

Also, the assertions about firewalls are interesting; we're hearing very different assertions in the discussions of QUIC (e.g,. 90%+ success rates for UDP protocols).

Cheers,

> On 12 Apr 2017, at 12:38 pm, weigengyu <[email-masked]> wrote:
> 
> Hi Mark,
> 
>> It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over HTTP again,
> 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.
> 
> The following are two abstracts of my master course students' theses, in which may be interested.
> 
> 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
> 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.
> 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
> -----原始邮件----- From: Mark Nottingham
> Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked]
> Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
> 
> Hi Carsten,
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Apr 2017 06:04:33 +0200

> So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.

Can’t answer that for Gengyu, but the term “firewall” occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one.

I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case.  (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.)

> Also, the assertions about firewalls are interesting; we're hearing very different assertions in the discussions of QUIC (e.g,. 90%+ success rates for UDP protocols).

Apart from the backend motivation, the main motivation for CoAP over TCP was easier NAT traversal (UDP bindings are timed out much faster in most NATs).  This may extend to other middleboxes, including firewalls that build (and then time out) UDP-based state.

I’m not sure the QUIC numbers transfer to this use case very well, as QUIC is mostly used for web page access from browsers, so short NAT binding timeouts don’t matter that much.  For a sensor that needs to be accessed every 30 minutes, these are much more of an issue.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 12 Apr 2017 09:51:38 +0000

Dear 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).

The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices.

I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit?

Best regards
Matthias

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Apr 2017 11:06:06 +0100

Hi Matthias,

> I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly…
We have a WG for this:
  https://datatracker.ietf.org/wg/webpush/about/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Apr 2017 20:09:21 +1000

[ cutting down the CC a bit ]

> On 12 Apr 2017, at 8:06 pm, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Matthias,
> 
> 

Well, yes and no. My understanding is that web push is designed for a very specific use case / deployment scenario, and it is likely not appropriate for other uses.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 12 Apr 2017 10:16:56 +0000

> >> I am not sure what is the preferred way to solve the async communication
> issue of HTTP. Server Sent Events, for instance, are already pretty close to the
> Observe mechanism. Maybe we could properly fix the push support of HTTP to
> counter the endless stacking of protocols a bit?
> > We have a WG for this:
> Well, yes and no. My understanding is that web push is designed for a very
> specific use case / deployment scenario, and it is likely not appropriate for other
> uses.

This is also my conclusion about this variant of HTTP push.

Best wishes
Matthias

---

From: Bill Silverajan <[email-masked]>
Date: Wed, 12 Apr 2017 13:53:05 +0300

Hello,

> I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case.  (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are i…
Carsten's right. The primary use case which motivated us to undertake 
the work were for browser access, and for sandboxed web applications 
that want to use CoAP-based communication to a end-point, but are 
restricted from using system-level APIs such as TCP or UDP socket 
libraries. Matthias (in a forked version of this message thread) also 
mentioned where we saw benefits in allowing CoAP over Websockets to 
reach constrained devices.

While the work was progressing however, we did become aware of minor use 
cases where using CoAP over Websockets can provide an advantage: 
Reaching constrained nodes residing in domains where end users may lack 
the authority to configure middleboxes to allow new services over 
TCP/UDP. This is commonplace in particularly restrictive and firewalled 
networks that otherwise allow traditional messaging, email and web-based 
services. However, I need to emphasise this is a minor use case.

Best regards,
Bill

---

From: Jaime Jiménez <[email-masked]>
Date: Thu, 13 Apr 2017 14:47:00 +0000

Hi,

could you share data source on that pls? It’d come in handy.

Ciao!
- - Jaime Jiménez

On 12 Apr 2017, at 5.42, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

(e.g,. 90%+ success rates for UDP protocols).

---

From: Brian Raymor <[email-masked]>
Date: Wed, 19 Apr 2017 00:48:17 +0000

Thanks for your thoughtful feedback, Mark.

Carsten responded:
> 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.)

> (*) https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60

Some context - during the security discussions in the WG, there was a recommendation to "mirror" the similar section in RFC7252.

https://tools.ietf.org/html/rfc7252#section-9 states:

  The NoSec and RawPublicKey modes are mandatory to implement for this specification.

which is why NoSec is MTI. 

I agree with Carsten. I'd be happy to make this completely optional if it results in less dissonance for reviewers and there are no objections in the WG.

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Wed, 19 Apr 2017 17:58:53 +0000

Hi there

I am picking up this discussion again, as I was made aware of another use case for CoAP-over-WebSockets related to firewalls or shielded networks: without having looked into the details, HTTP CONNECT apparently does not allow for OAuth, while upgrading to WebSockets can make use of OAuth to establish a secure channel between two edge CoAP proxies that, for instance, forward requests from devices behind one firewall to devices behind another firewall.

Best wishes
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Apr 2017 21:10:31 +0200

Hi Matthias,

while I can imagine uses cases like that, I don’t believe that a specification has to be exhaustive in listing its use cases.  The CoAP over WebSockets work was motivated by getting full CoAP functionality into a browser by providing a way for JavaScript code to use a proxy, and maybe it is enough to point this out in the specification.  I don’t think it is expedient to add use cases that tend to press unrelated buttons in people — even if they are made possible by the generality of the specification.  Implementers will find out anyway...

Grüße, Carsten

> On Apr 19, 2017, at 19:58, Kovatsch, Matthias <[email-masked]> wrote:
> 
> Hi there
> 
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Apr 2017 21:22:05 +0200

> defined to use well-known URIs, so this is an invalid use.

Clearly, this is a bug in draft-ietf-core-coap-tcp-tls-07.

I have argued that underlying this is an omission in RFC 6455:

ws:/wss: URIs are translated into http:/https: URIs, and the well-known space is already reserved in the latter, so it would be nonsensical to try to use RFC 5785 /.well-known for something else in the ws:/wss: URI schemes.

Maybe there wasn’t a use case for well-known URIs in WebSockets before, but there is one now, and we would like to remedy this omission in the procedurally simplest possibly way.

So I am proposing to add RFC 5785’s well-known URI mechanism to these URI schemes in the document that needs it, draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455.

Are there any objections to this procedure?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Apr 2017 21:32:37 +0200

> So I am proposing to add RFC 5785’s well-known URI mechanism to these URI schemes in the document that needs it, draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455.

Forgot to add the pointer to the simple fix text:

https://github.com/core-wg/coap-tcp-tls/pull/128/files

Grüße, Carsten