Re: [apps-discuss] Fwd: New Version Notification for draft-wilde-accept-post-01.txt
Erik Wilde <dret@berkeley.edu> Mon, 09 September 2013 19:10 UTC
Return-Path: <dret@berkeley.edu>
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 84B1121F9FBC for <apps-discuss@ietfa.amsl.com>; Mon, 9 Sep 2013 12:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 PQVP1CEBECFQ for <apps-discuss@ietfa.amsl.com>; Mon, 9 Sep 2013 12:10:49 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2623421F9D7A for <apps-discuss@ietf.org>; Mon, 9 Sep 2013 12:10:49 -0700 (PDT)
Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretpro.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1VJ6rG-0003SS-It; Mon, 09 Sep 2013 12:10:48 -0700
Message-ID: <522E1D37.1030602@berkeley.edu>
Date: Mon, 09 Sep 2013 12:10:47 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
References: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> <522A8845.6060709@berkeley.edu> <CABkgnnV_9ErXuwd4LYy=LYaLuaQVrHtnWox-PH9h03Tz89x9uA@mail.gmail.com> <CABP7RbdMWgDO3ixQopv4SJovqW6XQ6Jy9Te4BRCbPSoKctxGHw@mail.gmail.com>
In-Reply-To: <CABP7RbdMWgDO3ixQopv4SJovqW6XQ6Jy9Te4BRCbPSoKctxGHw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-wilde-accept-post-01.txt
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: Mon, 09 Sep 2013 19:10:53 -0000
hello. On 2013-09-09 11:50 , James M Snell wrote: > An Accept-Put (or Accept-{whatever}) would be useful if and only if > there are practical known use cases where we know they'd be used. The > two we currently have (Accept-Patch and Accept-Post) have very clear, > specific real world use cases that solve immediate non-theoretical > needs. If someone eventually finds need for Accept-Put, they can > easily draft up a quick I-D that defines it :-) > On Mon, Sep 9, 2013 at 11:42 AM, Martin Thomson > <martin.thomson@gmail.com> wrote: >> Apologies if I missed an earlier discussion, but why is this >> restricted specifically to POST requests? Is there value in also >> having Accept-Put (useful if the resource can be retrieved in multiple >> forms, but only uploaded in a subset of those, such that it is >> difficult to learn what types are acceptable), as well as Accept-Blah, >> for any future method that contains a body or any request that might >> return 415? james' response is right along the lines what i would say. you might be able to come up with a model for an Accept-AnyMethod field, but it would necessarily be more complicated. and not that this proves anything, but link hints as they are defined in the current draft support method-specific hints such as accept-post: http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.4 when we (the W3C LDP WG) came up with Accept-Post, we followed the model of Accept-Patch, which already exists as a registered header field: http://tools.ietf.org/html/rfc5789#section-4.1 personally, i don't think there's a functional difference between what you can do with method-specific fields, or with one field that openly covers all methods. the reasons for doing it per method include: - there is precedent (Accept-Patch) - link hints currently follow the same method-specific model. - the "content model" is simpler than for a more general header field. the preference of the LDP WG of course is to follow the path we're proposing, also because we already have implementations using it: http://tools.ietf.org/html/draft-wilde-accept-post-01#section-6 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 |
- [apps-discuss] Fwd: New Version Notification for … Erik Wilde
- Re: [apps-discuss] Fwd: New Version Notification … Martin Thomson
- Re: [apps-discuss] Fwd: New Version Notification … James M Snell
- Re: [apps-discuss] Fwd: New Version Notification … Erik Wilde
- Re: [apps-discuss] Fwd: New Version Notification … Martin Thomson