Aaron Parecki

Just for clarification since some people seem to be unclear, this issue is specifically about whether to allow/recommend HEAD requests when making the HTTP request to verify that a webmention source URL does in fact link to the target URL.

This is *not* about the HTTP request used to discover the webmention endpoint in the first place. There are definitely obvious benefits to doing a HEAD request first when discovering the endpoint, since the webmention endpoint may be advertised in the HTTP header, which means that the sender can avoid making a GET request at all.

When verifying the link back, the receiver is going to have to make a GET request eventually, in order to check the document body for the link. The question is whether we should recommend that a receiver first make a HEAD request to the source URL before making the GET request.

It's true that not all webmention targets are HTML documents. Because of this, I think it's reasonable to clarify the text, changing

> The sender MUST fetch the target URL (and follow redirects [FETCH]) and check for an HTTP Link header [RFC5988] with a rel value of `webmention`, or an HTML `<link>` or `<a>` element with a rel value of `webmention`.

to

> The sender MUST fetch the target URL (and follow redirects [FETCH]) and check for an HTTP Link header [RFC5988] with a rel value of `webmention`, and if the content-type of the target URL is HTML, the sender MUST also check for an HTML `<link>` or `<a>` element with a rel value of `webmention`.

Requiring all senders to check for the HTTP `Link` header provides the largest opportunity for interop among implementations, since it's possible to publish a Link header regardless of content type.

If you have specific examples of wanting to advertise a webmention endpoint in a non-HTML document, please document them and suggest a (as you said) "standards-compliant way" of advertising the endpoint in the document.

I'm just going to point back to what @sandhawke said:

> Abandoning your early adopters before establishing a new user base means you have nobody.

The time to suggest a 100% breaking change to the spec has long passed. There is already a lot of written and deployed code that sends webmentions using form-encoded syntax. It's not a matter of simply making a "tiny" change to switch to JSON, since it will affect senders as well as receivers, some of which are using libraries on both sides, not to mention the fact that this software is deployed quite widely and in places where a single person can't even mandate that it be updated. Such is the situation when a spec gets widely implemented.

@rrmutt You can sign up for the weekly newsletter! https://indiewebcamp.com/this-week

@obensource Speaking of audio, are you free tonight? It'd be great to see you at this! https://www.eventbrite.com/e/xoxo-podcast-studio-visioning-workshop-tickets-25070419299

@obensource @denormalize Perfect! This will be a good chance to test out my new bike-sized recording rig!

@denormalize Sure thing! Who should I get in touch with to coordinate?