Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt

ht@inf.ed.ac.uk (Henry S. Thompson) Fri, 13 April 2012 21:18 UTC

Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3AD21F8646 for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 14:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBbrcUPSn+Bo for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 14:18:18 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4E51E21F8615 for <apps-discuss@ietf.org>; Fri, 13 Apr 2012 14:18:18 -0700 (PDT)
Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q3DLHkno006551; Fri, 13 Apr 2012 22:17:51 +0100 (BST)
Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q3DLHkxF013888; Fri, 13 Apr 2012 22:17:46 +0100
Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q3DLHkdu014636; Fri, 13 Apr 2012 22:17:46 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3DLHkIL014631; Fri, 13 Apr 2012 22:17:46 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Zach Shelby <zach@sensinode.com>
References: <D73B8F43-AC66-48B9-BE26-A38A97C628B4@tzi.org> <f5bmx6ftxm2.fsf@calexico.inf.ed.ac.uk> <4F88546D.5020007@gmx.de> <f5behrrtwqc.fsf@calexico.inf.ed.ac.uk> <4F885889.5020401@gmx.de> <f5baa2ftvfy.fsf@calexico.inf.ed.ac.uk> <4F886487.3050806@gmx.de> <f5b62d3tsg2.fsf@calexico.inf.ed.ac.uk> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <f5bbomvs7fz.fsf@calexico.inf.ed.ac.uk> <4F888D02.7050802@gmx.de> <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com>
From: ht@inf.ed.ac.uk
Date: Fri, 13 Apr 2012 22:17:45 +0100
In-Reply-To: <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com> (Zach Shelby's message of "Fri, 13 Apr 2012 23:38:48 +0300")
Message-ID: <f5b3987s552.fsf@calexico.inf.ed.ac.uk>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Cc: Julian Reschke <julian.reschke@gmx.de>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt
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: Fri, 13 Apr 2012 21:18:19 -0000

Zach Shelby writes:

> Do we need to write up some kind of information guideline draft for
> including this kind of information in the media registration when
> OOB info needs to be defined (not just for EXI, but in general)?

This still just feels wrong.  Consider encrypted transmissions.  You
need a key to decrypt them.  That's (of necessity) OOB information.
The idea that the media type of the transmission somehow should be
involved in that whole aspect of things just seems wrong.
Compression, like encryption, is (at least partly) _orthogonal_ to
media type.

We are getting into the delicate, difficult territory I already
mentioned once, to do with the extent to which accepting 'exi' as a
coding-type amounted to bending the rules.  The simple two-layer story
implicit in the original media type architecture (here's a character
sequence, and here's a key to unlock its meaning), later extended to
three (the +... media types) in one direction, or three/four in
another (transfer- and content-encoding) is just not flexible enough
to deal with the complexity of contemporary practice.  Compound
documents, e.g. XHTML+MathML+(SVG-with-XHTML-inside) are one class of
problems.  What does it mean, for example, to say that the meaning of
a fragment identifier is determined by _the_ media type of the
entity-body in such a case?  Encodings of information, rather than
byte-sequences (e.g. EXI) are another.  OOB-dependencies may well be
another.

I'll crawl back into my hole now, and maybe wait to see what the
proposed media type registration for 'senml-exi' looks like, since
I've run out of ideas to try to provide a locally-adequate
workaround. . .

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]