The first sentence of your quote say that all prior knowledge should be about media formats (like the html specification, microformats, the PNG image format…).

From there, the medium itself should provide enough clue for the client to go on. For instance, anchor links in html says you can GET a resource at the specified URI. Other media formats could provide other clues.

To sum up, the only things you can specify a-priori are media formats. URIs and protocols should be interchangeable, so you can update and deprecate them. I think the main goal of REST is to concentrate coupling on media formats alone. Hopefully, most media formats are (or will be) standardized, effectively reducing coupling. Basically, REST architectures are for the long term.

Another example drawn from the article: if the blog posting service provides each post under a uri like /posts/{post-id}, the client of the service shouldn't have to know the uri structure. Instead, /posts/ should be a resource, and it should contain hyperlinks to all of the /posts/{post-id} uris that are available. There would probably be some metadata about each one as well, such as a title, to enable clients to figure out which one they want to follow.