Subject: Re: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Oct 2016 20:35:34 +0000

I updated draft-thaler-core-redirect-01 with an example section (which roughly says what the email says below),
and expanded the security considerations section a bit.

Dave

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Wednesday, September 14, 2016 6:43 PM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt

Short version:

Existing clients do (multicast) GET /oic/res, and the response contains privacy-sensitive information, plus some links And existing servers will respond to multicast GET /oic/res (but not /.well-known/core).

Redirects allow the following optimized behavior...
New clients do (multicast) GET /oic/res (or /oic/res?rt=bar), and the responses would be:
a) legacy servers, and any new servers that are not configured to be privacy-sensitive, respond with actual content,
      thus keeping latency and messages to a minimum
b) new privacy-sensitive server would instead respond with a redirect to a coaps://<ipaddr>:<port>/oic/res
      A subsequent coaps GET /oic/res to that endpoint returns actual data (just as unicast coaps always did before).

Thus, the overhead is kept to a minimum.

Is that clear?

Dave

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Tuesday, September 13, 2016 1:27 PM
> To: Dave Thaler <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [core] FW: New Version Notification for 
> draft-thaler-core- redirect-00.txt
> 
> Hi Dave,
> 
> I'm afraid I'm not as familiar with the OCF specs here, so having a 
> fully fleshed out example would help me understand the problem better 
> than speaking abstractly about "the resource", "multicast query", etc.
> 
> I understood the problem statement as talking about the discovery 
> process, not about the actual sensor/actuator resources.
> 
> So a highly privacy sensitive device might just answer a multicast GET 
> to /.well-known/core with
> 
> <coaps://...>;ct=40
> 
> which means "I won't tell you anything about me except over some form 
> of a secure channel (and I'm not telling what form of that)"; maybe 
> some additional link relations can fill in the latter point a bit.
> 
> If it is a bit more lenient, it might even answer a GET to /.well- 
> known/core?rt=bar with a similar response, revealing that it does 
> implement a bar.
> 
> I'm not sure I understand how an HTTP-style redirect would help here 
> except by making things more complicated, so a more detailed example would help.
> 
> HTTP-style redirect is most useful where clients have long-term 
> memories of links and servers need to update their resource structure 
> during those long terms.  In the CoRE world, we expect clients to be 
> more agile on the discovery front, removing the need for redirects.  
> For the remaining situations where redirects were popular in HTTP, 
> returning RFC 7807-style error objects may be way more useful, because 
> we then have the whole media type system to distinguish all the fine 
> points that are so confusing about redirects.
> 
> Grüße, Carsten
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core