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

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

We can fix this with the RFC editor. Thanks again for all your feedback!

Thanks,
Dave

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Thursday, December 14, 2017 2:19 PM
> To: Banghart, Stephen A. (Fed) <[e-mail]>
> Cc: Waltermire, David A. (Fed) <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> Looks good.
> 
> Nit: The brace alignment in the relaxng schema in Appendix A is a little strange.
> 
> On Thu, Dec 14, 2017 at 1:14 PM, Banghart, Stephen A. (Fed)
> <[e-mail]> wrote:
> > 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