Re: [mile] Artart last call review of draft-ietf-mile-rolie-10

[Martin Thomson <[e-mail]>]

Apologies for delays; travel.

On Wed, Dec 6, 2017 at 3:28 PM, Waltermire, David A. (Fed)
<[e-mail]> wrote:
> I agree that media types would be ideal here, but they are insufficient for what we are trying to accomplish in ROLIE. Let's use a ROLIE entry for an IODEF resource as an example. A notional example ROLIE entry might look like this:
[...]
> In the example, the <rolie:format> element informs the client that the content is IODEF v2 content, which can then be used by the client to make a decision to filter or download the content. The client may choose to filter if it doesn't support IODEF 2.0 as an example.

Why would defining "application/iodefv2+xml" be worse than this?  It's
simpler.  It fits with a bunch of other mechanisms.  A new, bespoke
format that is more complex, yet still inadequate, is strictly worse
in my opinion and experience.

> A primary reason in my mind is that we are looking for an approach that will map to JSON objects easily. We are working on new drafts for representing ROLIE feeds in JSON and CBOR. In such an approach, use of a URN-based property table (with indexes for CBOR) provides a path that can be more easily translated to JSON as compared to using ns+localname. We are willing to forego some constraints in the grammar to make JSON and CBOR an easier proposition for this application.

I'm not sure that I find this any more persuasive.  ns+localname is
trivial to map to JSON provided you stick to simple types for values.