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

Chris Lewis clewis at nortel.ca
Wed Dec 18 07:43:00 PST 1996


In message "Re: ietf-nntp My notes from the NNTP WG meeting at the 37th IETF", 
'bhern at netscape.com' writes:

>> 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.

The defacto standards (INN + Cnews/Reference NNTP implementation) transport
8-bit article bodies unmolested.  I see no reason to continue to enforce
this _unnecessary_ archaism which has already been purposefully abandoned.

We don't need to deal with charsets - NNTP is a transport mechanism, and
isn't involved in display issues.  The only place where it matters is in
the headers - where we may simply wish to take a similar bailout as,
say, Posix C did, and insist that the headers are, say, UTF8 (where can
I find a listing of this?) or Latin-1.  Indeed, we may well be able
to get away with insisting that the keywords are the current ASCII
encodings, and most of/all of the keyword values are 8-bit.
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.




More information about the ietf-nntp mailing list