[ih] theory and practice of RFCs?

[John Day]

Write an Internet-Draft like everyone else.


At 15:52 -0500 2012/12/15, Miles Fidelman wrote:
>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