Re: [apps-discuss] IANA issues, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24

Julian Reschke <julian.reschke@greenbytes.de> Wed, 30 October 2013 08:48 UTC

Return-Path: <julian.reschke@greenbytes.de>
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 9CFB911E8118; Wed, 30 Oct 2013 01:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 PkF6Prix4aae; Wed, 30 Oct 2013 01:48:39 -0700 (PDT)
Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7643011E8296; Wed, 30 Oct 2013 01:48:22 -0700 (PDT)
Received: from [192.168.2.117] (unknown [93.217.127.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 48C7610C06EE; Wed, 30 Oct 2013 09:48:20 +0100 (CET)
Message-ID: <5270C7D2.5010702@greenbytes.de>
Date: Wed, 30 Oct 2013 09:48:18 +0100
From: Julian Reschke <julian.reschke@greenbytes.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: S Moonesamy <sm+ietf@elandsys.com>, apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org
References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E7154.2070005@greenbytes.de> <6.2.5.6.2.20131029214748.0b93d3b8@elandnews.com>
In-Reply-To: <6.2.5.6.2.20131029214748.0b93d3b8@elandnews.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ietf-http-wg@w3.org, ietf@ietf.org
Subject: Re: [apps-discuss] IANA issues, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24
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: Wed, 30 Oct 2013 08:48:45 -0000

On 2013-10-30 06:24, S Moonesamy wrote:
> Hi Julian,
> At 07:14 28-10-2013, Julian Reschke wrote:
>> Yes -- this is not necessarily a problem. There are many things that
>> need to be defined for a new method, and not all of these fit into the
>> template.
>
> A DISCUSS about this can be easily addressed. :-)
>
> What is the intent behind the HTTP Method Registry (Section 8.1.3)?
> What information should that registry convey to the reader?  For
> example, is it a quick way for the reader to find out whether POST is
> cacheable (re. a choice that a browser vendor made some time back) or
> should the person read the relevant specification text to get accurate
> answer?

The template only contains a subset of the information, so in general, 
the reader will have to read the referenced RFC.

The entries in the template serve the purpose of shortcutting this 
lookup for considerations that can be answered with a simple "yes" or "no".

>> That's an assumption that is true for all "bare" Section references.
>
> The problem is that people copy and paste them blindly.  I suggest
> having information in the tables as the working group would like it to
> appear in the registry
>
>> The IANA Considerations are processed by the RFC Editor and IANA, and
>> they will make sure that the registry is properly populated. There's
>> no point in mentioning a still unknown RFC # here.
>
> It is up to the Responsible Area Director and the the document shepherd
> to make sure that the registry is properly populated.

And the authors during AUTH48. There is no problem here. We will make 
sure that the registry gets populated properly. Trust me.

> ...

Best regards, Julian