REPLY: 8129.binkd@1:103/705 264f4252   
   MSGID: 2:280/464.47 61eb14cd   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: UTF-8 4   
   TZUTC: 0100   
   TID: CrashMail II/Linux 1.7   
   Rob wrote (2022-01-20):   
      
    >>>> And it's only a problem with filenames that contains a whitespace   
    >>>> character.   
    RS>>> It's also a problem for filenames that contain any other "unsafe"   
    RS>>> characters that "SHOULD" (according to FTS-1026) be escaped.   
      
    >> You mean like 0x00 to 0x1F (control chars) and backslash (0x53)? How   
    >> often do you use these in filenames? ;)   
      
    RS> Preferably, never, but I'm not in control of what characters are used in   
    RS> filenames received BinkP, the sender is.   
      
   I wanted to express that in practice other (binkp-) reserved characters than   
   whitespace are rarely used in filenames.   
      
    RS> Ideally, the BinkP spec would have been even *more* restrictive in the   
    RS> filename characters allowed (escaped or not), because filenames with   
    RS> colons, semicolons, asterisks, question marks and vertical-bars (pipes)   
    RS> are *not* what I would call "safe", yet they're expressly allowed as   
    RS> "safe" in the spec. :-(   
      
   I think "safe" means safe in relation to the protocol, not filenames. Most   
   unix filesystems do allow any character except "/" and \0. (http   
   ://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations)   
      
   The protocol should be agnostic to filename restrictions of different   
   filesystems. It should not modify filenames and transmit them transparently.   
   The receiving system can then decide how to store them and which characters   
   should be escaped or changed. Other protocols like HTTP or SFTP do the same.   
      
   How forbidden characters would be saved should have been specified in FTS-5005   
   (Advanced BinkleyTerm Style Outbound flow and control) though.   
      
   It was a bit stupid to remove the UTF8 extensions from the binkp spec. What   
   happens to character >127 in filenames (and other strings) is undefined.   
      
   I also wonder why control characters have to be escaped in a binary protocol.   
   And why whitespace was chosen as a delimiter. They could have used \0 and   
   disallow \0 in strings. Then there wouldn't be any need for escapology. (Or   
   instead of using a delimiter between parameters make everything (type-)   
   length-value).   
      
   But it is what it is.   
      
    * Origin: Birds aren't real (2:280/464.47)   
   SEEN-BY: 1/123 15/0 30/0 80/1 90/1 103/705 105/81 106/201 114/709   
   SEEN-BY: 120/340 123/131 124/5016 129/305 330 153/757 7715 154/10   
   SEEN-BY: 203/0 218/700 221/0 1 6 226/30 227/114 229/110 200 307 317   
   SEEN-BY: 229/424 426 550 664 700 240/1120 5832 249/206 266/512 280/464   
   SEEN-BY: 280/5003 5555 282/464 1038 292/854 8125 301/0 1 101 113 123   
   SEEN-BY: 301/812 310/31 317/3 320/219 322/757 335/364 341/66 234 342/200   
   SEEN-BY: 396/45 423/120 460/58 633/280 712/848 770/1 920/1 2452/250   
   SEEN-BY: 5020/1042 5058/104   
   PATH: 280/464 301/1 229/426