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

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Martin,

We've posted a new version (-16) with the rolie:format changes as discussed. Thank you again for your work in reviewing the document, it has been extremely helpful in improving the draft throughout these last several draft iterations.

Thanks,
Stephen Banghart

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Thursday, December 14, 2017 11:39 AM
> To: Waltermire, David A. (Fed) <[e-mail]>
> Cc: Banghart, Stephen A. (Fed) <[e-mail]>;
> [e-mail]; [e-mail]
> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> Hi Dave, I think that you are underestimating the cost of each of these, but
> it's ultimately your document and your responsibility.  I won't continue to try
> to convince you further :)
> 
> On Thu, Dec 14, 2017 at 8:32 AM, Waltermire, David A. (Fed)
> <[e-mail]> wrote:
> > 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