Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-patch-status-00.txt

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Mar 2014 16:55:45 +1100

This is just a bit of a thought experiment, would be interested to hear reactions.

Cheers,

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-http-patch-status-00.txt
> Date: 14 March 2014 4:53:14 pm AEDT
> To: "Mark Nottingham" <[email-masked]>, Mark Nottingham <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-http-patch-status-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-http-patch-status
> Revision:	00
> Title:		The 2NN Patch HTTP Status Code
> Document date:	2014-03-14
> Group:		Individual Submission
> Pages:		8
> URL:            http://www.ietf.org/internet-drafts/draft-nottingham-http-patch-status-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-http-patch-status/
> Htmlized:       http://tools.ietf.org/html/draft-nottingham-http-patch-status-00
> 
> 
> Abstract:
>   This document specifies the 2NN Patch HTTP status code to allow
>   servers to perform partial updates of stored responses in client
>   caches.
> 
> 
> 
> 
> 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   http://www.mnot.net/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 14 Mar 2014 16:35:23 +0900

Hello Mark,

> This is just a bit of a thought experiment, would be interested to hear reactions.

A very nice thought experiment indeed, and hopefully soon more than just 
that.

In connection with a Master Thesis (*) here at my Lab where we looked at 
the gaps between REST and Websockets (and by extension, AJAX and similar 
stuff), I have been thinking about how to better integrate patching into 
HTTP (in particular also the push stuff in HTTP2, which you mention in 
Appendix A).

(*) by Shouhei ISHIHATA, in Japanese, sorry.

So here are my comments:
(please separate threads in replies where appropriate)

TODO: is this a 2NN or 3xx?: I'd tend to 2NN. It's definitely success in 
the sense that it's what the client was asking for. We also have 206 
Partial Content, and a patch is partial content, too. Also, the URI 
stays the same, which isn't usually what happens for a 3XX. And there's 
no followup request. But see also below.

Accept-Patch header field: This seems to indicate two things, namely 1) 
the client supports 2NN patching, and 2) the patch formats the client 
can handle. I was just thinking: why not put 2) into the good old Accept 
header field? It would be something like:
Accept: application/json, application/patch+json
which just says: You can send me the full format, or a patch. If we 
wanted to get rid completely of the Accept-Patch header field, we still 
would need some kind of client capability announcement. Or create a 
registry that identifies certain content types as patches (but then 
patches can be resources in their own right, too). Just thinking out 
loud (and written before discovering that Accept-Patch is already 
defined for responses in RFC 5789).

Server capability: How can a server say that it is able to send 
patches/that a certain resource can send patches? Clients may not want 
to send additional headers if they are not sure the server/resource will 
handle it. What's the best way to get over the chicken and egg problem?

Entity tags: Is this the only way to identify versions? Wouldn't the 
dates in If-Modified-Since work, too? Why are there two etags in your 
example (If-None-Match: "abcdef", "ghijkl")? Is this just to show that 
more than one etag is okay? Or is there an expectation that the client 
send as many as possible in the hope the server has a patch for one of 
them? Presumably the client got both "abcdef" and "ghijkl" from the same 
origin, and the origin should have patches available between any two 
versions, and the later the base version for the patch, the easier for 
the server.

    In particular, the stored response to apply a 2NN (Patch) response to
    is the same; if none is selected, the patch fails, and the client MAY
    resubmit the request without an Accept-Patch header field, in order
    to get a full response.
Why would the client send an Accept-Patch header field if it doesn't 
have something to apply the patch to?

 >>>>                                               However, the
       following fields MUST not be updated: Content-Type, Patched.
Re. Content-Type: I guess the idea of having a 'patch' that converts 
from one content-type to another is rather crazy, but couldn't it be 
that an application/patch+json converts from application/abc+json to 
application/def+json if these two are rather close?
Re. Patched: shouldn't you say that the field MUST NOT be created? 
(rather than MUST not be updated). Also, is Patched: the right header 
field name? What about Patches:? "This patches version ghijkl" and not 
"this pached version ghijkl" is certainly how I'd informally read
Patched: "ghijkl"

IANA considerations: "which ought to be reflected in the registry.": Why 
not just write "please add to the registry"?

In the Master Thesis that I mentioned above, we looked at how to reflect 
updates via WebSocket in sequences of URIs. The main example we used was 
an interactive board game. The states after each move were represented 
as something like http://play.game.org/games/nnnnn?move=nn. Changes such 
as moves by the remote player, from e.g. 
http://play.game.org/games/nnnnn?move=22 to 
http://play.game.org/games/nnnnn?move=23, were handled in code. Of 
course the differences between two board states can be expressed as a 
patch, but it would then be interesting to have something roughly like:

        GET http://play.game.org/games/nnnnn?move=22 HTTP/1.1
        Host: api.example.com
        Accept-Patch: application/patch+json
        User-Agent: Example/1.0
(request implicit because assuming HTTP2 push)

        HTTP/1.1 2NN Patch
        Content-Type: application/patch+json
        Content-Location: http://play.game.org/games/nnnnn?move=23
Content-Location here is (mis?)used to indicate that the patch creates 
the representation of a new resource, rather than updating the current 
resource. Does at least the idea behind this make sense? In this case, 
maybe a 3NN is better than a 2NN.

Related to the above, both this draft as well as HTTP2 push uses the 
word "cache" a lot, sometimes exclusively. While cache updates are 
clearly a prime target for patching and pushing, in interactive 
applications the data should reach the final user agent and the screen. 
Any problems with keeping the language a bit more general?

Regards,   Martin.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 Mar 2014 07:12:11 +1100

Hi Martin!

Thanks for the feedback. Responses below.

On 14 Mar 2014, at 6:35 pm, Martin J. Dürst <[email-masked]> wrote:

> A very nice thought experiment indeed, and hopefully soon more than just that.
> 
> 
> In connection with a Master Thesis (*) here at my Lab where we looked at the gaps between REST and Websockets (and by extension, AJAX and similar stuff), I have been thinking about how to better integrate patching into HTTP (in particular also the push stuff in HTTP2, which you mention in Appendix A).
> 
> TODO: is this a 2NN or 3xx?: I'd tend to 2NN. It's definitely success in the sense that it's what the client was asking for. We also have 206 Partial Content, and a patch is partial content, too. Also, the URI stays the same, which isn't usually what happens for a 3XX. And there's no followup request. But see also below.

That was my thinking too, although a 3xx doesn’t *have* to change the URI or have a followup request; 3xx really means “get it somewhere else”, e.g., 304 means “get it from your cache.". Sometimes the status code class is a bit arbitrary...

> Accept-Patch header field: This seems to indicate two things, namely 1) the client supports 2NN patching, and 2) the patch formats the client can handle. I was just thinking: why not put 2) into the good old Accept header field? It would be something like:
> which just says: You can send me the full format, or a patch. If we wanted to get rid completely of the Accept-Patch header field, we still would need some kind of client capability announcement. Or create a registry that identifies certain content types as patches (but then patches can be resources in their own right, too). Just thinking out loud (and written before discovering that Accept-Patch is already defined for responses in RFC 5789).

That would be Bad, because it would make it hard to talk about the difference between downloading a patch file on its own right, as a 200 response, vs. being able to apply it.

> Server capability: How can a server say that it is able to send patches/that a certain resource can send patches? Clients may not want to send additional headers if they are not sure the server/resource will handle it. What's the best way to get over the chicken and egg problem?

This comes up in many different contexts. There have been proposals in the past to address this kind of discovery (e.g., <https://datatracker.ietf.org/doc/draft-nottingham-http-browser-hints/>), but for various reasons they haven’t caught on with browsers. With HTTP/2 coming, the overhead of sending an extra request header is significantly lower, so there will be even less reason to do discovery soon...

> Entity tags: Is this the only way to identify versions? Wouldn't the dates in If-Modified-Since work, too?

They’re weak validators, so that’s a bit risky. I haven’t talked about ETag strength yet, but probably should (along the same lines that partial content responses do).

> Why are there two etags in your example (If-None-Match: "abcdef", "ghijkl")? Is this just to show that more than one etag is okay?

Yes.

> Or is there an expectation that the client send as many as possible in the hope the server has a patch for one of them?

Yes. :) 

> Presumably the client got both "abcdef" and "ghijkl" from the same origin, and the origin should have patches available between any two versions, and the later the base version for the patch, the easier for the server.
> 
> 
> >>>>
> Why would the client send an Accept-Patch header field if it doesn't have something to apply the patch to?

It might have one or more things that the patch *might* apply to, but the response fails through the selection algorithm.

> Re. Content-Type: I guess the idea of having a 'patch' that converts from one content-type to another is rather crazy, but couldn't it be that an application/patch+json converts from application/abc+json to application/def+json if these two are rather close?

No, that’s not crazy; patch formats that operate on headers have been discussed (but not yet minted). I think the current text allows this, in that it says “after applying the patch format…"

> Re. Patched: shouldn't you say that the field MUST NOT be created? (rather than MUST not be updated). Also, is Patched: the right header field name? What about Patches:? "This patches version ghijkl" and not "this pached version ghijkl" is certainly how I'd informally read
> Patched: “ghijkl"

Will adjust. I like Patches...

> IANA considerations: "which ought to be reflected in the registry.": Why not just write "please add to the registry”?

Thank you for the wordsmithing :)

> In the Master Thesis that I mentioned above, we looked at how to reflect updates via WebSocket in sequences of URIs. The main example we used was an interactive board game. The states after each move were represented as something like http://play.game.org/games/nnnnn?move=nn. Changes such as moves by the remote player, from e.g. http://play.game.org/games/nnnnn?move=22 to http://play.game.org/games/nnnnn?move=23, were handled in code. Of course the differences between two board states can be expressed as a patch, but it would then be interesting to have something roughly like:
> 
> Content-Location here is (mis?)used to indicate that the patch creates the representation of a new resource, rather than updating the current resource. Does at least the idea behind this make sense? In this case, maybe a 3NN is better than a 2NN.

Hmm, not sure. Would have to work through it in detail, I suspect.

> 
> 
> Related to the above, both this draft as well as HTTP2 push uses the word "cache" a lot, sometimes exclusively. While cache updates are clearly a prime target for patching and pushing, in interactive applications the data should reach the final user agent and the screen. Any problems with keeping the language a bit more general?

I think it can probably move to “stored response” more; usually it will be in a cache, but it doesn’t have to be.

Cheers, and thanks again!