- From: Abdullah Tarawneh <a@trwnh.com>
- Date: Tue, 28 Feb 2023 20:45:34 -0600
- To: Benjamin Goering <ben@bengo.co>
- Cc: Bob Wyman <bob@wyman.us>, public-swicg@w3.org
- Message-ID: <CACG-3GiFexm6rhb20n-_ndycBz7qi1CWrWKmfLQi7ZTNDTaEsA@mail.gmail.com>
> If there's an as2 parser that drops unknown jsonld, then it's an as2 parser that doesn't support parsing extensions to the vocabulary. I don't consider that an ActivityStreams native parser. This is explicitly supported by AS2-Core under section 2, "Serialization": "Implementations *MAY* augment the provided @context with additional @context definitions but *MUST NOT* override or change the normative context. Implementations *MAY* also use additional properties and values not defined in the JSON-LD @context with the understanding that any such properties will likely be unsupported and ignored by consuming implementations that use the standard JSON-LD algorithms." Basically, if you use extensions, you should do so using JSON-LD. But it is a design goal of AS2 that it can be parsed as plain JSON if you only care about the "normative" AS2 context. LD-aware consumers that wish to support plain-JSON AS2 MUST inject the AS2 @context if it is missing from an application/activity+json document. Likewise, as an LD-aware consumer, you SHOULD do the same for application/ld+json; profile=" https://www.w3.org/ns/activitystreams" documents. Put another way: - You can support LD and AS2, which lets you handle plain-JSON AS2 in addition to extensions (to the extent that generic processing of JSON-LD is viable without considering semantics) - You can support LD but not AS2, which means you can only process documents from plain-JSON AS2 if they include the @context (which they SHOULD, but don't have to), but otherwise should be able to process both LD-aware AS2 as well as extensions - You can support AS2 but not LD, which means you are only expected to process the Activity Vocabulary, and any support for extensions is not guaranteed (which is where most fediverse servers reside at the moment) >
Received on Wednesday, 1 March 2023 02:46:24 UTC