search

w3c / activitystreams

Activity Streams 2.0
https://www.w3.org/TR/activitystreams-core/
Other
284 stars 60 forks source link

Expectations around IRI resolution #438

Closed cjslep closed 6 years ago

cjslep commented 6 years ago

Please Indicate One:

Please Describe the Issue:

(I am splitting my email to the public-socialweb mailing list into separate issues, for background please see those emails).

It is unclear to me when inlining IRIs versus inlining actual contents is warranted, and what the expected behavior is when presented with an IRI. I am unsure what to expect of other implementations as I build out a golang implementation library:

  1. Not resolving IRIs at all and ignoring just those fields that are not inlined with an ActivityStream type.
  2. Not resolving IRIs at all and ignoring the entire message if any of those fields are not inlined to an ActivityStream type.
  3. Resolving with a GET request and ignoring just those fields whose GET response are not ActivityStream types.
  4. Resolving with a GET request and ignoring just those fields whose GET response are not ActivityStream types.
gobengo commented 6 years ago

@cjslep 3 and 4 are the same eh? That's the right choice I think.

Make a GET request with "Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams", application/ld+json, application/activity+json, application/json"

If you response code is not 2xx, stop (e.g. 405 means that URL cant give you AS2 or JSON) Try to treat the response like AS2 (parse as JSON). If any errors, stop.

cjslep commented 6 years ago

Sorry, I meant:

  1. Resolving with a GET request and ignoring just those fields whose GET response are not ActivityStream types.
  2. Resolving with a GET request and ignoring entire objects whose GET response are not ActivityStream types.

I think I had done some more reading up since I filed this issue, and I recall somewhere that implementations are expected to ignore invalid or incomprehensible properties, so indeed I think 3 is the way to go.

I also think a lot of the IRI resolution will happen within an application and not within an implementation library, to suit the specific needs of the app. The exception is of course the 'dereferencing' required in the specs that leverage this one, such as ActivityPub which explicitly mentions which IRIs are needed to be dereferenced for actions such as delivery.

I am going to close this now.