Add Inbox Discovery on Client Error #253
Conversation
| <ul> | ||
| <li>use the <code>Link</code> header with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#inbox</code>.</li> | ||
| <li>parse an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/ldp#inbox</code>. The subject of that relation is target and the object is the Inbox.</li> | ||
| </ul> |
There was a problem hiding this comment.
This passage seems to just repeat the previous one from the client's perspective. I think the client's perspective should not be limited to parsing the content, but what it can do with the given content.
There was a problem hiding this comment.
Also I guess that the LDN spec says everything there is to be said about LDN in other documents. We seem to be considering 40x return codes especially here and the meaning of an LDN in that situation.
I am not sure why one needs the complexity of adding content to the 401 at this point.
There was a problem hiding this comment.
The intention is to discover the Inbox. Assuming that if an implementation didn't want to send a notification towards resolving the error, it wouldn't bother to get a hold of the Inbox (where available).
The intention to send a notification is a separate step that needs to incorporate additional context - intentionally not specified here to keep the protocol flexible - and the requirement for Sender is already defined.
An application can have multiple roles.
| @@ -688,6 +688,29 @@ <h2 property="schema:name">Notifications</h2> | |||
| <p>A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p> | |||
There was a problem hiding this comment.
"by implementing the Receiver part" - the receiver part of the spec I guess. It's a bit oddly phrased.
Can on not just say: A Solid server must have an ldn:inbox to which notifications can be sent?
"And make inbox content available" - To whom?
There was a problem hiding this comment.
Happy to revise outside of this PR, but just to respond:
It is not that "a Solid server must have an ldn:inbox.." but that server needs to conform to LDN's requirements (receiver) for inbox resources.
There was a problem hiding this comment.
I am happy with this introspection pattern for enabling User Agents deduce the locations of special resources e.g., inbox folders.
Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com>
Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com>
Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com>
Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com>
| <ul> | ||
| <li>Include the <code>Link</code> header with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#inbox</code>.</li> | ||
| <li>Return an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/ldp#inbox</code>. The subject of that relation is the target resource and the object is the Inbox.</li> | ||
| </ul> |
There was a problem hiding this comment.
I still think that "the subject of the relation is the target resource" is confusing, because a relation can be thought of as an arrow, and the target of an arrow is the object of the arrow. So I think one should say "the subject of the relation is the resource which returned the error message" or something along those lines.
There was a problem hiding this comment.
I like the use of "target resource" as standard terminology across the protocol spec.
Do you think that maybe we should add it to the definitions https://solidproject.org/TR/protocol#definitions to make it explicit?
There was a problem hiding this comment.
"Target resource" is borrowed from RFC 7231, and I prefer not to add it to Protocol's definitions. The effective request URI (RFC 7230) is the reconstructed value of the HTTP request-target. The subject of the relation is same as the effective request URI. I've considered using effective request URI but figured that "target resource" was more readable - also stays close to LDN use.
I'm open to using effective request URI or possibly even Request-URI (LDP terminology) but didn't want to associate the subject URI close to the "request". LDN uses target resource to refer to the entity with an inbox.
There was a problem hiding this comment.
The problem is that you can standardize meanings in a spec for that spec, but not across specs. If you have a spec that very clearly has a subject and a target then you can define the meaning of target. But otherwise it is a relational term, and you here have two resources that are targets here. The 401 resource which is a target of the initial request and the inbox which is the target of the following request.
To make matters worse, you are discussing both at the same time in these paragraphs.
There was a problem hiding this comment.
This is not discussing inbox as the target of the following request.
Target is only mentioned in context of an entity with an inbox (equivalent to request-target in context of the subject of the relation) - which is what LDN says.
| <li>Return an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/ldp#inbox</code>. The subject of that relation is the target resource and the object is the Inbox.</li> | ||
| </ul> | ||
|
|
||
| <p>Senders do the following to discover the Inbox URL in an HTTP response with a <code>4xx</code> status code:</p> |
There was a problem hiding this comment.
I think the terminology of "Sender" comes from the LDN spec. Here have a client that received the 40x and suddenly turns into a "Sender". But the web server also was a Sender of the 40x resource. So it is confusing here. Instead of reifying roles like this one should continue to speak of the client that receives the 40x and wishes to send a notification to the inbox.
There was a problem hiding this comment.
I think I would use "Solid Clients" instead of "Senders" here and "Solid Servers" instead of "Servers" on line 697, for consistency.
It would be less confusing and more consistent terminology usage.
There was a problem hiding this comment.
This is partly the reason why I mentioned where these requirements can live ie. in Solid Protocol or LDNx or whatever.
The terminology is indeed based off LDN because the roles have intention. Neither is it true that any of these roles require a full blown LDP/Solid servers or applications. Minimum requirement for interop is what's expected from conforming classes (roles) of LDN.
Here have a client that received the 40x and suddenly turns into a "Sender"
A client may be requesting on behalf of an application implementing the "Sender" (eg. POST /bar/ ) or a "Consumer" (eg. GET /foo) roles. The client in and itself doesn't have any idea about "notifications". Only an application that's interested in sending a notification cares about the inbox.
But the web server also was a Sender of the 40x resource.
client that receives the 40x and wishes to send a notification to the inbox.
I would use "Solid Clients" instead of "Senders" here and "Solid Servers" instead of "Servers"
That's inaccurate. A server is not "sending" as an "LDN Sender". Server is just responding to the request here about a target resource. A target resource that wants advertise an inbox only needs to conform to LDN's requirements. It doesn't need to do anything else.
Having said that, I'm generally fine to switch from LDN terminology to using Solid-specific terminology but the intention with this section wasn't to tightly couple it with Solid.
There was a problem hiding this comment.
That's inaccurate. A server is not "sending" as an "LDN Sender".
Sorry, I think I have been a bit unclear. I am not suggesting to say Sender instead of Server.
As I understand from https://www.w3.org/TR/ldn/#abstract, if keeping the LDN terminology, I would:
- Change line #697 "Servers who want to advertise the Inbox URL" to "Receivers who want to advertise the Inbox URL".
- Change line #704 "Senders do the following to discover the Inbox URL" to "Senders and Consumers do the following to discover the Inbox URL".
If adopting the Solid terminology, I would switch to "Solid Clients" for line 697 and "Solid Servers" for line 704.
I am not sure which of the two options is the best, but given the context (solid protocol spec), I would probably switch to the Solid terminology.
There was a problem hiding this comment.
There are too many roles at play here. I would just stick to client and 40x resource, and explain everything in those terms. No need to bring in vocabulary from other specs. The reader should not have to read those specs to understand what is going on, as it is pretty simple.
Instead of
Senders do the following to discover the Inbox URL in an HTTP response with a
4xxstatus code:
write
A client wanting to POST a request for access can find the inbox by looking for a Link header with relation ldp:inbox in the returned response.
There was a problem hiding this comment.
Receivers who want to advertise the Inbox URL.
No. Receiver is not responsible of the target resource or has anything to do with advertising target resource's inbox.
Senders and Consumers do the following to discover the Inbox URL
No. Consumer is not relevant here because the context is about sending a notification to an inbox to resolve an error. See #253 (comment)
|
@dmitrizagidulin Nod. Inbox is advertised in context of the error and the Inbox URL can be anywhere. The Inbox URL per request can be different eg. /inbox/{uuid}/) - which is also why LDN starts sender/consumer interactions with the discovery step. Minimum requirement for interop for sender is to use JSON-LD payload and for consumer to read the Inbox and the notifications in JSON-LD. "Solid pod inbox (tm)" - perhaps loosely referred to as an agent's inbox - is LDN inbox ie. a essentially an ldp:Container that can handle JSON-LD and Turtle. |
| @@ -688,6 +688,29 @@ <h2 property="schema:name">Notifications</h2> | |||
| <p>A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p> | |||
There was a problem hiding this comment.
I am happy with this introspection pattern for enabling User Agents deduce the locations of special resources e.g., inbox folders.
|
It does not need a lot to get this through. Just some work on improving the language a little bit. |
| <section id="inbox-discovery-client-error" inlist="" rel="schema:hasPart" resource="#inbox-discovery-client-error"> | ||
| <h3 property="schema:name">Inbox Discovery on Client Error</h3> | ||
| <div datatype="rdf:HTML" property="schema:description"> | ||
| <p>This section extends the LDN protocol to allow the discovery of the Inbox URL of a target resource on client errors (HTTP responses with <code>4xx</code> status codes) [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>][<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p> |
There was a problem hiding this comment.
Perhaps state why that is a problem / issue compared to other responses.
There was a problem hiding this comment.
I find this whole feature couched in language which is obscure and not obvious. I understand that the purpose of this is part of this is to part of an access request protocol. A protocol for the user of the client to request access to be given by the publisher (the user of the server) to a resource for which they get a 403 error from the server.
If that is the case, then we should be explicit. This only applies to 402 Unauthorized, right? Calling it a "client error" isn't very helpful. (400 is definitely a client error, but 403 may be an error on the part of the publisher after all). Can we specify that this inly applied ro 403? Certainly not 400 or 401. And for "402 payment required", you don't want a pointer to a page about payment methods, not an inbox? Suggest make it clear that this is part of a protocol to request access, and couch it in those terms. And put a placeholder to be filled in later for the rest of the protcol. The shape for the request to go into the inbox, (including a response inbox pointer and a text field for reason requested and webid of requester, and wrether write access requested as well as read) , and the shape for teh response. And suggest the property be solid:accessRequetInbox or something. Where looking up that predicate URL will explain the whole protcol to a developer.
|
https://tools.ietf.org/html/rfc7231#section-3.3
Emphasis mine. As mentioned, this can potentially be for any I went with "client error" as per RFC 7231's "Client Error 4xx" ( https://tools.ietf.org/html/rfc7231#section-6.5 ). This PR is strictly about the protocol for discovering the inbox. Not mixing the data shape was completely intentional so that they can be described and evolve elsewhere without interfering with discovery. Just as the LDN protocol called it:
The flows for each case (eg. access request / 403) can be defined/spec'd elsewhere - and we have started on that - with specific notification data/shape.. eg. reusing the well-established and adopted ActivityStreams vocabulary ( https://www.w3.org/TR/activitystreams-vocabulary/ ) - which came out of the Social Web WG - to describe the activity/purpose of the message as a response to "resolving" the error (as the RFC suggests). This also fits well with our intention/consideration to use structured error messages (issue 28). |
|
You meant |
There was a problem hiding this comment.
I'm not sure what to make of this suggestion. On one hand, I appreciate the need to advertize some affordances when returning an error, but OTOH, I'm not sure that an inbox would be a useful thing to discover. Yes, you could send a notification there, but what would that buy you?
I think we might as well close this and see if we can come up with a broader proposal.
|
@kjetilk I'm not sure what to make of your response because there are plethora of links, descriptions and explanations at your disposal connecting the dots. Here is another support; screencast/source for request access public implementation in dokieli (source: linkeddata/dokieli@edd43f7 ) :
|
kjetilk
added
the
status: Nominated
|
I agree with @timbl and @kjetilk here — I'm not sure what sending a notification to an inbox is intended to achieve, and I'm concerned that this could lead to inbox spam by "lazy" application developers just sending all 4xx responses to the Inbox, when instead those errors are most likely the Application Developers' issue, and something that they need to implement UI to handle.
I think perhaps what's more needed is to specify "how an LDN Inbox is created for a WebID / Pod / Resource" and then specify that "the LDN rel linking to the Inbox must always be present if the Resource has an Inbox associated with it" That then allows for this, but doesn't make it the "default error reporting mechanism" for application developers. |
The notification is intended for the attention of the receiver, e.g., 403 -> request access. The screencast demonstrates what it tries to achieve. It is implemented. Source code is public. It is not hypothetical. For the user, it is for example very similar to the process as what is arguably one of the most widely deployed services out there - try accessing a GDoc that you don't have permission to, you can request access, the individuals that own/control the document will get a notification... last I checked.
Not all. Mentioned that in the first comment as to which codes are possibly most suitable. I think the user not having access to some resource and requesting access to it is categorically different than an application developer issue.
If providing agents the ability to manipulate resource headers is a go, sure, I'll embrace that but...
... but separate concerns. And, as stated, this discovery/notification capability doesn't entail that creator/owner of the resource/storage has to provide an inbox for the target resource, or the same inbox in every response, or an inbox on the same server, or anywhere in particular on the Web, or.. |
Right, but at a protocol level, I think we need to be specific — the way this is worded makes it sound like an application developer can / should send all 4xx errors to the linked Inbox, which I think would be fundamentally wrong and create a noise/spam problem.
It is fundamentally a developer issue, if the developer has not handled that error case. The solid spec is very clear that accessing a resource may require authentication or authorization, if an application chooses not to implement UI for that, then that is 100% on the application developer. It would definitely be a bad thing to write the spec saying "Just send something to the resources' inbox if you get a 4xx error", as it shifts responsibility for application or client errors to resource owners or pod servers, when it's really a client application issue: if a client application has a bug, it is up to the developer of that application to handle it.
I think this would be better handled by each of:
In the case of dokie.li, it is the responsibility of Dokieli to handle non-success results when interacting with resources, and to do so in a graceful manner, whether that's showing the user a message, providing UI to send an access request, or UI to authenticate the user if they are not authenticated. Mandating at spec level that there's an inbox for 4xx errors is fundamentally wrong, unless we're more looking at it like reporting CSP errors, in which case, the Inbox IRI would be that of the pod provider. In which case, I'd 100% expect all 4xx errors to return the Inbox of the Application Developer as the Inbox, not that of the Resource Owner or Resource; i.e., "A user of my application encountered an error I did not handle it, therefore I should be notified at [this address] |
|
@ThisIsMissEm I believe the purpose of this proposal is not to send every 'bug' to the user's mail. The idea is (if I'm correct, @csarven) that an error response, if semantically usefull (as in #28 and RFC 7807), it could additionally refer to an "inbox" that can be used to handle this error out-of-band. Such an inbox is not neccessarily the same one in which the user receives mail, posts or other notifications. But it can be a place where an out-of-band service (e.g. an authorization app) can take listen for requests. I do think, however, @csarven, that this endpoint should not neccessarily be an Inbox. A more abstract proposal would use Structured Errors / Problem Details to convey any semantically described endpoint that could be usefull for the agent. |
That's not the case. In the same way that clients are not required to follow the URI-Reference of a
Sure but if the developer hasn't implemented to handle the error case, nothing is broken. The application is simply not picking up on the affordances. The original request is simply unfulfilled, e.g., 403. End of story. Which is why the hint that's given in the response enables applications, if they choose to, to prompt the user for consent to submit an access request.
But no one is proposing "just send something". That's not interop. Protocol and Data Model are separate concerns/aspects that can be specified independently. What's demonstrated in this PR and elsewhere is only a case pertaining to requesting access in which an implementation uses AS2 + WAC vocabs. Something that merely reuses and extends to move the discussion forward (if not since 2018 or even much earlier). If we don't like cornflower blue, I'm sure we can come up with something else for the notification.
Sure. 400 is perhaps a client "bug" but again that wasn't one of the status codes that I tried to draw attention to. 403 is not a bug. (We can work out structured error messages separately. Discussion on that has been sitting around for years too. Where is the data model for interop?) Yes, listing specific status codes is one way - and that's completely fine - and the alternative is to leave enough variance for servers to decide if/when/where the response to a target resource advertises an inbox.
Separate issue but some of us are quite interested in that. It is in the spirit of HTTP. We need a data model and respond with text/html including RDFa.
I'm not sure. I don't think we should lump inboxes with 2xx and 4xx. Vary: Authorization should probably play a role here?
Perhaps. There is a simpler generalisation with the current approach without exposing the resource owner. (But if structured error messages includes that one day, great.) The inbox returned on the response is about the target resource. However that inbox is controlled and maintained is orthogonal.
Specs don't "mandate". And this spec/proposal is not doing that. |
That's fine too. As I've stated in the first comment #253 (comment) :
We are not short on ideas or eventually coming up grand designs that does everything amazingly. The point here.. what's the point.. well, with this simple PR and demo.. there is a demonstration of something that's useful without boiling oceans and waiting around for 5 more years. Can we "have a better design" (tm)? Absolutely! What is it going to take to get there? |
|
Hmmm, right, so I am in favour of doing relatively simple things that can be extended now rather than later... Providing affordances for things that a client might do is nice. I'm still wary of overusing headers, where there are things we perfectly well could use a bit of RDF in the body for. We do have a predicate for inbox already, can't we just use that as a beginning of an approach to do this for #28? |
|
@csarven I'm hearing what you say, but I still think we should be very deliberate in what this is intended to have as an outcome. i'd also ask: if a WebID / Pod / Resource had an LDP Inbox normally, on success statuses, would that Inbox be different for 4xx errors? i.e., would you have one inbox for annotating/commenting/social, which gets returned on 200 responses, and a different inbox for 403, 402, etc? Would all 4xx responses get the same Inbox? Would both 200 and 4xx give the same inbox if an inbox is defined for the pod/resource? i think this really needs to be added with a concrete use case, otherwise it will invite misinterpretation from Authors & Implementors, both which may ultimately not server the Users. if it's Authorization, let's focus on solving that, and leaving all the other error types to later. |
|
Also, in practice, I don't think any implementation of a server has defined what happens with data in inboxes or how Users get notified, so you'd perhaps write a request to the inbox, but as the controlling user is never actually notified, and instead the inbox data is only surfaced through an app, it could be functionaly the same as sending that access request to /dev/null (a nice analogy for the is whenever social media companies have split your DMs inbox into two: siloing spam / requests in one, and leaving the rest elsewhere, it's very common for users to suddenly discover heaps of messages they never got because they were never notified correctly) |
We sure can. If we want to enable applications to set the inbox (alongside other descriptions, policy, communication option, contact information..) in RDF, an auxiliary resource like the Description Resource may need to be used so that the server can re-use that information in error messages. I think that also opens up an important area (can of worms): allowing subject resource to have different access controls than auxiliary resources so subject resource may not be readable but the description resource or the ACL resource can be ( see e.g., #63 (comment) ). |
|
Thanks all. Withdrawing this proposal because apparently demonstrating a solution to meet some use cases (existing issues spanning several years and circumstances) in addition to sharing some implementation experience (with open source code and screencasts..) wasn't enough to land this. Indeed this PR has some approvals, some objections, some misunderstandings, and some whatevers :) We had consensus but not consent. Noting here that no actually working / demonstrable alternative was provided to date. Better not have any solution now because we'll certainly land a better design in 5 years, right? /s On the bright side, this was a good learning experience, and as discussed above with Kjetil, we can indeed take up error-specific use cases as part of the data model of Structured Error Messages: #28 - which I fully support. |
|
It looks like a good idea, just in my caseI have not gotten so far yet with my own setup. |
When a server responds with a client error (4xx), it can also enable clients to attempt to resolve the error by providing contact information. (See for example RFC 7231 https://tools.ietf.org/html/rfc7231#section-3.3 suggestion on next steps to resolve the error.)
This PR extends the LDN protocol to allow the discovery of the Inbox URL of a target resource when a client error occurs.
Not all 4xx responses are necessarily meaningful to advertise the Inbox URL. This is left to the discretion of the server. However, there are use cases that appear to be suitable for 401, 402, 403, 407, 410, 418, 423, 429, 451 (and possibly others). For instance, when clients encounter 401 or 403, the next steps to inquire the right credentials or request access to resources was previously discussed. This PR meets the Protocol needs of eg. nodeSolidServer/node-solid-server#992 , solid/solid#229 , solid/web-access-control-spec#40 , solid/web-access-control-spec#21 , solid/data-interoperability-panel#13 , solid/authorization-panel#28 .
Inbox discovery on client error may complement structured error messages eg. #28 .
Specifying inbox discovery on client errors could be in a different document because it is not tied to the Solid Protocol eg. LDNx spec of sorts that may cover the other items in solid/data-interoperability-panel#13 (comment) , but until a more suitable is needed, I suggest to keep it in the Solid Protocol.