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

[Martin Thomson <[e-mail]>]

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