Subject: Fwd: New Version Notification for draft-snell-search-method-02.txt

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2020 06:00:40 +0200

(FYI)

-------- Weitergeleitete Nachricht --------
Betreff: New Version Notification for draft-snell-search-method-02.txt
Datum: Wed, 02 Sep 2020 04:00:11 -0700
Von: [email-masked]
An: Ashok Malhotra <[email-masked]>, James Snell
<[email-masked]>, James M Snell <[email-masked]>, Julian Reschke
<[email-masked]>

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Sep 2020 14:52:25 +1000

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 <[email-masked]> wrote:
> 
> (FYI)
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2020 09:08:11 +0200

Am 03.09.2020 um 06:52 schrieb Mark Nottingham:
> ...

I believe it would be good if we had a concrete proposal for people who
are asking for a safe method that carries a payload.

The draft currently is minimal in that it re-uses an existing method,
making it more generic (which seems to be good in general).

Best regards, Julian

---

From: Roberto Polli <[email-masked]>
Date: Thu, 3 Sep 2020 10:57:59 +0200

Il giorno gio 3 set 2020 alle ore 09:11 Julian Reschke
<[email-masked]> ha scritto:
> > ... draft-snell-search-method-02.txt ..
1- I like the general idea;
2- such a feature is useful;
3- implying that an xml payload must return a webdav response can
limit its adoption or foster non-compliant implementation (Eg. xml
requests returning non-webdav responses). This will happen unless  we
revise https://tools.ietf.org/html/rfc5323, which is widely deployed.
While I'm no fan of xml, this is quite a limitation.

```
for backwards compatibility with existing WebDAV
   implementations, SEARCH requests that use the text/xml or
   application/xml content types MUST be processed per the requirements
   established by [RFC5323].
```

If somebody prefer to use an alternative method name, we could pick
QUERY or FIND https://www.w3.org/2012/ldp/wiki/Proposal_for_HTTP_QUERY_Verb
Once we agree on the semantics, the name can be anything.

My2¢,
R.

-- 
Roberto Polli
Full Stack Developer
M. +39 3406522736
MID
DIPARTIMENTO PER LA
TRASFORMAZIONE
DIGITALE
Presidenza del Consiglio dei Ministri - Ministro per l'innovazione
tecnologica e la digitalizzazione
teamdigitale.governo.it

Il Dipartimento per la Trasformazione Digitale, salvo eccezioni,
comunica con le altre Amministrazioni via posta elettronica ordinaria
e non posta elettronica certificata, in conformità a quanto previsto
dall’art.47 del Codice dell’Amministrazione Digitale.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Sep 2020 11:04:16 +0200

> Once we agree on the semantics, the name can be anything.

RFC 8132 calls it FETCH.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2020 11:24:49 +0200

>     established by [RFC5323].

That's a detail we can work on; I believe this can be relaxed: we can
make it depend on the namespace of the root element (or even the
concrete element name; see
<https://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.2.2.2.p.2>).

> Once we agree on the semantics, the name can be anything.

Once again, the benefit of using an existing name is that there's
already code out there which knows about the method being safe...

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 3 Sep 2020 11:37:15 +0200 (CEST)

On Thu, 3 Sep 2020, Julian Reschke wrote:

>From the Introduction:

>   o  Query expressions included within a request URI must either be
>      restricted to relatively simple key value pairs or encoded such
>      that the query can be safely represented in the limited character-
>      set allowed by URL standards.

This last line is the only place in the document that uses the term "URL". The 
first line of the sentence uses "URI" though. Intentional?

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2020 11:41:46 +0200

Am 03.09.2020 um 11:37 schrieb Daniel Stenberg:
> This last line is the only place in the document that uses the term
> "URL". The first line of the sentence uses "URI" though. Intentional?

Good catch. I don't believe this is intentional :-) (James?)

That said, let's first discuss whether this is something for this WG to
pick up...

Best regards, Julian

---

From: Roberto Polli <[email-masked]>
Date: Thu, 3 Sep 2020 12:59:05 +0200

Il giorno gio 3 set 2020 alle ore 11:43 Julian Reschke
<[email-masked]> ha scritto:
>> .. [ text/xml requests imply webdav responses] ...
> That's a detail we can work on
>  let's first discuss whether this is something for this WG to
> pick up...
If Julian says it's workable, I'm ok :)

My2¢,
R.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 3 Sep 2020 09:04:25 -0700

> On Sep 3, 2020, at 1:57 AM, Roberto Polli <[email-masked]> wrote:
> 

Note that is triggered by the media types, not the data format.

I don't see that as a limitation at all. Those general types don't
say anything useful for the recipient. That's why applications of XML
are supposed to use a more specific +xml media type instead, and we
can require that of future implementations without hindering XML as
a payload.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2020 19:09:01 +0200

Am 03.09.2020 um 18:04 schrieb Roy T. Fielding:
> ... > Note that is triggered by the media types, not the data format.
>

Right.

Payloads in WebDAV regrettably use application/xml (or text/xml). That's
hard to change now, but I'm tempted to register several more specific
types for future use cases (like linking to a PROPFIND payload).

Best regards, Julian

---

From: Austin Wright <[email-masked]>
Date: Thu, 3 Sep 2020 17:09:06 -0700

I have three suggestions, in this order:

(1) Why not adopt the REPORT method? It seems to be defined with neutral semantics, or at least more neutral than SEARCH:

> A REPORT request is an extensible mechanism for obtaining information about a resource.

This definition sounds like a query, and I like the name: it suggests you’ll provide or receive some sort of report, generated by the server based on the payload.

(2) If we mint a new HTTP method, I favor QUERY.

(3) I’m not opposed to SEARCH, I figure the worst that could possibly happen would be some legacy Java app sees "Allow: SEARCH" and makes a WebDAV query to the resource, triggering an uncaught error due to the unexpected response, causing an infinite loop and overheating the CPU, setting everything on fire.

What I don’t like very much is the name. SEARCH suggests something very specific to me. I think of PATCH, a method where only certain media types make sense.

Austin Wright.

> On Sep 3, 2020, at 10:09, Julian Reschke <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Sep 2020 07:20:20 +0200

>> A REPORT request is an extensible mechanism for obtaining information about a resource.

That's indeed a potential alternative, but the difference is quite minor
(in the prose describing the payload).

Best regards, Julian

---

From: Philippe Mougin <[email-masked]>
Date: Tue, 8 Sep 2020 15:23:16 +0200

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 <[email-masked]> a écrit :
> 
> Everyone -
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 9 Sep 2020 14:03:39 +0200

> As discussed a while back, I see a few problems in the draft.

FWIW, the dicussion we should have *right now* is whether the WG wants
to work on this general topic, not the details of the current proposal.

If this draft is adopted as work item, the WG will continue to modifiy
the proposal until we have (potentially rough) consensus on it.

That said...

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

You may call that "recasting as RPC", but that's *exactly* what people
are asking for. Keep in mind that in practice the only difference to GET
with query parameters is that the query is in the payload, not in the
URI. We can sure word smith this some more, but this really is what this
topic is about.

> 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 sear…

In theory, yes. In practice of course *most* of the time there *is* a
resource identified by "http://example.org/feed", and it does indeed
process the query parameters.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Sep 2020 12:10:09 +0200

> What do people think about it -- is it worthwhile? Are there any problems? Consider this a prelude to a CfA...

I believe we should have a document that adresses the need of a safe
method with payload.

SEARCH is a good candidate, and I volunteer to edit/co-edit (and
potentially address the compatibility with WebDAV SEARCH).

I would recommend not to start actual work before we do the WG LC on the
new core specs, though.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 12 Sep 2020 13:13:00 +1200

On 11/09/20 10:10 pm, Julian Reschke wrote:
>>  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.
>>
>> What do people think about it -- is it worthwhile? Are there any
>> problems? Consider this a prelude to a CfA...
>>
>> Cheers,
>> ...
> 

Looking through the draft for SEARCH it appears to me that the intended
use makes responses to it effectively non-cacheable by default. The
requirement not to invalidate previous responses does not help with that
- just confuses things further.

There is also the need for an Accept-Search mechanism to negotiate its
use. If negotiation is needed, then are we perhapse better off instead
negotiating the fact that GET payload is usable?

Would a hop-by-hop header that allowed a server to inform a client how
many bytes of GET payload it will accept can resolve these use cases?

Amos

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Sep 2020 10:06:59 +0200

> negotiating the fact that GET payload is usable?

I don't think that negotiation is stricly needed.

> many bytes of GET payload it will accept can resolve these use cases?

That would require every hop to support that new signal, right?

...I am skeptical about GET-with-payload, considering the known interop
issues and the fact that we've been telling people for years not to try
it. *If* we can make it work without touching too many components, that
would be interesting. But can we?

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 15 Sep 2020 09:32:05 +1200

> I don't think that negotiation is stricly needed.

There is no implicit default content-type documented. Just the
Accept-Search header to negotiate one, and a passing reference to extra
requirements when XML is used.

> would be interesting. But can we?

I think this is the only way GET-with-payload would actually work
reliably while those known issues exist. Origin that support it sending
the header and middleware that don't dropping the header. So clients
receiving the header know they can use GET payloads.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Sep 2020 05:46:46 +0200

> requirements when XML is used.

Well, there is no negotiation for POST either (except for returning 406,
which will work here as well). Where's the difference?

> receiving the header know they can use GET payloads.

So we would need to modify intermediaries and software components. I
believe this is a non-starter.

Best regards, Julian

---

From: Roberto Polli <[email-masked]>
Date: Tue, 15 Sep 2020 11:31:36 +0200

Hi all,

I just noted I replied to Amos without CC the ML.

> >> I don't think that negotiation is stricly needed.
+1

> >>> If negotiation is needed, then are we perhapse better off instead
In my experience, servers use GET when they don't want to process
payload and manage the burdens of receiving it.
Sometimes they interpret GET with payload as potentially harmful
requests and act accordingly (eg. blocking/dropping the request).

imho using a different method makes it easy to isolate cacheable and
constrained GET requests from other - more complex - endpoints
accepting a payload body and
which are subject to more complex security concerns.

> believe this is a non-starter.
+1

My2¢,
R.

-- 
Roberto Polli
API Expert
M. +39 3406522736
MID
DIPARTIMENTO PER LA
TRASFORMAZIONE
DIGITALE
Presidenza del Consiglio dei Ministri - Ministro per l'innovazione
tecnologica e la digitalizzazione
https://innovazione.gov.it/