ietf-nntp NNTP and 16-bit charsets

[Charles Lindsey]

In <20010507110359.Q26621 at demon.net> "Clive D.W. Feather" <clive at demon.net> writes:

>>     7. Likewise, the terminating line ".CRLF" (in US-ASCII) MUST NOT be
>>        considered part of the multi-line response;

>s/;/ (but the preceding CRLF is part of the last line of the response);/

More or less. See below.

>>        NOTE: Texts using charsets which represent characters as sequences
>>        of 16 or 32 bits (e.g. UCS-2 and UCS-4) cannot be reliably conveyed
>>        in the above format.

This bit was changed yesterday in response to Russ.

>> The text forming the header and body of the
>> message to be posted MUST be sent by the client in the format already
>> defined for multi-line responses

>s/already defined/defined above (section 4)/

OK.

Here, again, is the full text.

Each response MUST start with a three-digit response code that is
sufficient to distinguish all responses. Certain valid responses are
defined to be multi-line; for all others, the response is contained in a
single line. All multi-line responses MUST adhere to the following format:

    1. The resonse consists of a sequence of one or more "lines", each
       being a stream of octets ending with 0x0d0a (US-ASCII CRLF). Apart
       from those line endings, the stream MUST NOT include the octets
       0x00, 0x0a, or 0x0d (US-ASCII NUL, LF, and CR).
    2. The first such line contains the response code as with a single
       line response.
    3. If any subsequent line begins with the "termination octet" (0x2e or
       US_ASCII "."), that line MUST be "byte-stuffed" by pre-pending an
       additional termination octet (0x2e) to that line of the response.
    4. The lines of the response MUST be followed by a terminating line
       consisting of a single termination octet (0x2e or US_ASCII ".")
       followed by CRLF in the normal way. Thus a multi-line response is
       always terminated with the five octets "CRLF.CRLF" (in US-ASCII).
    5. There is NO limit on the length of a line.
    6. 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.
    7. 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; (the first CRLF of the
       terminating "CRLF.CRLF" is, of course, part of the last line of the
       response).

       NOTE: Texts using encodings (such as UTF-16 or UTF-32) that may
       contain the NUL octet or the CR or LF octets in contexts other than
       the CRLF line ending cannot be reliably conveyed in the above
       format.

       Note also that, although this standard does not limit the length of
       a line in any way, the standards that define the format of articles
       may do so.

In the POST command:

If posting is permitted, the article MUST be presented to the server by
the client in the format specified by RFC 1036 (or by any of its
successors or extensions). The text forming the header and body of the
message to be posted MUST be sent by the client in the format defined
above (section 4) for multi-line responses (except that there is no
initial line containing a response code).  Thus a single period (".") on a
line indicates the end of the text, and lines starting with a period in
the original text have that period doubled during transmission.

In the IHAVE commnd:

If transmission of the article is requested, the client MUST send the
entire article, including header and body, in the format defined above
(section 4) for multi-line responses (except that there is no initial line
containing a response code). Thus a single period (".") on a line
indicates the end of the text, and lines starting with a period in the
original text have that period doubled during transmission. The server
MUST then return a response code indicating success or failure of the
transferal of the article.


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