ietf-nntp NNTP and 16-bit charsets

[Russ Allbery]

Charles Lindsey <chl at clw.cs.man.ac.uk> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> What are you classifying as "relaying" if you're using ARTICLE to do it?

> AIUI, if A relays to B, then A says "IHAVE these articles" and then B,
> in a following but separate transaction, says "then please send me these
> ARTICLEs". So although B is using the same command (ARTICLE) as an
> ordinary newsreader would use, he is using it for relaying purposes
> (whether the server at A realises that or not).

No, ARTICLE isn't used for relaying.  See the description of IHAVE in this
draft.  (You may have been confused by the way that the ihave and sendme
control messages work, but they work completely differently than NNTP
does.)

>> RFC 977 refers to other standards which clearly set a 998 octet limit;
>> that's been the only standard to which people can write code.  And the
>> job of this working group is to standardize existing practice.

> The job of this working group is to define a transport.

The job of this working group is to clarify RFC 977 and document existing
practice, not to change the existing protocol as it's currently
implemented.  See the charter of this working group, particularly the last
paragraph.  We've picked up UTF-8 as an exception; I don't think adding
more exceptions is a good idea.  It's more important that we publish
sooner.

> It is the job of USEFOR to set any limits thought necessary.

USEFOR will not be published before this document is.  What USEFOR says is
mostly irrelevant to what should go into this document, except insofar as
we can anticipate the requirements of the next generation of article
standard without swerving from documenting existing practice.  If lines
over 998 octets don't work with existing servers, I think that our charter
is fairly clear when it comes to what we should document.

If they do, that's great, and we can make everyone happy.  Which is why I
want to find out whether there are any existing servers with this problem.

> So the transport standard should define requirements as widely as
> possible, provided it leads to no performance penalty or serious
> conflict with existing usage

Except where that contradicts our charter.

One of the really *good* things about this working group is that it has a
very clear charter.  I've been very glad for that; it provides clear
guidance and limits how far we wander off into time-consuming territory.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>