On Mon, Oct 30, 2017 at 9:40 PM, Toerless Eckert <tte@xxxxxxxxx> wrote:
On Sun, Oct 29, 2017 at 11:39:34PM -0400, Alia Atlas wrote:
> Personally, I have not seen it work well or be generally perceived as
> anything more than a waste of time to ask well specified and widely available mature open
^^^^^^^^^^^^*
> source work to come and be republished as an Independent Stream Informational RFC.
I guess that "well specified" is a cornerstone word here: _if_ the OS protocol was well specified (and with this I mean in an unambiguous way, with enough detail to allow interoperability with other implementations and in a stably referenced document), I would agree that re-publishing it is a waste of time and I would have no qualms in using it in an RFC.
However, my personal experience with OS software (both as users an -- partly -- as a contributor) is that documentation in some cases can be really lacking and the source code is considered the ultimate documentation (I remembered that few years ago I asked details about the format of octave data files and I was told to look at the source code).
One could think about considering a snapshot of a specific version of the source code as the protocol specs; unfortunately source code is not good for that: first, you need to reverse engineer it in order to deduce -- say -- the format of a packet; secondly often is *not* unambiguous, for example: if you declare a packet field as "int" in C, how many bits is? Sure, the code will run smoothly with current processors since int is 32 bits everywhere, but what if you are going to communicate with a processors whose int is 64 (or 16)-bit wide? (and I did not mention "efficiency tricks" that are ill-defined according to the C specs, but work as long as you stick to gcc).
One could object that if there is an open source implementation, there is no need for unambiguous specs since one can just use the existing implementation. However, I see this as a very weak solution: someone else could need to create a new implementation, maybe in a different language, maybe for a different architecture not compatible with the current implementation.
Summarizing, if the cornerstone condition "well specified" is met, I think that the OS protocol can be considered as a protocol developed by any standard body (this suggest that condition "well specified" is quite demanding), but if the condition is not met, the only solution I can think of is to "snapshot" it (and clean it, if necessary) into an Informational RFC.
Riccardo