[Commentor] LC-2835 Tim Berners-Lee (archived comment) [Working Group decision] OPTIONS is not required to achieve this. It could be used in cases when a client wants a low-cost means to learn more about the resource identified by the URI if it hasn't already done a GET. If it has done a GET and kept the header information, there is no need to use OPTIONS. [Commentor reply] tocheck [Comment] 
4.9.1 Servers must support the OPTIONS method. Why? Should there be a basic level of functionality which any LDPR allows and which does not require OPTIONS polling? OPTIONS is expensive: another round trip. Always avoid an extra round trip if you can. We need this system to move really fast. Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users. Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension or a POWDER label say). You have to do it for every fresh URI you find. The Linked Data operation is a GET. Is the basic operation for an LDP-capable client always OPTIONS, GET, or GET, OPTIONS? Maybe key headers can be put into the HEAD and GET response. Maybe the class of resource announced with Link: rel=type can have a URI which can be looked up itself and cached. and will give the set of features in a standard way. Suggest define a core LDP protocol which does NOT use OPTIONS, by assuming that the core functionality is enough for clients to do what they need. Clients needing extensions maybe can use OPTIONS. But maybe POWDERR should be preferred.