[NNTP] Re: New NNTP drafts approaching IETF Last Call

[Mark Crispin]

On Thu, 24 Mar 2005, Clive D.W. Feather wrote:
> The responses from HDR and OVER are derived from header contents and carry
> the same requirement. This requirement matches both current practice and
> the principle that this is Usefor territory, not ours.

Sorry, that doesn't wash.

First, when "current practice" is broken, it needs to be fixed.  "Just 
send 8-bits" was wrong-headed 15 years ago and it remains wrong-headed 
today.  I see your persistance in this matter as being a underhanded 
attempt to preserve "just send 8-bits" and avoid making the very difficult 
decisions necessary to establish true multilingual interoperability.

Second, it doesn't work to punt a question to Usefor when Usefor has 
nothing to say on the matter.  We are talking about responses to the HDR 
and OVER commands in NNTP, not message headers.

The only way that you can do this is to establish an explicit requirement 
for Usefor to establish a means to declare the character set of 8-bit 
characters in HDR and OVER responses in NNTP.  If that is not in Usefor's 
charter, then you must convince Usefor to accept that as a work item.

I offered you an easy way out; to use SHOULD to establish UTF-8 as a goal 
state but allow other character sets in legacy uses.

Since you've rejected that, what's left is the hard way.  Either you add 
an explicit character set tag to the HDR and OVER responses, or you 
convince Usefor to add such a tag (ala MIME quoted-words) to all 8-bit 
texts.

> This is
> because this text is generated by national or regional authorities and we
> have no practical power to order them to do anything; we can only
> encourage. While a hierarchy works in KOI-8, they're hardly likely to want
> this text to be UTF-8.

What are these "national or regional authorities"?  In particular, is 
there *any* national or regional government which has passed a law that 
says "newsgroups are to be in KOI-8"?

> Finally there is HELP. This is unstructured text designed to match
> purely local needs. Currently it's like an article body - any octets
> allowed except NUL, CR, and LF not in CRLF pairs. It normally gets dumped
> from a file on the server or some similar approach. Any change in
> requirements is going to be widely ignored.

I don't see how a "I don't want to fix it, so I refuse to allow it to be 
fixed" attitude is at all helpful.

Quite frankly, if NNTPv2 doesn't fix the problems in NNTP, or worse, 
establishes a principle that it's alright to disregard what you don't 
like, then I see no point to having an NNTPv2 document.

Time and time again, decisions were made in IMAP that some people did not 
like.  But since the document took a position, it was clear what complied 
with the specification and what did not.

The only reason why the text in HELP is random is because the 
specification gives no guidance as to what that text should be.  Rather 
than being "widely ignored", I suspect that most implementors try to do 
the right thing if they had some guidance as to what the "right thing" may 
be.

All that's needed is a simple statement to the effect that HELP texts must 
be in UTF-8 to comply with the NNTPv2 specification.  That doesn't "must 
be in English" or any other such thing that inflames national pride.  It 
simply indicates that, if text is not ASCII, it be something that can be 
rendered propertly by a compliant NNTPv2 client.

I may not be able to read Cyrillic; but I can recognize Cyrillic text and 
I know native speakers who can interpret it for me.  I can do this because 
the text, being UTF-8, will render properly.  If it's some random 8-bit 
string, it may take a considerable amount of time to determine the correct 
character set.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.