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

[Martin Thomson <[e-mail]>]

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