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

Erik Wilde <dret@berkeley.edu> Wed, 07 May 2014 02:12 UTC

Return-Path: <dret@berkeley.edu>
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 00DAE1A04BA for <apps-discuss@ietfa.amsl.com>; Tue, 6 May 2014 19:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level:
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 04e_BHY2-I6A for <apps-discuss@ietfa.amsl.com>; Tue, 6 May 2014 19:12:06 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1D1A0304 for <apps-discuss@ietf.org>; Tue, 6 May 2014 19:12:06 -0700 (PDT)
Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66] helo=[192.168.1.76]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1WhrKx-0007uS-Iu; Tue, 06 May 2014 19:12:01 -0700
Message-ID: <5369966C.2000408@berkeley.edu>
Date: Tue, 06 May 2014 19:11:56 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>, "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
References: <53697AD6.2030504@berkeley.edu> <5369822F.3080401@it.aoyama.ac.jp>
In-Reply-To: <5369822F.3080401@it.aoyama.ac.jp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0ixTBJUi-oq_2hlB_oznNXZsOQY
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 02:12:11 -0000

hello martin.

thanks a lot for the feedback!

On 2014-05-06, 17:45 , "Martin J. Dürst" wrote:
>> 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.

it's a), because of the timing issues involved with working on these two 
documents in W3C- and IETF-land.

>> 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?

it could be either way, i don't think we have a strong opinion about 
that. it seems to me that there are different opinions when to use what, 
but if standards track is a better fit, that's fine with us.

> 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.

thanks for pointing that out. i guess if we are not making progress with 
the draft, then that would be a way to go for us. for now, maybe there 
is enough interest to move forward with the current approach.

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

that would be a template according to RFC 3864? good point, i will add 
that to 
https://github.com/dret/I-D/blob/master/accept-post/draft-wilde-accept-post-03.xml

thanks and cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |