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

Ned Freed <ned.freed@mrochek.com> Fri, 18 May 2012 04:03 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 2FE7C21F860D; Thu, 17 May 2012 21:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level:
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 0fPdqYQHHJkL; Thu, 17 May 2012 21:03:38 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 559CF21F85D3; Thu, 17 May 2012 21:03:38 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFLQ8QAT1C001DIX@mauve.mrochek.com>; Thu, 17 May 2012 21:03:34 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com>; Thu, 17 May 2012 21:03:30 -0700 (PDT)
Message-id: <01OFLQ8NTHEG0006TF@mauve.mrochek.com>
Date: Thu, 17 May 2012 21:01:55 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 17 May 2012 17:13:37 +1000" <9A0F9270-B389-497F-A940-D4505E8E3F2A@mnot.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <39405CB0-D62D-419F-83C6-DB3CFA7CD9B7@mnot.net> <01OFJW6FHKJ60006TF@mauve.mrochek.com> <A36F2701-439D-48A6-9180-E69EABE6CE4D@mnot.net> <01OFK722DY440006TF@mauve.mrochek.com> <9A0F9270-B389-497F-A940-D4505E8E3F2A@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: 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
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: Fri, 18 May 2012 04:03:39 -0000

> On 17/05/2012, at 10:55 AM, Ned Freed wrote:
> >
> >> I'm not talking about re-defining the concepts, I'm saying that a quick,
> >> non-normative summary of what they are, along with pointers to more detailed
> >> information elsewhere, would help readers.
> >
> > Then feel to suggest text.

> Replace section 1 (Introduction) with:

> """
> Recent Internet protocols have been carefully designed to be easily
> extensible in certain ways. In particular, many protocols, including but
> not limited to HTTP [RFC2616] and MIME [RFC2045], are capable of carrying
> arbitrary labeled content.

> The mechanism used to label such content is a media type, consisting of a
> top-level type and a subtype, which is further structured into trees.
> Optionally, media types can define companion data, known as parameters.

> For example,

>   text/plain; charset=utf-8
  
> has a top-level type of "text", a subtype of "plain", which places the media
> type in the standards tree. Here, the "charset" parameter is serialised as it
> would be in HTTP.

> A registration process is needed for these labels, so that that the set of
> such values are defined in a reasonably orderly, well-specified, and public
> manner.

> Therefore, this document defines media type specification and registration
> procedures that use the Internet Assigned Numbers Authority (IANA) as a
> central registry.

> The media type registry managed by the procedures defined here can be found at
> <http://www.iana.org/assignments/media-types/>.
> """

> Just a suggestion, of course; I'm sure it can be improved upon.

With the exception of the example, which I think is unnecessary, this basically
seem fine to me. I don't see it as much of an improvement to be honest, but the
one thing it does do that I like is that by talking about the location of the
registry I can eliminate the section that does that.

				Ned