Re: [art] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt

Ned Freed <ned.freed@mrochek.com> Tue, 28 February 2017 15:06 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAC1295B3; Tue, 28 Feb 2017 07:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qsDZgOHDZELb; Tue, 28 Feb 2017 07:06:03 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37A712953F; Tue, 28 Feb 2017 07:06:02 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBEUCWYHF4007NZV@mauve.mrochek.com>; Tue, 28 Feb 2017 07:05:07 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBDDVH6WZK0005AQ@mauve.mrochek.com>; Tue, 28 Feb 2017 07:05:04 -0800 (PST)
Message-id: <01QBEUCUSIQW0005AQ@mauve.mrochek.com>
Date: Tue, 28 Feb 2017 06:46:57 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 28 Feb 2017 15:23:05 +0100" <87r32io0mu.fsf@aung.informatik.uni-bremen.de>
References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> <01QBES7UHX6E0005AQ@mauve.mrochek.com> <87r32io0mu.fsf@aung.informatik.uni-bremen.de>
To: Olaf Bergmann <bergmann@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/dDgkLlPu14usblQeYeRFABKwJOw>
Cc: media-types@ietf.org, art@ietf.org, Ned Freed <ned.freed@mrochek.com>, core@ietf.org
Subject: Re: [art] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2017 15:06:04 -0000

> Hi Ned,

> Ned Freed <ned.freed@mrochek.com> writes:

> > Has something changed about the definition of EXI that would make it actually
> > appropriate as a media type suffix? Because unless there's been a change the
> > reason this hasn't progressed is because it's inappropriate for it to do so.

> What has changed is the fact that +exi is in actual use.

So are many other things that don't actually make sense. Usage doesn't
make something valid to register.

> > In particular, it isn't possible to process a type that ends in +exi in any
> > significant way without knowing the type's schema. So unless there's a way
> > of discovering that knowing nothing but the type name, +exi provides
> > no utility.

> Well, processing a document is one thing. But signaling that you can
> process a document (with or without schema) is another thing. The "+exi"
> suffix helps where application/exi and content-coding: exi are not
> applicable (e.g. in a CoAP Accept option). This is pretty much what the
> draft describes.

Hmm. Well, if this assessment of the mechanism in CoAP is valid - and I take no
position on that - it sounds to me like CoAP effectively extended the semantics
of media types in a fairly fundamental way.

In particular, it seems like you're using them as a signalling mechanism where
no data of the given type is actually involved. If that's indeed the case, then
that extension to the use of media types needs to be fully and completely
described, along with its security considerations, so that types intended
for this usage can undergo proper review before they are registered.

There is some precedent for such usage, in that there are cases where the
top-level name of a media type has been used for signalling, necessitating the
registration of essentially the same type under audio/ and video/. But the type
still functioned as a label for actual media.

Anyway, IMO you have a lot of work to do before the registration of +exi can
be justified.

				Ned