Re: musings

Craig Partridge <> Thu, 16 May 1996 23:46 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa27896; 16 May 96 19:46 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27892; 16 May 96 19:46 EDT
Received: from by CNRI.Reston.VA.US id aa06338; 16 May 96 19:46 EDT
Received: by (5.65c/5.61+local-23) id <AA13488>; Thu, 16 May 1996 16:31:08 -0700
Received: from by (5.65c/5.61+local-23) id <AA13482>; Thu, 16 May 1996 16:31:07 -0700
Received: from by (5.65c/5.61+local-23) id <AA23886>; Thu, 16 May 1996 16:31:06 -0700
Received: (from craig@localhost) by (8.7.1/8.7.1) id QAA17268; Thu, 16 May 1996 16:29:01 -0700 (PDT)
Message-Id: <>
To: William Chops Westfield <>
Cc: Fred Baker <>, Robert Elz <>,
Subject: Re: musings
In-Reply-To: Your message of Thu, 16 May 96 15:45:00 -0700. <>
Date: Thu, 16 May 96 16:29:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Craig Partridge <>
Precedence: bulk

    Of course, RFC1122/23 weren't an unqualified success either.  It's shown up
    in RFPs, but you can still find plenty of implementations that are broken i
    serious ways (according to RFC1122/23) that the vendors seem to have little
    interest in correcting.

Yep, but also a bunch of changes that RFC 1122/23 required have been made.

I'd say six of one, half dozen of another, except I think more changes were
made than not.

Another note about RFC 1122/23 and this BCP idea for rreq.  RFC 1122/23
*amended* the standards.  They're the documents that, for instance, are
the standards that say use slow start etc.  So BCP wouldn't be right
for RFC 1122/23 and, I believe, wouldn't be right for rreq either.