Re: Should the specs be forked and maintained elsewhere?

http content negotiation is normatively required by the activitypub spec
(3.2).
I'll also point out that some URIs from the TRs already support it.

```

> bengo@bengo ~ ⚡  curl -H "Accept: application/json"
> https://www.w3.org/ns/activitystreams | head -n 10
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
>  Current
>                                  Dload  Upload   Total   Spent    Left
>  Speed
> 100  7985  100  7985    0     0  39142      0 --:--:-- --:--:-- --:--:--
> 40125
> {
>   "@context": {
>     "@vocab": "_:",
>     "xsd": "http://www.w3.org/2001/XMLSchema#",
>     "as": "https://www.w3.org/ns/activitystreams#",
>     "ldp": "http://www.w3.org/ns/ldp#",
>     "vcard": "http://www.w3.org/2006/vcard/ns#",
>     "id": "@id",
>     "type": "@type",
>     "Accept": "as:Accept",
> bengo@bengo ~ ⚡  curl -H "Accept: text/html"
> https://www.w3.org/ns/activitystreams | head -n 10
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
>  Current
>                                  Dload  Upload   Total   Spent    Left
>  Speed
>   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--
>   0<!DOCTYPE html><html dir="ltr" typeof="bibo:Document " prefix="bibo:
> http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#
> as: https://www.w3.org/ns/activitystreams#" lang="en"><head><meta
> charset="utf-8"><meta name="generator" content="ReSpec 20.7.1"><meta
> name="viewport" content="width=device-width, initial-scale=1,
> shrink-to-fit=no"><meta property="dc:language" content="en" lang="">
>     <title>ActivityStreams 2.0 Terms</title>
>
>
>
>   <style>/*****************************************************************
>  * ReSpec 3 CSS
>  * Robin Berjon - http://berjon.com/
>  *****************************************************************/
>
> 100 33068    0 33068    0     0   148k      0 --:--:-- --:--:-- --:--:--
>  153k
> curl: (23) Failure writing output to destination
>
```

On Fri, Mar 24, 2023 at 10:16 AM Ryan Barrett <public@ryanb.org> wrote:

> Sure! And feel free to redirect to a different venue if we're getting off
> topic. Off the top of my head:
>
>    1. Most web developers are not aware that conneg exists. This is
>    usually fine, since it's uncommon, but can be an unpleasant surprise when
>    they first hit it and don't understand it.
>    2. The `Accept` header is notoriously complicated to parse, generate,
>    and fully comply with. Imo much of that complexity is unneeded in practice.
>    3. It often breaks caching when it's first introduced. Internal and
>    external caches generally ignore Content-Type and Accept (etc) by default,
>    so when conneg is first introduced, clients often get the wrong response
>    type. Developers learn the hard way that they need to add Accept to Vary
>    and to their framework's cache.
>    4. URLs leak across contexts. They may start out within a single
>    service or API, but they gradually proliferate into user-visible links,
>    object identifiers in other systems, add-on services, third party tools,
>    etc. These generally don't know the original conneg requirements, which
>    causes unpleasant surprises.
>
> I think most of this boils down to: modality generally considered harmful.
> When something always behaves the same way, it's reliable and easy to use.
> When it behaves differently based on something far away in the environment
> that you may not know exists, it's unreliable and surprising. Add in a very
> large ecosystem of independent tools that all need to interoperate, often
> in fine-grained ways, and you have a recipe for failure.
>
> On Fri, Mar 24, 2023 at 9:42 AM Bob Wyman <bob@wyman.us> wrote:
>
>> Melvin, Ryan,
>> Could you provide at least a short summary of why "content negotiation"
>> has not lived up to expectations? It is good to know that it is
>> non-optimal. It would be better to know why.
>>
>> bob wyman
>>
>>
>
> --
> https://snarfed.org/
>

Received on Friday, 24 March 2023 17:24:04 UTC