Re: [Gen-art] Gen-ART review of draft-ietf-appsawg-media-type-suffix-regs-06

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 19 October 2012 12:15 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C9E21F8643 for <gen-art@ietfa.amsl.com>; Fri, 19 Oct 2012 05:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.409
X-Spam-Level:
X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00lJDSuXRpVB for <gen-art@ietfa.amsl.com>; Fri, 19 Oct 2012 05:15:06 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6737821F863F for <gen-art@ietf.org>; Fri, 19 Oct 2012 05:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1350648905; d=isode.com; s=selector; i=@isode.com; bh=YSTixY7IeF3ewtEpZ7df9t4iaWS+TohZN2y5BnvnRfM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uBRrB/KoMSsZGenloBnMlieNIgM5ucI3bJpLeXxvUAMu5X3jKoGId/ru3AC4GAzOu6J0vS Rc6DwB7vIsNtU4uuGShfip8L5oPIMvkLDGIsbafJ++wMtPrIsQo2lwJ5GHEqyFMFhOVFKW E48Fu6XrUSGcrsn3tWc+ty8GB95LlYc=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UIFESAAbAkA-@statler.isode.com>; Fri, 19 Oct 2012 13:15:05 +0100
Message-ID: <5081444F.8090806@isode.com>
Date: Fri, 19 Oct 2012 13:15:11 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnX11-NWygv3xzzcVRs=-nUJH7xb3N7VfrhKyq517kC-MA@mail.gmail.com>
In-Reply-To: <CABkgnnX11-NWygv3xzzcVRs=-nUJH7xb3N7VfrhKyq517kC-MA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-appsawg-media-type-suffix-regs.all@tools.ietf.org, gen-art@ietf.org
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-appsawg-media-type-suffix-regs-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2012 12:15:07 -0000

Hi Martin,
Thank you for your review.

On 16/10/2012 22:48, Martin Thomson wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-appsawg-media-type-suffix-regs-06
> Reviewer: Martin Thomson
> Review Date: 2012-10-16
> IETF LC End Date: 2012-10-19
> IESG Telechat date: 2012-10-25
>
> Summary: This document is ready for publication as a (?) RFC.
>
> Minor issues: Is BCP status really appropriate?  Informational seems
> more appropriate for this sort of document.  The choice of providing a
> modicum of guidance in Section 2, as opposed to in the RFC that
> establishes the registry, could suggest this status, but that seems a
> bit weak as motivation.
This is a Normative reference for a BCP. It was split off from it.

I agree the registrations themselves can be Informational.
> Nits:
>
> +der doesn't even make a passing reference to +ber.  That's odd, since
> one describes a subset of the other.
It might be worth adding a sentence on this.
> Mention of schema for +der and +ber doesn't seem relevant to the key
> security consideration: that structures can be nested indefinitely.
> This is possible regardless of what the schema says - a generic
> processor is more likely to fall victim in that regard.
This is not really different from arbitrary nesting in, for example, 
XML. But I suppose this can be pointed out explicitly.