Re: ietf-nntp Issues with new draft

Nat Ballou <NatBa@ims.microsoft.com> Thu, 04 September 1997 21:48 UTC

Received: from cnri by ietf.org id aa18772; 4 Sep 97 17:48 EDT
Received: from announcer.academ.com (majordomo@ANNOUNCER.ACADEM.COM [198.137.249.60]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA04020 for <ietf-archive@cnri.reston.va.us>; Thu, 4 Sep 1997 17:51:55 -0400 (EDT)
Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.8.5) id QAA04021; Thu, 4 Sep 1997 16:47:48 -0500 (CDT)
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.8.5) with ESMTP id QAA04016 for <ietf-nntp@ANNOUNCER.ACADEM.COM>; Thu, 4 Sep 1997 16:47:47 -0500 (CDT)
Received: from eemail.microsoft.com (eemail.microsoft.com [131.107.1.244]) by academ.com (8.8.5/8.8.5) with ESMTP id QAA03826 for <ietf-nntp@academ.com>; Thu, 4 Sep 1997 16:47:45 -0500 (CDT)
Received: from ims.microsoft.com - 131.107.1.244 by eemail.microsoft.com with Microsoft SMTPSVC; Thu, 4 Sep 1997 14:47:48 -0700
Received: from natba1 - 157.55.23.225 by ims.microsoft.com with Microsoft SMTPSVC; Thu, 4 Sep 1997 14:47:48 -0700
Reply-To: Nat Ballou <NatBa@ims.microsoft.com>
From: Nat Ballou <NatBa@ims.microsoft.com>
To: NNTP Working Group <ietf-nntp@academ.com>
Subject: Re: ietf-nntp Issues with new draft
Date: Thu, 04 Sep 1997 14:43:24 -0700
Message-ID: <01bcb97b$91fb1b00$e117379d@natba1.dns.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01BCB940.E59C4300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1702.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1702.0
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

-----Original Message-----
    From: Stan Barber <sob@academ.com>
    To: Nat Ballou <NatBa@ims.microsoft.com>; NNTP Working Group <ietf-nntp@academ.com>
    Date: Thursday, September 04, 1997 8:30 AM
    Subject: Re: ietf-nntp Issues with new draft
    
    
    Nat, 
    
    The x8x response codes were always intended to be used by non-standard 
    extensions. It makes no sense to continue to use them for something
    that will now be a standard extension. If we are going to use the x8x for
    authentication and identification, we can't use them for non-standard
    extensions.
    I'm just concerned that there are already clients and servers that use the 
current response codes.  I understand your reasoning, but it complicates
the transition to the new RFC.

Nat