Re: [appsdir] Apps Directorate review of draft-ietf-ecrit-additional-data-36
Randall Gellens <email@example.com> Mon, 12 October 2015 19:16 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2E1B34C7; Mon, 12 Oct 2015 12:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD3pIQT4Uvno; Mon, 12 Oct 2015 12:16:49 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [22.214.171.124]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E12A1B357E; Mon, 12 Oct 2015 12:16:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; firstname.lastname@example.org; q=dns/txt; s=qcdkim; t=1444677409; x=1476213409; h=message-id:in-reply-to:references:date:to:from:subject; bh=FOMLOu/79YKIfDlqgsuRswYUsTlVpUZ5x3Mt80UcWZg=; b=IhBIC8sWMiOu6NB/ny6OUdJmkAClvaYNCkOJgLMlHa7/VguWquf0rjwK m0kHUFcCQauvSax9tGUFZLsl5+iXEToMyhFwpkGuomBJNH8RRMHXCzZmC 89IivfhddsyZscc0ty2v+GVyn86v0USvUdFnmvDeQ0A0xNqCW8mV95eIX M=;
X-IronPort-AV: E=McAfee;i="5700,7163,7952"; a="143316086"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2015 12:16:48 -0700
X-IronPort-AV: E=Sophos;i="5.17,674,1437462000"; d="scan'208";a="562357882"
Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2015 12:16:33 -0700
Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t9CJGDXS010013; Mon, 12 Oct 2015 12:16:16 -0700
X-IronPort-AV: E=Sophos;i="5.17,674,1437462000"; d="scan'208";a="1067334784"
Received: from unknown (HELO [192.168.5.193]) ([10.64.194.45]) by Ironmsg04-R.qualcomm.com with ESMTP; 12 Oct 2015 12:16:11 -0700
X-Mailer: Eudora for Mac OS X
Date: Mon, 12 Oct 2015 12:12:56 -0700
To: Tim Bray <email@example.com>, The IESG <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, email@example.com
From: Randall Gellens <firstname.lastname@example.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: [appsdir] Apps Directorate review of draft-ietf-ecrit-additional-data-36
List-Id: Apps Area Review List <appsdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/appsdir>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/appsdir>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2015 19:16:51 -0000
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
- [appsdir] Apps Directorate review of draft-ietf... Tim Bray
- Re: [appsdir] Apps Directorate review of draft-... Randall Gellens