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

["Waltermire, David A. (Fed)" <[e-mail]>]

Martin,

> Apologies for delays; travel.

No worries. 

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

I am agreeing with you that defining "application/iodefv2+xml" is better, but creating new media types for arbitrary formats is not the responsibility of ROLIE. The specifications for these things should be doing this. What we are providing through rolie:format is a way to address the less-than-ideal case of having no specific media type. The consensus of the WG was that this is needed.

In cases where a specific media type is provided, we could change the requirement making rolie:format optional. This would support the ideal case of using a media type without the rolie:format element and the less-than-ideal case of using something like "application/ xml" + rolie:format. We can work on some text if this sounds like a good compromise. Are you ok with this approach?

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

There are pros and cons on both sides of the argument. We have a good technical rationale for the text in the draft; we are willing to give up some validation to allow for a clearer path forward with JSON/CBOR. Can we agree to disagree and move forward on this one?

Thanks,
Dave