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

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

Martin,

Comments below.

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Sunday, November 05, 2017 7:58 PM
> To: Banghart, Stephen A. (Fed) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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)
> <[e-mail]> 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