- From: Philippe Mougin <pmougin@acm.org>
- Date: Tue, 8 Sep 2020 15:23:16 +0200
- To: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Philippe Mougin <pmougin@acm.org>
As discussed a while back, I see a few problems in the draft. It states "The path identifies the resource processing the query (in this case 'http://example.org/feed') while the query identifies the specific parameters of the search operation". This recasts the Web model into an RPC-like system where the http://example.org/feed resource is some software we send parameters to in order for it to perform a search. But actually there is no such resource involved. The resource involved is http://example.org/feed?q=foo&limit=10&sort=-published; it will typically be defined as being the result of a specific search computation. This is one of the distinctive feature of the Web: the ability to define ressources as results of some computations and to perform these computations only when a client GET the representations of these resources. This has numerous implications such as the existence of a generic retrieval method, the ability to link to results of computations without actually performing the computations, and the ability to support caching of computations' results. This is why a sensible description of GET should not recast it as mere RPC, I'd suggest. Another problem is that the second part of the introduction then went on contradicting the first part as it states "Encoding query parameters directly into the request URI effectively casts every possible combination of query inputs as distinct resources". Besides, it identifies it as a disadvantage. Best, Philippe Mougin > Le 3 sept. 2020 à 06:56, Mark Nottingham <mnot@mnot.net> a écrit : > > Everyone - > > From what I can see, we last talked about this draft at IETF93, in 2015. There, we considered issuing a Call for Adoption, but that didn't ever happen. > > I've seen continued interest in it from a variety of people (mostly outside the WG). > > What do people think about it -- is it worthwhile? Are there any problems? Consider this a prelude to a CfA... > > Cheers, > > >> On 3 Sep 2020, at 2:00 pm, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> (FYI) >> >> >> -------- Weitergeleitete Nachricht -------- >> Betreff: New Version Notification for draft-snell-search-method-02.txt >> Datum: Wed, 02 Sep 2020 04:00:11 -0700 >> Von: internet-drafts@ietf.org >> An: Ashok Malhotra <malhotrasahib@gmail.com>, James Snell >> <jasnell@gmail.com>, James M Snell <jasnell@gmail.com>, Julian Reschke >> <julian.reschke@greenbytes.de> >> >> >> A new version of I-D, draft-snell-search-method-02.txt >> has been successfully submitted by Julian Reschke and posted to the >> IETF repository. >> >> Name: draft-snell-search-method >> Revision: 02 >> Title: HTTP SEARCH Method >> Document date: 2020-09-02 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-snell-search-method-02.txt >> Status: https://datatracker.ietf.org/doc/draft-snell-search-method/ >> Htmlized: https://tools.ietf.org/html/draft-snell-search-method-02 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-snell-search-method >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-snell-search-method-02 >> >> Abstract: >> This specification updates the definition and semantics of the HTTP >> SEARCH request method originally defined by RFC 5323. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> > > -- > Mark Nottingham https://www.mnot.net/ > >
Received on Tuesday, 8 September 2020 13:24:31 UTC