Section 3.2: no language support

[r12a]

[raised by Addison Phillips, discussed in i18n telecon]

https://www.w3.org/TR/webmention/#receiving-webmentions

Section 3.2 say (in part):

The response body MAY contain content, in which case a human-readable response is recommended.

There is no mention of language negotiation or language identification here. The assumption appears to be that a wad of English is returned? ;-)

The example could include a Content-Language header or might allow for other language identification in the body (complicated)

This is also applicable to at least 3.2.3 Error Responses as well.

If the Webmention was not successful because of something the sender did, it MUST return a 400 Bad Request status code and MAY include a description of the error in the response body.

[aaronpk]

Thanks for bringing this up. The response body is not meant to be visible to end users, and is only informative, since the HTTP code indicates the actual status of the request. Some implementations return a JSON body or no body as well, while others return text such as "Success".

Given that there is no functionality specified by returning a response body, do you think it would be appropriate to just drop "in which case a human-readable response is recommended."?

For error responses, these again are not meant to be visible to the end user, and only useful in development. What is the normal recommendation for returning error messages intended to be seen only be developers?

[akuckartz]

As an end user I have seen many errors intended to be seen only by developers.

[kevinmarks]

If we update the normative reference to HTTP 1.1 to RFC 7231, we can delegate the response body to https://tools.ietf.org/html/rfc7231#section-6.5 (ie the language identification is done in the usual way for HTTP, and not needed to be specified by webmention)

[sandhawke]

Changing a normative reference would normally necessitate another CR. Or is the charge in reference purely editorial?

[aaronpk]

The spec references HTTP 1.1 (RFC2616) in two places, when talking about sending the HEAD request, and when talking about returning the HTTP status code. Changing the reference to 7231 would not have any implications of changing existing implementations if that's what you mean.

[kevinmarks]

I don't think we use the parts of HTTP 1.1, that were ambiguous in 2616, but referencing the better spec is worth it in terms of leading implementers to the current state of understanding. Mark Nottingham wrote about the differences here: https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead Sorry I didn't catch this reference earlier.

[sandhawke]

That sounds like it should be okay, but as part of the PR transition, we'll have to make the case that the change isn't a problem.

[aaronpk]

notes from f2f discussion:

• Change normative response and example to an empty body
• Add an informative note that describes what implementations have done around returning HTML body, status messages, etc
• Senders: to avoid an HTTP 400 response, include an Accept: */* header so you always get some response
• Receivers: add informative note that some receivers accept webmentions from a browser and return HTML and follow HTTP best practices including appropriate use of accept-language
• i18n: what is the guidance on error responses that have no functionality?

[aaronpk]

Notes from discussion with i18n:

• Remove example english text from response body
• Don't include "bad examples" of returning English without returning a language header
• Error response section does not need an i18n recommendation because it does not suggest any response body