Rahul Gupta

This is me being through and transparent. The entire paragraph is: *Due to the limits on connections per domain, the Per Resource Events Protocol is not suitable for use with...

@csarven Thanks for bringing your wealth of knowledge about Solid to provide this historic retrospective. I have also updated the topmost comment to explain the reason we need another notifications...

I read the cited issue/comment. I think there is typo in the PATCH table, it should be 200 and 201 for exists and not exists respectively, just like the PUT...

Thanks for the clarification @csarven! I stand corrected then... So my trouble is this: when I am watching a container C/ for notifications, I am at present using status codes...

Maybe one more clarification for this, if the resource is configured such that the user-agent had read access, would at least in those cases 201 be the appropriate code?

@bourgeoa Excuse my ignorance, but what is WHERE?

@bourgeoa Given that all resources that are being PATCHed on NSS will necessarily have read access on them and @csarven agrees that 201 is an acceptable response in those case,...

@michielbdejong opened PR on the specific branch. Please review and merge! I am not sure if I can trigger a test without the PR!

@elf-Pavlik HTTP Semantics compliance is not an issue with this PR. From that point, this PR is OK! "Last-modified" is problematic in the context of Containment Triples, but that is...

While it is ok to have "Last-Modified" header as a MUST for consistency and historicity, my 2 cents is that the 1 second resolution makes it pretty useless for _"harder,...