TIP: Click on subject to list as thread! ANSI
echo: fidosoft.husky
to: MAURICE KINAL
from: MARK LEWIS
date: 2016-06-27 05:27:00
subject: 1234567890123456789012345

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

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.