As others have doubtless noted, the actual standard as well as K&R 2 are deliberately even more vague about this issue. The standard presumably wants to avoid forcing the existence of and defining the semantics of directories, the notion of .., whether / or \ or something else is used as a separator in file names, etc. etc.
Most of the solutions people have come up with are presumably consistent with the standard and so the question is what is the most useful convention. I suppose there are two general theories about this.
One is that relative "..." includes are relative to the original source file, the other is that they are relative to the file in which they appear. On the whole I have become persuaded that the first interpretation is more useful and easier to understand. It caters to the situation I've met most frequently, where one wants to compile some complicated system from afar--source and associated headers in some distant place, but I don't want to have to read them to discover their inclusion relationships.
Of course the systems that do have directories often implement -I directives, which (depending on how you look at it) either save you because you can control the search, or introduce further confusion because you sometimes have to figure out what -I things are needed.