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:

>>> It might also be argued that forbidding NUL is unnecessary (does any
>>> current implementation in fact have a problem with it?),

>> Yes.

> Fairy Nuff! But it would be of interest to hear which ones, and what the
> problem is.

INN, for one.  And the problem is the obvious one; INN is written in C and
unfortunately treats the body like a NUL-terminated string in a few
places.  It's a bug that should be fixed, but it will require some tricky
surgery (although Katsuhiro may have made forward progress on it with the
data handling rewrite in CURRENT).

> OK, how about:

>     7. When interpreting a multi-line response, the "byte stuffing" MUST
>        be undone; i.e. the client MUST ensure that in, any line beginning
>        with the termination octet followed by octets other than US-ASCII
>        CRLF, that initial termination octet is disregarded. 
>     8. Likewise, the terminating line ".CRLF" (in US-ASCII) MUST NOT be
>        considered part of the multi-line response; i.e. the client MUST
>        ensure that any line beginning with the termination octet followed
>        immediately by US-ASCII CRLF is disregarded.

> Observe the use of words like "interpreting" and "considered". It is up
> to the client exactly when it does and "interpreting" or "considering",
> but it still has a clear obligation to do it sooner or later, certainly
> before any users get to see it.

Eh.  Okay, I can live with that.

> I think some of it needs to be said, but maybe not at such length. But
> it is not a matter of interpretation of the body, but rather one of
> pointing out a limitation of the NNTP transport which those building
> systems around it need to be aware of.

I think that prohibiting NUL already points out that limitation, but I'll
see what other folks think.

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