Why the special character restriction?

[Anne Wilson]

Russ,

Thanks much for the helpful response.

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.

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.)

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?)

Anne



Russ Allbery wrote:
> Anne Wilson <anne at unidata.ucar.edu> writes:
> 
> 
>>But, I still get asked a question for which I have no good answer.  Why
>>the continued restriction on special characters in the message body? Why
>>can't the message body just be a black box?
> 
> 
>>It's not a big deal for us to do a simple encoding because we visit
>>every byte of a data product anyway in order to compute a
>>signature. But, if we didn't want to compute a signature the cost of
>>encoding would be much harder to swallow.
> 
> 
> There are several problems:
> 
> The NNTP standard requires that all messages end in CRLF.  There's no way
> around this without inventing a new set of commands that allow arbitrary
> binary data.
> 
> INN can't cope with nul characters in the message body because it uses too
> many of the standard C string functions.  This should be fixable; it will
> just require a fair bit of work to flush out all of the problems with all
> of the different utilities.  I'd love to do this work but have very, very
> limited time to work on INN right now, unfortunately.  (As does nearly
> everyone else working on INN.)
> 
> There are some requirements that INN enforces because they're requirements
> of the underlying article format standards, although it already waives
> some of them, like unpaired CR or LF.  This should really be a
> configurable option, but again will require some implementation work.
> 

-- 
***************************************************
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/
****************************************************