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

[Christian Amsüss <[e-mail]>]

Hello Dave,

(To: dropped due to very strict Microsoft mail servers -- hope you
notice this reply anyway)

On Thu, Sep 15, 2016 at 01:43:28AM +0000, Dave Thaler wrote:
> 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).

Does the (legacy) client's request have an "Accept" header of
application/link-format or absent? (The ?rt= seems to indicate that).

If yes, I think that the appropriate response in the b) situation would
be

<coaps://my-address/oic/res>;ct="40"

(preferably with whatever if= data that would lead to discovery of
/oic/res if it wasn't a hardcoded URI anyway; why not just .wk/c?).

Additional information according to a future version of
draft-silverajan-core-coap-protocol-negotiation-04 could be provided as
well, but the above is IMO sufficient to make the OCF use case work, and
seem not to incur much overhead compared to the Location-Scheme response
(I didn't do the exact byte counting on "://" vs. option number).

Would that work for you?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
tel:[phone]                | http://www.energyharvesting.at/
                                      | ATU68476614