XPost: news.software.readers   
   From: oneingray@gmail.com   
      
   >>>>> Barry Margolin  writes:   
   >>>>> Ivan Shmakov  wrote:   
   >>>>> Whiskers  writes:   
      
   [...]   
      
    >>> ]$ telnet localhost nntp   
      
    >> Won't telnet(1) go nuts should the article being fetched happen to   
    >> contain an \xFF octet?  FWIW, I'd advocate for using nc(1) (AKA   
    >> Netcat) here instead.  (Why, some of my hosts have no telnet(1)   
    >> client installed at all.)   
      
    > NNTP is a text protocol, binaries are sent encoded in ASCII (either   
    > base64   
      
   	There also is the case of non-ASCII (as in: UTF-8) plain text.   
   	Which may be either encoded in 7-bit (either quoted-printable or   
   	Base64), or left "unencoded" 8-bit.   
      
   	My understanding is that the major NNTP implementations of today   
   	allow for 8-bit-clean transfer (with the obvious exception for   
   	\x00, \x0A, \x0D), and RFC 5537 seem to prohibit an NNTP   
   	transport from munging the content, whether the most significant   
   	bit is set or not.  (Although an implementation is still allowed   
   	to reject an article it isn't capable of passing through.)   
      
   	Consider, e. g.:   
      
   --cut: urn:ietf:rfc:5537 --   
      Transports for Netnews articles MUST treat news articles as   
      uninterpreted sequences of octets, excluding the values %d00 (which   
      may not occur in Netnews articles), %d13, and %d10 (which MUST only   
      appear in Netnews articles as a pair in that order and which,   
      together, denote a line separator).  [...]   
   --cut: urn:ietf:rfc:5537 --   
      
    > or uuencoded, I think).   
      
   	Somehow, I doubt MIME allows for uuencoded data.  And while such   
   	an encoding doesn't require MIME, I know of no good reason to   
   	use it instead of "properly MIMEd" Base64.   
      
    > There shouldn't be any \xFF octets.   
      
   	Specifically, while UTF-8 doesn't seem to use \xFF, ISO-8859-1   
   	assigns it for LATIN SMALL LETTER Y WITH DIAERESIS, windows-1251   
   	for CYRILLIC SMALL LETTER YA, and so on.   
      
    > Also, when telnet connects to a non-default port, it doesn't try to   
    > negotiate TELNET options.  Does it still react to them if it receives   
    > them?   
      
   	Frankly, I don't know for sure.  My guess is that it may vary   
   	between implementations.  I'd prefer to be on the "safe side,"   
   	however, which is: nc(1).   
      
   --   
   FSF associate member #7257	http://hfday.org/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)