Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-media-type-regs-07

Ned Freed <ned.freed@mrochek.com> Thu, 24 May 2012 17:02 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 C2C2621F85C9; Thu, 24 May 2012 10:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 DcCufVM1X+la; Thu, 24 May 2012 10:02:48 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5C21F85A5; Thu, 24 May 2012 10:02:48 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFUV6RX5AO002CP6@mauve.mrochek.com>; Thu, 24 May 2012 10:02:41 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFQWV49GTC0006TF@mauve.mrochek.com>; Thu, 24 May 2012 10:02:34 -0700 (PDT)
Message-id: <01OFUV6NJYR60006TF@mauve.mrochek.com>
Date: Thu, 24 May 2012 09:49:09 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 24 May 2012 15:10:58 +0100" <4FBE4172.5020509@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format="flowed"
References: <39405CB0-D62D-419F-83C6-DB3CFA7CD9B7@mnot.net> <01OFJW6FHKJ60006TF@mauve.mrochek.com> <004C9D74-9447-43F5-8C29-32E26716FB99@isode.com> <01OFJY4T4E9K0006TF@mauve.mrochek.com> <0B11FB37-5971-4191-9298-85A357794C8F@isode.com> <01OFK4MBYUPG0006TF@mauve.mrochek.com> <4FBE4172.5020509@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: Mark Nottingham <mnot@mnot.net>, Ned Freed <ned.freed@mrochek.com>, IESG IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, "draft-ietf-appsawg-media-type-regs.all@tools.ietf.org" <draft-ietf-appsawg-media-type-regs.all@tools.ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-media-type-regs-07
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, 24 May 2012 17:02:53 -0000

> Ok, maybe it is silly. But I've heard IANA people talking about private
> registrations of things like port numbers, which are hidden from the
> world until the product associated with such private registration is
> released.

I ask again: How many registration setup specifications have you seen that make
a point of stating that the information they cantain is supposed to be public?
You have yet to provide a single example. And a particularly relevant
counterexample is RFC 3864, which set up the provisional header field registry.
Nowhere did the IANA directions in that document say that the registry needed
to be public, yet it ended up that way. So the default is clearly public and an
explicit statement is required for a registry to be private.

But that said, this nonsense needs to stop, and if changing the wording is the
only way to accomplish that, so be it. How about:

  Standardization processes often take considerable time to complete. In order
  to facilitate prototyping and testing it is often helpful to assign
  identifiers, including but not limited to media types, early in the process.
  This way identifiers used during standards development can remain unchanged
  once the process is complete and implementations and documentation do not
  have to be updated.

  Accordingly, a provisional registration process is provided to support early
  assignment of media type names in the standards tree. A provisional
  registration MAY be submitted to IANA for standards tree types. The only
  required fields in such registrations are the media type name and contact
  information (including the standards body name).

  Upon receipt of a provisional registration, IANA will check the name and
  contact information, then publish the registration in a separate publicly
  visible provisional registration list.

  Provisional registrations MAY be updated or abandoned at any time. When this
  happens the media type is no longer registered in any sense; it can
  subsequently be registered just like any other unassigned media type name.

This intentionally leaves open whether or not any indication of abandoned
registrations should be visible. That can and should be IANA's call.

Does this work for you?

				Ned