Re: [apps-discuss] +exi

Ned Freed <ned.freed@mrochek.com> Sun, 12 February 2012 20:28 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 590A121F8683 for <apps-discuss@ietfa.amsl.com>; Sun, 12 Feb 2012 12:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 vAwrMsdvhhhX for <apps-discuss@ietfa.amsl.com>; Sun, 12 Feb 2012 12:28:22 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D3C0C21F8610 for <apps-discuss@ietf.org>; Sun, 12 Feb 2012 12:28:22 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBWIJZXN3K00KYHY@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 12 Feb 2012 12:28:15 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBR11Q7E9S00ZUIL@mauve.mrochek.com>; Sun, 12 Feb 2012 12:28:09 -0800 (PST)
Message-id: <01OBWIJWLZRM00ZUIL@mauve.mrochek.com>
Date: Sun, 12 Feb 2012 12:21:39 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 12 Feb 2012 20:59:45 +0100" <b96gj7pa05cim9fo6s4oe83dh8p88q7bc5@hive.bjoern.hoehrmann.de>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
References: <CB59D465.18D85%psaintan@cisco.com> <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> <4F357924.2070705@stpeter.im> <hnuaj7hjvc3l168s7j5h634530ecfq1j41@hive.bjoern.hoehrmann.de> <01OBTT8X03QS00ZUIL@mauve.mrochek.com> <b96gj7pa05cim9fo6s4oe83dh8p88q7bc5@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: paduffy@cisco.com, Mark Nottingham <mnot@mnot.net>, Thomas Herbst <therbst@silverspringnet.com>, Ned Freed <ned.freed@mrochek.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] +exi
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: Sun, 12 Feb 2012 20:28:23 -0000

> * Ned Freed wrote:
> >> Last I heard the idea was that draft-ietf-appsawg-media-type-regs would
> >> formalize the `+example` convention, but someone would have to write the
> >> registration for `+json` separately. That has not happened yet as far as
> >> I am aware. I argued that draft-ietf-appsawg-media-type-regs should re-
> >> gister already established conventions like `+json`, but apparently I
> >> was unsuccessful.
> >
> >Read the draft again, in particular the IANA considerations. That's exactly
> >what it does do.

> I take it you mean

>    o  The initial content of the registry shall be constructed at the
>       time of the registry's creation by the designated media types
>       reviewer(s) by examining the current media types registry and
>       extracting all conforming uses of "+suffix" names.

> I would have expected the draft to have the actual registration forms
> for the suffixes in question, but okay.

Material for one time use like this turns into useless clutter the minute the
registrations are done. In fact it's worse than useless  clutter - a careless
reader might infer that the registrations in a registration document like this
are the list of available suffixes.

Additionally, I don't see any point in duplicating existing registry content
anywhere else and then having to continually check to see if any new prefixes
have shown up in the registry. So I'm also opposed to having a separate
document to do this. That's why I came up with the idea of having the reviewers
create the initial suffix registry content from the existing media types
registry.

Again, the lighter the processes we define, the better.

				Ned