[ih] theory and practice of RFCs?

[Miles Fidelman]

Alex McKenzie wrote:
> The RFCs were truly Requests for Comments.   ... <snip> I don't know 
> when the RFC series became as tightly controlled as it is now, but I 
> know it was after RFC 905, published in April 1984.
and Dave Crocker wrote:
> The modern IETF certainly filtered documents, but that started in the 
> late 80s.  As the IETF became more proprietary about what documents 
> got published, the RFC Editor was pressed to pay attention to the 
> possibility that an independent document was, somehow, an 'end run' 
> around the IETF.  I think this is what caused the RFC Editor to start 
> using more active filters on what got published.[*]

Which brings me back to the other question I posed: "If one wanted to 
pose an idea for a new protocol, and solicit feedback, how would you do 
it today?"

This is motivated by wanting to distribute a white paper about some of 
my current work, for review and comment.  My initial thought was to 
publish a draft RFC - but the process and audience are not what they 
once were, and recent RFCs seem much more standards like (as others have 
commented).  In the early days, it seems like there were tremendous 
benefits from the whole process of academic/collegial discussion, rough 
consensus and running code, etc. - all centered around RFCs as a 
communications vehicle.  These days, everything seems to have 
splintered, and more political:
- we have folks who simply ignore the process (e.g., CARP)
- we have things that have followed a convoluted process (e.g., RSS and 
Atom, various microformats)
- we have splintering of standards communities, processes, groups (e.g., 
W3C, XMPP, calconnect, OGC) - some of which have rather steep membership 
fees for participation - and a lot of work seems to span multiple groups 
in loosely defined ways

In my specific case, the focus is group communication - integrating 
elements of messaging, calendaring, and task management - leveraging and 
extending several existing protocols.  I've been working on an 
architecture level description, and thinking about publishing something 
like the original SMTP RFC821, or NNTP RFC977 - both of which were 
fairly heavy on system architecture concepts (it seems like later 
versions have deprecated architectural discussions, focusing more/just 
on transaction formats).  Or think of an architecture-level treatment of 
the iCalendar family of protocols.

As I say, my initial thought was a Draft RFC, but that doesn't quite 
seem right anymore.  I seem to recall a short-lived series of IETF 
documents called "IDEAS" (do I have that right), but can't seem to find 
any current information.

So...  if you wanted to circulate an architecture-level white paper for 
review & comment, would you prepare it as a draft RFC and submit it to 
the RFC editor, or take a different route (and if so, what route)?

Thanks for any suggestions!

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra