* Originally in asian_link   
   * Crossposted in golded   
   * Crossposted in fidosoft.husky   
      
   26 Jun 16 20:45, you wrote to me:   
      
    ml>> it had the last space here when i wrote it   
      
    MK> Okay.  I am betting that it got stripped off somewhere along the path.   
      
   yeah, golded+ stripped the trailing space(s) off the subject line :(   
      
    MK> Same with the Russian alphabet that left here intact and I noticed   
    MK> that it gets truncated at 71 bytes rather than at 72.  I am betting it   
    MK> is because of the 72nd byte being reserved for the null character   
    MK> which used to be a string terminator for long since outdated software.   
      
   #00 still is the string terminator... we used to call them ascii-z strings or   
   c-strings to differentiate them from strings which have a leading length byte   
   and are limited to 255 characters... the only limit i know of for   
   ascii-z/c-strings strings is/was 65535 bytes but that limit might be much   
   higher these days...   
      
    MK> To test this idea Little Mikey reposted the Russian alphabet truncated   
    MK> to 70 bytes to ensure that the last character is a valid 2 byte   
    MK> character and that seems to have remedied the 'problem'.   
      
    ml>> JAM allows for a 100 byte subject line   
      
    MK> Interesting but it still doesn't resolve the REAL issue methinks.   
      
   true... the limit is much more basic... it is built into the transport   
   mechanism...   
      
   ----- fts-0001.016 -----   
      
   [...]   
         someName(n)   - Null terminated string allocated n chars (incl Null)   
         someName{max} - Null terminated string of up to max chars (incl Null)   
   [...]   
    B. Application Layer : the System from the User's View   
      
      1. Application Layer Data Definition : a Stored Message   
   [...]   
                      subject(72)       (* see FileList below *)   
   [...]   
      
    C. Presentation Layer : the User from the System's View   
      
      1. Presentation Layer Data Definition : the Packed Message   
   [...]   
                        subject{72}       (* Null terminated *)   
      
   ----- fts-0001.016 -----   
      
    MK> A couple years ago I heard someone suggest that utf-8 echomail would   
    MK> be the proper solution and leave the rest of the echoareas as ascii   
    MK> ... or even the bogus higher/upper ascii which I still see here and   
    MK> there.   
      
   yeah, we've been hearing that for a long time but no one has done anything   
   about it so far... PKT specs would definitely be fixed/different, though...   
   the question is which is best? binary or text... text is easiest but larger...   
   binary is harder but more compact...   
      
    MK> If you're asking me I am content to leave things as they are but if   
    MK> things must change then utf-8 is most definetly the way to go and then   
    MK> 72 ... errrrr ... 71 characters could be as high as 284 bytes ...   
    MK> errrr 285 bytes if counting a null terminator for 4 byte characters.   
    MK> Having said that I seriously doubt things would get that bloated.   
      
   i dunno... there have been times when folks tried to write their message in   
   the subject line... we see that even in email postings...   
      
    ml>> i've put 150 characters in the subject line   
      
    MK> Not counting the null character I see only 71 bytes AND characters   
    MK> which are replicated in the subject line in this reply to you.  If it   
    MK> hadn't passed through any system before reaching here it would have   
    MK> been honoured by this system at 150 characters and/or bytes although   
    MK> my terminal would have wrapped it at the 106th character no matter how   
    MK> many bytes there might have been in terms of multibyte characters.   
      
   ya wanna hear the real ooogly? when the mail processor (HTP) scanned the   
   message out, it marked the local message header as sent... when it did that,   
   it also truncated the subject line to 71 characters... looks to me like   
   another bug (aka design flaw) (in HPT), to me... only the message attributes   
   should have been adjusted when the local copy of the message was marked as   
   sent... not the subject line or any other header lines that are longer than   
   the PKT spec allows for...   
      
    MK> I honestly believe there should be a limit though but based on   
    MK> characters not bytes.   
      
   agreed...   
      
    MK> Anyhow this has been a real eyeopener.  If you want to continue this   
    MK> conversation I am game.  :-)   
      
   it has been fun but i don't know what else there is to talk about, really...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
      
   ... To an alligator, do we taste like chicken?   
   ---   
    * Origin:  (1:3634/12.73)