Add Inbox Discovery on Client Error #253
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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> | ||
|
|
||
| <p>A Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p> | ||
|
|
||
| <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. |
||
|
|
||
| <p>Servers who want to advertise the Inbox URL in a HTTP response with a <code>4xx</code> status code, <code>MUST</code> do one of the following:</p> | ||
csarven marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| <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>include 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> | ||
csarven marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| </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. 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. 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. |
||
|
|
||
| <p>Senders and consumers do the following to discover the Inbox URL in a HTTP response with a <code>4xx</code> status code:</p> | ||
csarven marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| <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. 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. |
||
|
|
||
| <p>These may be carried out in either order, but if the first fails to result in an Inbox the second MUST be tried.</p> | ||
| </div> | ||
csarven marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| </section> | ||
| </div> | ||
| </section> | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am happy with this introspection pattern for enabling User Agents deduce the locations of special resources e.g., inbox folders.