[appsdir] Apps Directorate review of draft-ietf-ecrit-additional-data-36

[Tim Bray <[e-mail]>]

I have reviewed this document on behalf of the Apps Directorate.  This
review covers mostly technical matters, in particular related to the XML
message structure.

This document describes a variety of XML data structures for use in Public
Safety applications, along with MIME and SIP message packaging techniques.

There is one issue which will require consideration at the IETF level:
Although these messages are acknowledged to contain highly private
information, the specification allows the use of plain-text transmission
because, and I quote: “as an emergency call, it is more important for the
call to go through than for it to be protected”.  Which is OK as long as
there is a basis of trust that the notion of “emergency call” is not being
used by either criminal elements or abusive government regimes.  Is the
specification’s language acceptable in the context of RFC7258?

That aside, the message framework described here seems well-thought-through
and ready for publication.  However, I recommend consideration of the
following changes for improving the safety and usability of this framework.

1. Must-Ignore policy

The last paragraph of section 6 emphasizes “The general principle that
applies to emergency calls is that it is more important for the call to go
through than for for everything to be correct”.   There is one particular
case related to both this and to the evolution of this format over time.
While the draft emphasizes that evolving this message format is difficult,
experience suggests that technology providers succumb to the temptation to
“enrich” message formats by adding new elements.

The standard way to avoid breakage as a consequence, and to facilitate
future evolution, is with a “Must-Ignore” policy, as discussed, for example
in RFC7493, see https://tools.ietf.org/html/rfc7493#section-4.2

I think it would be beneficial if, early in the draft, there were a
statement of principle that when a receiving implementation encounters an
XML element or attribute that it does not recognize, it MUST NOT regard
this as a fatal error and MUST NOT alter its behavior.

Spelunking through the schema I observe occasional occurrences of xs:any,
which suggests some thought has been given to this, but being explicit at
the prose level would be beneficial.

2. Schema Choice

I think there is fairly widespread consensus in the community of document
structure designers that Relax-NG is a schema framework which is vastly
superior to XML Schema; capable of modelling more real-world data
structures more cleanly and readably.  Since there are high-quality
automatic conversion tools, perhaps the schema could be offered as Relax-NG?

Also, I didn’t find any mention of whether the assertions in the schema are
to be considered normative, i.e. what is the consequence of a message
arrives which does not conform to that schema?  As a general principle the
IETF has preferred specifications in which the normative English prose is
self-contained and doesn’t require understanding a schema.

3. Namespaces

The examples could be made considerably more human readable with the wider
use of default namespaces.  This is already done for vcard examples, but
why not extend it.  All those colons are reader-hostile.

4. com:Comment

Can this contain any markup, for example HTML?  This may be explicit in the
schema but it's not in the human-readable text.