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

Tim Bray <tbray@textuality.com> Mon, 12 October 2015 18:08 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: appsdir@ietfa.amsl.com
Delivered-To: appsdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED221ACDF9 for <appsdir@ietfa.amsl.com>; Mon, 12 Oct 2015 11:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.323
X-Spam-Level: *
X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKaeB7-Gad2D for <appsdir@ietfa.amsl.com>; Mon, 12 Oct 2015 11:08:20 -0700 (PDT)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6AA1ACDDF for <appsdir@ietf.org>; Mon, 12 Oct 2015 11:08:20 -0700 (PDT)
Received: by igbni9 with SMTP id ni9so43256191igb.1 for <appsdir@ietf.org>; Mon, 12 Oct 2015 11:08:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=M9TpXh0wJDwBNutS6JbVV2tbvwB7JgeCSmWxVA7ADtY=; b=A9FmWEIOtPW6ki/d/kaaBWXAoyQHhxKunYdTtOrEQqs1ixY8B6L3ma/k3iJM3KbxPg neRxDG7d2YDNoiQH8zm/PEwbeyVOUo6vOJgPm6PJwnwjBR0ygqpeRr3Ug+8Dy4co9bbc gGbehFFMuZB84uFbz6gx1SMgNFxLltTf6ctyAI2R/fx0n9Pso7O18dU7a7XIeKS9zI4e PvBCfpoDc1KYqgW1RFfeX37ki427+evMUkTFacCHhWZfWNQ6QgRTQ58yGT3d3a8jBHZD R0np1KWlflTdI+hvbSosjYlrZqOOyd6SlfsWvXqQC9Xhc9tBwcIdoYDcTwwrKqMjhFGH u0Ag==
X-Gm-Message-State: ALoCoQnRZ8uiigCu2DoJ24h0XQxrQwMIY212hqi5xTmZSIfPbRj3+HYDDIrD2oDCCKMH6gK5XVPH
X-Received: by 10.50.57.102 with SMTP id h6mr13648321igq.29.1444673299972; Mon, 12 Oct 2015 11:08:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.30.4 with HTTP; Mon, 12 Oct 2015 11:08:00 -0700 (PDT)
X-Originating-IP: [24.84.248.61]
From: Tim Bray <tbray@textuality.com>
Date: Mon, 12 Oct 2015 11:08:00 -0700
Message-ID: <CAHBU6iu3ORk5HTWL9WO6NcOS9-+QE82W286eCqoqfVZTVBy=DQ@mail.gmail.com>
To: The IESG <iesg@ietf.org>, "appsdir@ietf.org" <appsdir@ietf.org>, draft-ietf-ecrit-additional-data.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=047d7bdc165edca7e30521ec3642
Archived-At: <http://mailarchive.ietf.org/arch/msg/appsdir/ELqi1u9vMiAJ85dhjiAZVbc2Bys>
Subject: [appsdir] Apps Directorate review of draft-ietf-ecrit-additional-data-36
X-BeenThere: appsdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Apps Area Review List <appsdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/appsdir>, <mailto:appsdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/appsdir/>
List-Post: <mailto:appsdir@ietf.org>
List-Help: <mailto:appsdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/appsdir>, <mailto:appsdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2015 18:08:22 -0000

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.