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

Ned Freed <ned.freed@mrochek.com> Fri, 18 May 2012 04:18 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 01FE521F869F; Thu, 17 May 2012 21:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.205
X-Spam-Level:
X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 IF91gTe905-Y; Thu, 17 May 2012 21:18:09 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0F21F8684; Thu, 17 May 2012 21:18:09 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFLQQR7EO0001NX2@mauve.mrochek.com>; Thu, 17 May 2012 21:18:06 -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:18:03 -0700 (PDT)
Message-id: <01OFLQQP4FDM0006TF@mauve.mrochek.com>
Date: Thu, 17 May 2012 21:05:43 -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:18:10 -0000

> >>>> * Section 5.4 directs people to send comments on registered media types to
> >>>> IANA. Isn't it more appropriate/straightforward to send them to the change
> >>>> controller, optionally CC:ing the types list?
> >>>
> >>> No, I don't think so. Sending it to IANA insures that it gets tracked.
> >
> >> Is there an expectation that the comments will be collected, or that there
> >> will be metrics for comments on a media type, or...? I don't see the benefit of
> >> giving IANA yet another thing to do here.
> >
> > That's the whole point - if the comment seems sensible, it gets added to the
> > registration. If we send comments to change controller, I think there's a fair
> > chance that's as far as they will go.

> So, IANA becomes the arbiter of what's an applicable comment here? Is the
> assumption that they'll consult with the DE as appropriate?

Of course they will. That's how IANA works. Please remember that it was IANA
that started the whole outside reviwer process; the IETF started writing it
down *long* after it was the norm. But I suppose there's no harm in adding a
clause making it explicit.

In any case, since the procedure has been in place for long time and AFAIK it
has never been used, the bigger problem is likely to be that IANA will have no
idea how to actually make the comment visible on the site, assuming a comment
is ever actually made.

> >> I see. In that case, I'll add a comment that separating the provisional and
> >> permanent registries doesn't work well, IME; we have a similar situation in the
> >> Message Header registry, and forcing people to look into two lists makes it
> >> confusing. I'd recommend a single, authoritative list, using the status field
> >> to distinguish them.
> >
> > I strongly disagree. I think the problem of provisionals being seen as real if
> > they are intermixed, no matter how well they are labelled.

> Once they're registered, they are real.

No, they most certainly are not. They aren't supposed to be deployed. That's
what real means to me in this context.

				Ned