Why the special character restriction?

[Anne Wilson]

Russ,

Thanks tons for the info!  We'll be ruminating over this.

Anne

Russ Allbery wrote:
> Anne Wilson <anne at unidata.ucar.edu> writes:
> 
> 
>>Setting aside the issue of resources, sounds like you're saying that the
>>only potentially "unsolvable" problem (without mucking with the
>>protocol) is that CRLF indicates the end of a message, which could be
>>erroneous in the context of binary data.
> 
> 
> Right.
> 
> 
>>Because we currently do mainly streaming transmission, for our purposes 
>>it might be sufficient to simply add a byte count parameter to TAKETHIS. 
>>Do you think more commands would be necessary?  (Although I can imagin 
>>cases where we might want to do some batched transmission.)
> 
> 
>>From an NNTP protocol perspective, you need new versions of TAKETHIS,
> IHAVE, ARTICLE, BODY, and POST.  I think that's a complete list.
> Obviously, you won't need all of those initially depending on what
> portions of the news system that you use.
> 
> Adding the new commands would be relatively straightforward in INN if
> INN's problems with nul characters were fixed; that's the hard part of the
> work just because there are so many places those problems can sneak in.
> 
> 
>>Also, are you saying that with INN I can have CR and LF in my data as
>>long as they're not CRLF?  (LFCR being okay?)
> 
> 
> INN doesn't care at all about CR and LF in any variation and order other
> than logging messages if it sees unmatched CR or LF characters (although
> such articles are technically in violation of the NNTP standard).
> 

-- 
***************************************************
Anne Wilson			UCAR Unidata Program		
anne at unidata.ucar.edu		       P.O. Box 3000
               			  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://my.unidata.ucar.edu/
****************************************************