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

[Charles Lindsey]

In <Pine.WNT.4.63.0503141626430.2332 at Tomobiki-Cho.CAC.Washington.EDU> Mark Crispin <MRC at CAC.Washington.EDU> writes:

>I found something right away:

>The text in section 3.2:

>    Note that texts using an encoding (such as UTF-16 or UTF-32) that may
>    contain the octets NUL, LF, or CR other than a CRLF pair cannot be
>    reliably conveyed in the above format (that is, they violate the MUST
>    requirement above).  However, except when stated otherwise, this
>    specification does not require the content to be UTF-8 and therefore
>    it MAY include octets above and below 128 mixed arbitrarily.

>seems silly to me.  Nobody sends UTF-16, UTF-32, UCS-2, or UCS-4 data in 
>Internet protocol commands.  Viewed one way, it's a tautology; viewed 
>another, it confuses contexts.

Well yes and no. If someone uses one of those charsets in an article body
then it will have to use a Content-Transfer-Encoding such as Q-P or Base64
(or even, our dead bodies not withstanding, yEnc). So then what NNTP sees
is actually just ASCII (or something else in the case of yEnc, though it
is guaranteed not to contain NUL or naked CR or LF).

However, the wording in the present draft is slightly misleading, since it
seems to suggest that the arbitrary mixture of octets might contain NUL or
naked CR or LF. So perhaps the second sentence would better say:

"However, except where given a specific interpretation by this document,
the content {of this multiline response} can be any sequence of octets
(not necessarily interpretable as UTF-8), just so long as it does not
include the octets NUL, CR of LF (other than as CRLF)."

That is as far as this document should go. What headers and bodies
actually contain is a matter for USEFOR (which does address such issues)
and its proposed I18N extension (which will have to consider them
carefully). NNTP is a pure transport protocol and what is is required to
transport is (and always has been) sequences of octets excluding NUL and
naked CR and LF, and all it actually has to do with the articles it
transports is to pull message-ids out of them and maybe the contents of
certain headers for OVER, HDR, etc.

Certainly, it does not need to be aware of MIME, because by the time it
sees the articles all the MIME in them has been encoded away out of sight,
only to be seen when it is unwrapped at the final destination.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5