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

Ned Freed <ned.freed@mrochek.com> Thu, 12 April 2012 21:01 UTC

Return-Path: <ned.freed@mrochek.com>
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 90F3921F8730 for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 14:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599]
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 EYY3b8E1ea3Y for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 14:01:37 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5870821F872D for <apps-discuss@ietf.org>; Thu, 12 Apr 2012 14:01:36 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8FAF1RV4005JVJ@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 14:01:32 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 14:01:30 -0700 (PDT)
Message-id: <01OE8FADTZ7S00ZUIL@mauve.mrochek.com>
Date: Thu, 12 Apr 2012 13:57:00 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 12 Apr 2012 14:50:25 -0400" <4F8723F1.8080201@att.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="ISO-8859-1"; format="flowed"
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <FBCADBF9-D6FB-4E0D-9668-F5B3EF744037@tzi.org> <f5bobqye1vj.fsf@calexico.inf.ed.ac.uk> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <4F8723F1.8080201@att.com>
To: Tony Hansen <tony@att.com>
Cc: "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: Thu, 12 Apr 2012 21:01:37 -0000

> The Structured Syntax Suffixes are appropriate for use when the media
> type identifies the semantics of the protocol payload. That is, knowing
> the semantics of the specific media type provides for more specific
> processing of the content than that afforded by generic processing of
> the underlying representation.

> At the same time, using the suffix provides receivers of the media types
> to do generic processing of the underlying representation in cases where

>      1) they do not need to handle specially the specific semantics of
> the exact media type, and,

>      2) there is no special knowledge needed by such a generic processor
> in order to parse that underlying representation other than what would
> be needed to parse any example of that underlying representation.

> Please correct me if the following is wrong:

> It is my understanding that the general underlying representation of
> EXI-based types *may* be totally generic. However, each EXI type also
> pre-defines a dictionary specific to that type that the EXI
> representation may use to shorten the output. So if I hand a media type
> to a generic EXI parser, it will do fine until it hits something that is
> only defined in that type-specific dictionary. Unfortunately, the
> type-specific dictionary is not included in the EXI representation, but
> must be gathered out-of-band.

Even this might, and I emphasize might, be barely acceptable if there was
always a SchemaId in the content clearly identifying the necessary schema and
such schemata are always generally available. But it has been clearly stated
that that's not always the case. Indeed, one of the purposes of registering
these types is apparently to specify the SchemaId default when one is not
included.

If that's the case, then this is really not acceptable. Media type
registrations are not intended for this sort of automatic information
extraction. Some other mechanism would have to be used, and we'd have to have a
pretty serious discussion about the advisability of doing that.

> So it seems like +exi *could* be used if the representation stuck to
> only using the generic dictionary and eschewed any type-specific
> out-of-band dictionaries.

Agreed. That would make the definition of +exi acceptable. Whether or not
that's an acceptable restriction for users of EXI is, of course, another
question entirely.

				Ned