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

[Mark Nottingham <[e-mail]>]

Hi Martin!

Thanks for the feedback. Responses below.


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

> Hello Mark,
> 
> On 2014/03/14 14:55, Mark Nottingham wrote:
>> 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.

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

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

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


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

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

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!


> 
> 
> Regards,   Martin.
> 
> 
>> Cheers,
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: [e-mail]
>>> Subject: New Version Notification for draft-nottingham-http-patch-status-00.txt
>>> Date: 14 March 2014 4:53:14 pm AEDT
>>> To: "Mark Nottingham" <[e-mail]>, Mark Nottingham <[e-mail]>
>>> 
>>> 
>>> 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/
>> 
>> 
>> 
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 

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