RFC5988: <link rel="..."/>

[westurner]

RFC5988 "specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field."

• http://tools.ietf.org/html/rfc5988

This could be used with or without RFC5785. (#2)

[madrobby]

Makes sense, however given that we describe service downtime the service may be down and so the link header field would never load in the first place. Need to be threading carefully here! :)

[westurner]

To me, the advantage of this over just handling standard HTTP codes [1] would be that I may have advance notice of when and why a particular service would be unavailable.

If the HTTP response code to a HEAD request is not a 200 OK, operational questions I would have -- as a user or an automated agent -- would include:

• When will the service be back online?
• Why is the service offline?

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

[westurner]

If a browser or an external aggregating service could grep this structured data from the page (as with #10 Schema.org Event microdata), I could have advance notice of when and why a particular service would be unavailable.

[madrobby]

These are all academic and of no use or consequence if a service is actually down. Lets keep it simple, and not add complication for the sake of it.

[donohoe]

I'd make two arguments for this:

• The service may be down but usually there is a high probability of some sort of landing page or placeholder page. The LINK tag would still be useful and make sense. Its only in catastrophic failure that this isn't useful.
• Ahead of downtime (catastrophic or otherwise) it would help discoverability for any apps and tools that come across the site.