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

Chris Newman <Chris.Newman@innosoft.com> Wed, 18 December 1996 00:21 UTC

Received: from cnri by ietf.org id aa24856; 17 Dec 96 19:21 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa27235; 17 Dec 96 19:21 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id SAA06240 for ietf-nntp-outgoing; Tue, 17 Dec 1996 18:19:14 -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 SAA06235 for <ietf-nntp@ACADEM2.ACADEM.COM>; Tue, 17 Dec 1996 18:19:12 -0600 (CST)
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by academ.com (8.8.3/8.7.1) with ESMTP id SAA20894 for <ietf-nntp@academ.com>; Tue, 17 Dec 1996 18:19:10 -0600 (CST)
Received: from eleanor.innosoft.com ("port 49469"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.0-8 #8694) id <01ID4FKF3OQAA8C9QW@INNOSOFT.COM>; Tue, 17 Dec 1996 16:18:08 -0800 (PST)
Date: Tue, 17 Dec 1996 16:18:55 -0800 (PST)
From: Chris Newman <Chris.Newman@innosoft.com>
Subject: Re: ietf-nntp My notes from the NNTP WG meeting at the 37th IETF
In-reply-to: <32B72456.52A7@netscape.com>
To: Brian Hernacki <bhern@netscape.com>
Cc: ietf-nntp@academ.com
Message-id: <Pine.SOL.3.95.961217160859.13274J-100000@eleanor.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

On Tue, 17 Dec 1996, Brian Hernacki wrote:
> > 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.

That statement does not reflect current practice.  We need to fix the
interoperability problems caused by "just send <insert localized 8-bit
character set name here>".  It's a bug in the spec, which should be
fixed now while it's easy to change because of the pre-standard status.
I expect resistance from the IESG in moving a spec which ignores 
internationalization.  If an area director states that ignoring i18n won't
hold up the spec, then I'll shut up.