Rejected RFC

Previously posted at http://joel.westside.com/wsContentPublisher/story.view?RowId=9

User Experience Working Group                                 A. Mukerji
Request for Comments: nnnn                                   J. Aufrecht  
Category: Informational                                    April 1, 2001

     Extensions to Standard Enumeration of User Output Functions

Status of this Memo

   This memo provides information for the Internet community.  This
   memo does not specify an Internet standard of any kind.
   Distribution of this memo is unlimited.

Abstract

   The traditional enumeration of user excretory function, "Number
   One" and "Number Two," fails to address the entire function
   domain.  This memo extends current practice by defining functions
   Three through Ten.  For backwards compatibility (especially as
   regards Number Two), new names and subtypes for Function Numbers
   One and Two are proposed.

Function Definitions

   1: Streaming Media Release. Distinct from RTSP (Real Time
      Streaming Protocol.) Usually intended to be unicast, but the
      decision to broadcast or multicast is left to the implementor.
      A natural consequence of Java.

   2: Core Dump, also Dot Release.  Preferred implementation is FIFO.
      Core logs may be examined for evidence of invalid input or
      system corruption.

 2.1: Enhanced Dispersion Core Dump.  May cause a paper jam.

 2.2: Accelerated Core Dump. Frequently a consequence of I18N.  While
      examination of the logs alone may not yield evidence of a
      preceding race condition, inspection of the environment will
      frequently produce confirmation.

   3: Backward Accumulation Receipt Feed (BARF)

      A common routing problem, typically a result of input type
      mismatch or compiler error.  Also caused by mistaking big-endian
      packets for little-endian.  Although not specified, virtually
      all implementations are LIFO.  A standard websafe 240-color
      palette should be more than adequate to render results.

   4: Simple Network Offline Terminal (SNO TTY)

      When produced by a Sudden Node Echo Event (type ZE),
      care should be taken to properly garbage-collect so as to
      minimize impact on other users.  Use of bless() or equivalent
      is common practice to avoid terminal ncurses-related errors,
      especially in hex.

   5: Splashed, Packetized Interactive Transmission (SPIT)

      Indiscriminate vectoring of packets may results in process
      termination, especially if recipient is a large trucker.
      
   6: Reserved for Future Implementation

   7: Passive Hydrogenated Audio Response Transmission.

      A common component of a Distributed Denial of Service attack.
      Although difficult to authenticate, it is even harder to
      repudiate.  Generally results in the perpetrator being advised
      to flush his or her cache.

 7.1: Passive *Hydrated* A.R.T.  A highly destructive variant,
      inevitably resulting in reassignment of host domain to "wet.1."
      Disaster recovery planning, especially the use of redundant
      trunks, is essential.

   8: Process Fork().  Typically involves a named pipe (despite vendor
      claims, virtually all pipes are named).  Care should be taken to
      avoid unhandled exceptions.  Alternately, a "transparent"
      firewall may deter intruders (and prevent spread of
      viruses), but can never be 100% effective; incorrectly withdrawn
      standards may further compromise protection.  Other
      deterrents include access control lists, proper use of assert(), 
      and the innate repellant properties of technical users, in
      particular system administrators.

      As an aside, the authors would like to point out that certain
      well-known difficulties in the technical community may be
      partially attributable to the standard practice of performing
      fsck *prior* to mount, which may result in parameters being
      passed and buffer caches filled inappropriately.  We recommend
      instead that fsck be incorporated as part of the mount
      function.  This operation should be performed in pairs (or
      teams) whenever possible, although diminishing returns may be
      experienced at higher values of N.  

      Users should beware inadvertant Random Access errors, and, while
      care must be taken to avoid race conditions at all cost, note
      that the opposite is true as regards *raise* conditions.
      Further, Quality of Services guarantees should be treated with
      skepticism and validated with previous users if at all possible.
      Interfaces should be placed in promiscuous mode when performing
      such validations.

      Although readers may note certain similarities to eXtreme
      Programming, we believe these to be strictly superficial.
      (However, it is interesting to note that, in both cases, the
      client is likely to get fscked.)

   9: User Spawn().  Often the consequence of a good fork() without
      adequate exception handling.  This may be prevented by asserting
      appropriate limits before filesystems are mounted and buffers
      overflowed.
  
  10: Pre-Emptive Recursive I/O Deallocation. 

      Typically preceded by transmissions via Proprietary Messaging
      System, a lossy protocol with no documentation.  Fault-tolerance
      (and even remote access) are strongly recommended to avoid
      damage to peripherals.  Users encountering invalid checksums are
      urged to disregard the parity bit.  Unintelligible error
      messages are unfortunately the norm; for example, "File is
      Read-Only" is replaced with "I just can't, okay?"

Author's Addresses

   Arindum Mukerji (raja@moselle.com)
   Joel Aufrecht (joel@aufrecht.org) 

Copyright Notice

   Copyright (C) 2001, Joel Aufrecht and Arindum Mukerji.  All Rights
   Reserved.

   This document and the information contained herein is provided on
   an "AS IS" basis, especially as regards Function Numbers Eight
   through Ten.