Re: [apps-discuss] Accept-Post HTTP header field

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Wed, 07 May 2014 00:45 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9151A02F9 for <apps-discuss@ietfa.amsl.com>; Tue, 6 May 2014 17:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_Htm3MM9gNt for <apps-discuss@ietfa.amsl.com>; Tue, 6 May 2014 17:45:54 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7233B1A02AD for <apps-discuss@ietf.org>; Tue, 6 May 2014 17:45:54 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4F5B332E55B; Wed, 7 May 2014 09:45:48 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 22ba_3932_15625677_4ca8_4d6c_be81_638eba445b9a; Wed, 07 May 2014 09:45:47 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D8B8EBF4D0; Wed, 7 May 2014 09:45:47 +0900 (JST)
Message-ID: <5369822F.3080401@it.aoyama.ac.jp>
Date: Wed, 07 May 2014 09:45:35 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Erik Wilde <dret@berkeley.edu>, "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
References: <53697AD6.2030504@berkeley.edu>
In-Reply-To: <53697AD6.2030504@berkeley.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o7MOZleXMvw6ly_Ljx2TN7eAr34
Cc: Steve K Speicher <sspeiche@us.ibm.com>, John Arwe <johnarwe@us.ibm.com>, Arnaud Le Hors <lehors@us.ibm.com>
Subject: Re: [apps-discuss] Accept-Post HTTP header field
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 07 May 2014 00:45:56 -0000

Hello Erik,

On 2014/05/07 09:14, Erik Wilde wrote:
> hello.
>
> http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data
> Platform") is a current W3C document in last call WD status, and it
> introduces/uses the Accept-Post header field proposed in a current draft:
>
> http://tools.ietf.org/html/draft-wilde-accept-post
>
> we have publicized this proposed header field on this list, and the
> latest draft also includes a list of known implementations of this
> header field:
>
> http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6

What's the intent behind "Feature at Risk" box? I can see two reasons 
for this: a) trying to be really good citizens, and not going ahead with 
something that's not properly registered; and b) not being confident 
that this is a good idea.

If it's the former, than see below.

> after making the specification available for a while, and listing known
> implementations, we are wondering about next steps. what it would take
> to get this draft moving towards an experimental RFC (apart from some
> references that will need to be updated).

Why experimental? Why not standards track?

An alternative would be to do a provisional registration, because this 
doesn't need an RFC. That would give you some slack for moving ahead 
with the Linked Data Platform spec without being at the mercy of a 
potentially low level of interest in the IETF.

With respect to the draft itself, I don't see a registration template.

Regards,   Martin.