IETF Logo Mail Archive

Re: ietf-nntp My notes from the NNTP WG meeting at the 37th IETF

Brian Hernacki <bhern@netscape.com> Tue, 17 December 1996 22:55 UTC

Received: from cnri by ietf.org id aa22899; 17 Dec 96 17:55 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa25274; 17 Dec 96 17:55 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id QAA05980 for ietf-nntp-outgoing; Tue, 17 Dec 1996 16:52:54 -0600 (CST)
X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.3/8.7.3) with ESMTP id QAA05975 for <ietf-nntp@ACADEM2.ACADEM.COM>; Tue, 17 Dec 1996 16:52:52 -0600 (CST)
Received: from c3po.mcom.com (h-205-217-237-46.netscape.com [205.217.237.46]) by academ.com (8.8.3/8.7.1) with ESMTP id QAA20436 for <ietf-nntp@academ.com>; Tue, 17 Dec 1996 16:52:50 -0600 (CST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by c3po.mcom.com (8.7.5/8.7.3) with ESMTP id OAA13976 for <ietf-nntp@academ.com>; Tue, 17 Dec 1996 14:52:17 -0800 (PST)
Received: from ventnor.mcom.com ([207.1.137.53]) by dredd.mcom.com (Netscape Mail Server v2.02) with SMTP id AAA26778; Tue, 17 Dec 1996 14:52:16 -0800
Message-ID: <32B72456.52A7@netscape.com>
Date: Tue, 17 Dec 1996 14:53:10 -0800
From: Brian Hernacki <bhern@netscape.com>
Organization: Netscape, Floating Point Division
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.5 sun4u)
MIME-Version: 1.0
To: Chris Newman <Chris.Newman@innosoft.com>
CC: ietf-nntp@academ.com
Subject: Re: ietf-nntp My notes from the NNTP WG meeting at the 37th IETF
References: <Pine.SOL.3.95.961217120041.13274A-100000@eleanor.innosoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

> In addition, I think this group needs to face the i18n problem and solve
> it, as painful as that may be.

As attractive as solving i18n in NNTP is, I don't think it's in the
scope of our charter. RFC977 is pretty clear on what it expects and
handles in terms of charsets, etc. Adding functionality for charset
support to 977bis or changing the way the existing base protocol works
is not what this group is suppose to do.

2.2.  Character Codes

   Commands and replies are composed of characters from the ASCII
   character set.  When the transport service provides an 8-bit byte
   (octet) transmission channel, each 7-bit character is transmitted
   right justified in an octet with the high order bit cleared to zero.

--brian

v2.8.7 | Report a Bug | By Email