Subject: [core] HTTP-CoAP: media type mapping

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Tue, 2 Dec 2014 09:30:58 +0000

(On behalf of the HTTP-CoAP I-D editors.)

During IETF Hawaii, Carsten suggested that we bring the media type mapping
problem [1] to the mailing list for a further round of comments.

Brief summary of the topic: we want to allow media type and content
formats to evolve freely at the two ends of the translation chain, without
the HTTP-CoAP proxy becoming the point where media type information is
lost in translation.

In particular, there are two (pretty orthogonal) sub-topics on which the
discussion can focus on, matching the two sides of the problem:

1) CoAP -> HTTP mapping

Proposal: define an open ended HTTP media type "application/x-coap-<n>" -
where n is the decimal representation of the corresponding CoAP content
format - to handle the mapping of CoAP content formats that are unknown to
the proxy, instead of falling back to the completely opaque
"application/octet-stream".

2) HTTP -> CoAP mapping

Proposal: define some some kind of automatic mechanism that would allow
the proxy to get the "freshest" mapping function automatically.

On the latter point, a possibility that Carsten mentioned was to extend an
experiment that Klaus is currently running that periodically scans the
IANA media type registry and assigns content format numbers to all media
types that are in that registry.  If we manage to define the interface to
retrieve the mapping function, then we could possibly ask IANA to generate
these numbers for us.  (Maybe Carsten wants to expand a bit on this.)

Note that if such interface is available, it can be used as the primary
method for handling the other side of the mapping as well, leaving the
"application/x-coap-<n>" option as a last resort.

We (HTTP-CoAP editors) had some initial discussion on this point, and the
feeling was that although the proposal is attractive, bundling it with the
HTTP-CoAP draft is likely to slow the latter down a lot.  We think it'd be
better to sketch the proposal in a separate I-D, and then let the
HTTP-CoAP I-D (informationally) reference it as one option for a dynamic
configuration of the media type mapping mechanism.

Comments welcome,
Cheers

[1] http://tools.ietf.org/html/draft-ietf-core-http-mapping-05#section-6.3