why are ringbuffers bound to an existing file descriptor?

I was just curious whether an unconventional use of the proposed ringbuffer API for userspace to userspace communication would work, assuming that whatever the kernel does with the ringbuffer for the chosen file type doesn't interfere or is taken into account. It's not sensible or needed, though, because that can be done right now and you only need help from the kernel for the non-spinning wait, e.g., via futex, which is available.

Regarding my first question, why a ringbuffer needs to be associated with a file descriptor: Do you expect ringbuffers will only be used as an alternative api to the same data channels as accessible by reading/writing the file descriptors? Is this why there is no standalone ringbuffer? Any kernel feature which supports ringbuffer communication should also support conventional I/O on the same descriptor?