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

[Randall Gellens <[e-mail]>]

Hi Tim,

Thanks for your review.  I appreciate the effort that went into it. 
As it happens, the document went through IETF Last Call some time 
back, and cleared the last IESG DISCUSS a week or so ago, and was 
approved by the IESG today.  Luckily, your review did not identify 
any issues that require document changes.  Please see in-line for 
more details.

At 11:08 AM -0700 10/12/15, Tim Bray wrote:

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

The information will only be sent by a device on calls that the 
device knows are emergency calls.  Likewise, service providers in the 
call path will only include the information when processing calls 
initiated as emergency calls.


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

This is already a principle of the mechanism.  The document already 
says that entities use the "purpose" parameter values of the 
Call-Info header fields to identify the data structures available, 
and access those data structures they are interested in (by local 
policy).  Ipso facto, an entity will not be interested in an unknown 
data structure, hence, unknown data structures are ignored.  Part of 
the reason for this, as explained in the document, is that some 
elements may contain information that carries regulatory, legal, or 
other implications (e.g., medical information), so entities will only 
want to access structures that they are prepared to handle.

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

I think the current text is sufficient; if you disagree, it is 
possible to add editorial text during AUTH48, which I am happy to 
consider if you suggest exactly where the text now is deficient.

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

It's too late to make any technical changes.

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

The English prose description of the structures is sufficient, and 
multiple reviews have shown that the English prose description of the 
structures is consistent with the schemas (we went through a lot of 
work to check this).  Of course it is possible that there is some 
prose that does not match its schema and that none of the reviewers 
or authors noticed.  If so, this can be addressed by an errata.  The 
general principle that the call go through says that the call won't 
be failed because of it.  Each entity is free to either process 
non-confirming structures or not, and this is the case if the 
structure does not confirm to the prose, schema, or nether (should 
there be any instances where they differ).

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

Yes, this would have been worth considering had the review arrived a 
few weeks ago.

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

The schema permits any text valid for the xml 'string' type, so while 
markup is syntactically permitted, the description says that this is 
human-readable text and not intended to be machine-readable, so I'd 
say that strongly discourages using markup.  I think very few people 
would try to claim HTML (or XML  for that matter) to be 
human-readable.

Thanks again for your review.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Creativity is just connecting things. [C]reative people [are]
able to connect experiences they've had and synthesize new things
[because] they've had more experiences or ... have thought more
about their experiences than other people. ... A lot of people
... don't have enough dots to connect, and they end up with very
linear solutions without a broad perspective on the problem. The
broader one's understanding of the human experience, the better
design we will have.  --Steve Jobs, Wired Magazine, February, 1996