[apps-discuss] Feedback on draft-shelby-exi-registration-01

Robin Berjon <robin@berjon.com> Wed, 04 April 2012 13:28 UTC

Return-Path: <robin@berjon.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BFBC321F855B for <apps-discuss@ietfa.amsl.com>; Wed, 4 Apr 2012 06:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qpZDhitNeGI7 for <apps-discuss@ietfa.amsl.com>; Wed, 4 Apr 2012 06:28:34 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com []) by ietfa.amsl.com (Postfix) with ESMTP id BAB4D21F8539 for <apps-discuss@ietf.org>; Wed, 4 Apr 2012 06:28:34 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5BF8620E20 for <apps-discuss@ietf.org>; Wed, 4 Apr 2012 09:28:33 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([]) by compute6.internal (MEProxy); Wed, 04 Apr 2012 09:28:33 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version; s=smtpout; bh=fQhoU190dxOZPISsqDPIRYviZxk=; b=Es0 uKjiMGkVZhzrYURCn4DpmQMs+85PjKf0nCwQpdZYZpbVwKh6bZLUcY5cCkBzv7WZ zgEdNDB1e2DQFRj9tTdIoRB0bF2B6+4zkDHkrovc2RsNfx038JiJ8ZH46vjmB3Cf xBetxIpZeAOj49EDiOHtbgb9i7Vk9fT/EksgtarI=
X-Sasl-enc: 9W+2HGVkY3XEMCYgzS7WH6rFyhBsXUgFnV5q+TPSJ2Ze 1333546112
Received: from vis154b.sophia.inria.fr (vis154b.sophia.inria.fr []) by mail.messagingengine.com (Postfix) with ESMTPSA id C10198E0182; Wed, 4 Apr 2012 09:28:32 -0400 (EDT)
From: Robin Berjon <robin@berjon.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 04 Apr 2012 15:28:33 +0200
Message-Id: <6C13AB73-6302-43D4-87BC-FB7ECD968A5B@berjon.com>
To: apps-discuss@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 04 Apr 2012 08:16:24 -0700
Cc: draft-shelby-exi-registration@tools.ietf.org
Subject: [apps-discuss] Feedback on draft-shelby-exi-registration-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 13:28:35 -0000

Dear all,

please find some notes below on the draft-shelby-exi-registration-01 proposal that describes a +exi media type suffix. Before I jump in, I would like to make it clear that these comments are strictly my own and are not made as any of former chair of the EXI WG, the XBC WG, or as member of the W3C TAG.

• It is mentioned that the +exi suffix is defined "for use in a specific class of protocols". It further seems to be implied that these protocols do not support conveying content encoding separately from the type. I think that it would be helpful to specify what those protocols are. Given the cost and impact of introducing a +exi structure suffix across the board, without that information I can only suspect that it may be both cheaper and simpler to update the relevant protocols.

Additionally, if those protocols are designed to be simpler, easier to process profiles of HTTP, given that the use case covers devices that obviously already have an EXI decoder, in absence of further information I also wonder if those protocols could not be replaced by some form of EXI-encoded HTTP (possibly minus a number of headers). But naturally this is just a speculation made in absence of information.

• Reading the following:
The "+exi" Structure Syntax Suffix defined in this document is 
appropriate for use with a special class of protocols that:

   o  Make use of a Media Type to identify the semantics of the protocol
      payload, and offer more that one serialization of the payloads.
      For example, some protocols may offer JSON, XML and EXI
I cannot help but get a strong sense that this is actually making a case for using content coding rather than a structured suffix since it mirrors (certainly in the case of EXI) the semantics versus serialisation distinction. EXI was deliberately defined to be a content coding for XML; the group's decision to define an "exi" content coding rather than a +exi suffix was intentional and not an oversight.

Conflating content coding and media type seems at the very least strange to me. To take an example, we currently have image/svg+xml. This draft introduces image/svg+exi. Can you explain why that would be a good thing to introduce, and if it is should we also look into adding image/svg+gzip and image/svg+identity?

• This part "use EXI as a native encoding (without the use of XML as an interemediate)" worries me because it seems to stem from a rather fundamental misunderstanding of what EXI is. EXI is XML. There is no form of requirement to hop through XML Data Model -> XML -> EXI, and whichever way the EXI bitstream was produced really, really should be immaterial for any protocol transmitting it as well as for a potential media type registration.

• This is worrying: "The registration of a Media Type using this suffix MUST describe how to determine the XML Schema that is used to encode/decode a payload identified by that Media Type." What it does is register a generic suffix for a very specific usage. For instance, SVG has no XML Schema. The above therefore precludes SVG from potentially registering image/svg+exi (assuming it would be a sensible thing to do).

What's more, EXI is not limited to relying on schema information from XML Schema. It is perfectly valid to use DTDs, RelaxNG, JSON Schema, domain-specific knowledge, etc. in order to generate a schema-informed EXI encoding. So the above essentially rules out a large (possibly the majority) of XML content, and rules out valid EXI encodings. Again, 1) that seems very restrictive to justify a structured suffix; and 2) it reinforces the feeling that this registration may be in part motivated by some misunderstanding of EXI.


Robin Berjon - http://berjon.com/ - @robinberjon