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

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 6 Dec 2017 21:28:31 +0000

Martin,

Comments below.

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Sunday, November 05, 2017 7:58 PM
> To: Banghart, Stephen A. (Fed) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> On Sat, Nov 4, 2017 at 2:52 AM, Banghart, Stephen A. (Fed)
> <[email-masked]> wrote:
> > Martin,
> >
> > Could you clarify which XML issues you mean? The rolie:format /
> rolie:property elements or something else?
> >
> > rolie:format is necessary beyond media types for differentiating between
> formats that don't have their own media type, and for making clear the
> difference between a "media type" and a "format". Media types provide
> information about the serialization of content, but don't actually define the
> model of the content. Schemas can be used to help the parser understand the
> content, rolie:format provides a means to describe both the model and the
> schema of the content. We could solve this by providing some modified media
> type, but this would require just as much specification as our current solution.
> As an example, how would we best specify to a consumer that the content
> element links to an IODEF document? It's media type is XML, but there remains
> information that can only be gleaned  by downloading the entire content file.
> 
> You describe the exact purpose of a media type.  The advantage of media types
> being that the type is available in more places than just a ROLIE Feed.  For
> instance, you can use content negotiation in HTTP to ensure that you get
> something you can consume.
> 
> I'm not saying that this is more or less specification, it's just that you get more
> value from a media type than you do with this sort of mechanism.  Even if it
> means minting a few more media types.

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:

<entry>
  <id>ec15f322-24d2-4cae-b6d0-344bf94a1b0d</id>
  <title>Makebelieve Incident Report</title>
  <link rel="self" href="https://example.com/rolie/ec15f322-24d2-4cae-b6d0-344bf94a1b0d"/>
  <link rel="alternate" href="https://example.com/rolie/ec15f322-24d2-4cae-b6d0-344bf94a1b0d"/>
  <published>2012-08-04T18:13:51.0Z</published>
  <updated>2017-12-05T09:35:31.0Z</updated>
  <summary>This is a made up incident report record to use as a ROLIE example.</summary>
  <rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0" version="2.0"
    schema-location="https://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd"
    schema-type="application/xml" />
  <content type="application/xml"
    href=" https://example.com/data/a1706568-efec-49d6-8c00-9f2a2b4dc6f1" />
</entry>

The media type defined in the content element ("application/xml") is insufficient to allow the client to know that this ROLIE entry points to IODEF content. Your suggestion to handle this using improved media types is one to strive for, but RFC 7970 does not provide a media type for IODEF XML. This means that without the <rolie:format> element, the most a client can know before accessing the content is that the content is any arbitrary, well-formed XML content ("application/xml").

The use of <rolie:format> provides a mechanism to determine more information about the model using the @ns and @version attributes, and the schema for the outer model using the @schema-location and @schema-type attributes. The @ns attribute is used to determine the model of the content, while the @schema-location and @schema-type are optional elements that can be used to determine the type and location of a schema, which also can support alternate schema languages for XML or JSON. These four attributes can give the client a richer set of contextual information to determine if the content is interesting or not.

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.

> Furthermore, identifying a schema is usually inadequate to describe the relevant
> parts of an XML format.  There are many generic container formats in XML for
> which listing the top-level schema is pointless.

While I agree, identifying the container format is better than only knowing "application/xml". Unfortuately, "application/xml" is all that can be known in common cases like IODEF v2 when no specific media type is defined. This solution acknowledges that the ideal does not always happen and provides a workable solution for when we get less from existing standards.

> ROLIE itself suffers from this because it uses Atom.  It's not even possible to list
> schemas, because that loses critical information about what elements are used
> in what contexts.  In order to properly capture the full transitive closure of
> formats, you need something considerably richer (I once thought that this worth
> doing/possible, but that idea was quickly abandoned without really testing it
> fully:
> https://tools.ietf.org/html/draft-thomson-simple-expressing-xml-support-00).

Interesting background. Thanks.

> > rolie:property has a couple of advantages over defining the key-value pairs in
> XML. Defining new elements in XML is expensive. In the ROLIE core document we
> define 4 new properties, which would yield 4 new elements in the schema. In our
>  Software Descriptor we define another software specific property, and we may
>  add more as we iterate the draft. There are two other extensions in development
> that may add new properties as well. rolie:property provides a means to easily
> define new properties without generating a huge number of new elements.
>
> I disagree on the XML - the amount of effort you put in to define your
> XML properties is pretty minimal: a namespace and schema, plus
> semantics of each of the fields.  You gain the ability to properly
> constrain the grammar (for example, you could use xs:dateTime for
> content-updated-date instead of prose).  You have demonstrated how
> easy that can be in this document (by defining rolie:property itself).

Yes. The ease of use argument is not the one I would have used.

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.

Note: We do not intend to create a general ATOM XML to JSON conversion since mapping arbitrary XML to JSON is not a fruitful exercise. Instead, we want to define a more limited ROLIE XML to JSON/CBOR mapping instead, which is more straightforward. I'd be happy to talk with you about our ideas on JSON and CBOR, but this should not hold up ROLIE. 

> I've dealt with extensible fields like this in the past (see RFC
> 6848), and it's no more difficult to pair up ns+localname and simple
> value than it is to pair up URN and simple value.

See above.

> As proposed, you also have a new registry for these fields, which is
> strictly more costly.

Yes. But it provides a mechanism for index and URN registration allowing for collision avoidance in a way that can facilitate work going forward. Should we document this better in ROLIE in order to move forward?

> p.s., I thought you were going to remove
> "urn:ietf:params:rolie:property:local", but it is still in -13.  That
> would of course be moot if you did as I suggest.

We will submit a -15 with the registration removed and any other required changes.

Thanks,
Dave

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 6 Dec 2017 21:28:31 +0000

Martin,

Comments below.

<entry>

See above.

Thanks,
Dave

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Dec 2017 17:38:36 -0600

Apologies for delays; travel.

> 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 exampl…
[...]
> 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 cl…

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.

> 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 appro…

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Dec 2017 17:38:36 -0600

[...]

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 14 Dec 2017 14:32:55 +0000

Martin,

> Apologies for delays; travel.

No worries. 

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

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 14 Dec 2017 14:32:55 +0000

Martin,

No worries. 

Thanks,
Dave

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Dec 2017 10:38:37 -0600

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 :)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Dec 2017 10:38:37 -0600

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Thu, 14 Dec 2017 19:14:17 +0000

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

> Sent: Thursday, December 14, 2017 11:39 AM
> To: Waltermire, David A. (Fed) <[email-masked]>
> Cc: Banghart, Stephen A. (Fed) <[email-masked]>;
> [email-masked]; [email-masked]
> 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 :)
> 
> >> 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:
> >> [...]
> >> 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.
> >>
> 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?
> >
> >> 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.
> >>
> > 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

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Thu, 14 Dec 2017 19:14:17 +0000

Martin,

Thanks,
Stephen Banghart

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Dec 2017 13:18:35 -0600

Looks good.

Nit: The brace alignment in the relaxng schema in Appendix A is a
little strange.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Dec 2017 13:18:35 -0600

Looks good.

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 14 Dec 2017 20:15:21 +0000

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

Thanks,
Dave

> Sent: Thursday, December 14, 2017 2:19 PM
> Cc: Waltermire, David A. (Fed) <[email-masked]>; [email-masked];
> [email-masked]
> Nit: The brace alignment in the relaxng schema in Appendix A is a little strange.
> 
> > 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
> >
> >> >> 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:
> >> >> [...]
> >> >> 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.
> >> >>
> >> >> 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.
> >> >
> >> 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.
> >> >
> >> 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?
> >> >
> >> >> 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
> >> >> 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.
> >> >
> >> 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

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 14 Dec 2017 20:15:21 +0000

Thanks,
Dave