Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Receiver responses to notification requests #60

Closed
albertmeronyo opened this issue Nov 7, 2016 · 3 comments
Closed

Receiver responses to notification requests #60

albertmeronyo opened this issue Nov 7, 2016 · 3 comments

Comments

@albertmeronyo
Copy link
Contributor

While I was implementing pyldn, a compliant receiver, it was a bit unclear how receivers must respond to GET requests against notification URIs.

I see this bit was added meanwhile as a receiver responsibility, which already helps:

Responds to GET requests made to the individual notification URLs with JSON-LD (or optionally other serializations).

Section 3.3.2 specifies though how a receiver should respond to GET requests against inbox URIs, but not what to do against GET requests to notification URIs. This bit

Each notification must be an RDF source. If non-RDF resources are returned, the consumer may ignore them.

suggests that the receiver must make the notifications available, and answer HTTP 200 OK to valid notification URIs and HTTP 4xx where applicable; but I felt this wasn't specific enough in the draft. Also, I find the requirement on making notifications RDF sources a bit over constraining. Currently pyldn uses notification URIs as graph names, and stores the payloads' triples within those. It's a bit unclear whether this is compliant with the spec or not. I think it might also create issues when consumers ask for serializations that do not support quads (e.g. curl -X GET -H'Accept: application/n-triples' http://example.org/inbox/1)

Some of these are also implied by section 3.4 Consuming, but as a receiver implementor I would expect all receiver requirements to be described in section 3.3.

@csarven
Copy link
Member

csarven commented Jan 2, 2017

Thanks for raising this.

Treating the notification URI as the graph name is one way of doing it, and the way you do it is perfectly fine. The resource itself is a graph in and of itself where it might have its description in triples or quads (multiple graphs in the resource).

Updated: https://linkedresearch.org/ldn/#receiving-inbox-contents and clarified the note here: https://linkedresearch.org/ldn/#note-request-uri-and-relative-id

How does that sound?

@albertmeronyo
Copy link
Contributor Author

There's a small typo at https://linkedresearch.org/ldn/#note-request-uri-and-relative-id (repeated 'the'):

Implementations may wish to treat notification URIs as graphs which contain the the RDF from the notification payload.

The rest addresses my concerns just fine. Thanks for the update!

@csarven
Copy link
Member

csarven commented Jan 18, 2017

Great, thanks for the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants