Text 16862, 129 rader
Skriven 2013-11-23 23:29:29 av mark lewis (1:3634/12.71)
     Kommentar till en text av Maurice Kinal (1:261/38.9)
Ärende: utf-8 fidonet messaging
===============================
On Sun, 24 Nov 2013, Maurice Kinal wrote to mark lewis:

 MK> Hey mark!

 ml> mail processors have no reason to be looking at the content of a
 ml> message

 MK> Then how do they know what AREA to toss it to?  Isn't that
 MK> particular infomation the very first bytes of the message body (ie
 MK> content of a message)? 

the area line is a control line... i was speaking more specifically to the
content of the body...

 ml> only the headers and some control lines

 MK> The control lines are part of the message body from what I see in
 MK> the raw pkts here.  Granted that is probably a lousy place for them
 MK> but that is where they are.

because there is/was no other place for them... but they are not message body
content... they are control lines... they must be on a line by themselves and
their first character must be CTRL-A... there are a few, very few, control
lines that do not start with CTRL-A but they are still the only thing on the
line... control lines are also not restricted to coming directly after the
header... they may be anywhere after the message and before the message
terminator...

 MK> In the situation here, I keep the original pkt intact and only
 MK> process the vital information extracted to a temporary file which
 MK> doesn't contain all the information that is maintained (unaltered)
 MK> in the original pkt.  In the temporary file there is absolutely
 MK> nothing from the pkt header and only the ascii data (date, to,
 MK> from, subject) from the msg header(s).  Am I missing anything
 MK> vital?  I still see most of the control lines but have started to
 MK> strip them out of the temporary file when I actually view them,
 MK> such as PATH and SEEN-BY.  So far I haven't seen anything I would
 MK> use them for being an enduser, which happens to be my target
 MK> audience.

no different than any bbs or FTN system which stores the messages for
presentation to a user...

 ml> what are you smoking over there?

 MK> Nothing at the moment.  However I am aware there could be something
 MK> worth smoking in an attempt to figure out what a mail processor is
 MK> *not* doing as you seem to be implying.  

you stated that there was a mail processor that sidelined messages due to
content not matching what the control lines stated... i asked you to elaborate
and we're now here...

 MK> Please feel free to
 MK> enlighten if you are aware of a smokable material that might help
 MK> illuminate what a mail processor's job should entail other than
 MK> what it isn't supposed to be doing.  At the moment I am not getting
 MK> it at all.  :-/

what we have here... is a failure to communicate... read what you wrote in the
quote below...
 

 MK> Anyhow I do not "catch" or sideline any mail but am aware of at
 MK> least one mail processor that will sideline mail if it contains any
 MK> non-ascii and non-utf8 characters within a message flying the
 MK> 'CHRS: UTF-8 4' kludge.  I am not positive how sensitive it is to
 MK> the '4' level part of the CHRS kludge. 

 ml> that is so twisted i can't even follow it

 MK> Simple.  0x94 isn't a valid utf-8 code.  Also it isn't an ascii
 MK> code, which range from 0x00 to 0x7f.  

you (and others) are being much too strict in your interpretation but i guess
that's par for the course :?

 MK> As for your sent 0xc3 0xb6 combination, the conversion process 
 MK> assumes they are two non-ascii characters instead of one utf-8 
 MK> character which your editor is identifying as 'CHRS: IBMPC 2'.

"ascii characters" [sigh] is where the too strictness comes from... there are
folks still debating this even after all this time...

 MK> Those particular CP437 characters correspond to line/box drawing 
 MK> characters.  However 0xc3 .AND. 0xb6, which is 0x0f6 in 
 MK> utf8-speak, is equivalent to 0x94 in CP437. That is why I asked 
 MK> for your confirmation.

the problem, again, is that some software translates them when it should not...
that was my sole point...

 MK> Seems pretty clear to me especially without smoking material.  ;-) 

 ml> i sent the first byte sequence as a test to see if other software
 ml> would specifically mistake it for a multibyte UTF-8 character

 MK> It would have if you hadn't included the following 0x94 character. 

why? it should NOT have because the CHRS line stated what codepage to use... it
was definitely NOT UTF-anything ;)

 MK> Here is a nice simple test;

 MK> ------------------- commandline magic starts
 MK> echo -e '\xc3\xb6' | file -b -
 MK> echo -e '\xc3\xb6 \x94' | file -b -
 MK> ------------------- commandline magic ends

that "test" as you call it is useless on a majority of systems... sorry...

 MK> I get a kick from the output of the second command.  Stinkin'
 MK> DOS-think.  

it has nothing to do with "dos-think"... perhaps you forget where fidonet
started? it certianly wasn't with MSDOS machines... think about it, eh?

 MK> Anyhow the non-iso part is right since if you look on
 MK> any of the 8 bit iso character tables 0x94 is a control code.  Same
 MK> with 0x094 in utf-8.  Sending it in messages will definetly tick
 MK> off many people using iso codepages which are many. I am guessing
 MK> WAY more than that use CP437.  ;-)

a "control code"?? really? used for what purpose??

)\/(ark

--- FMail/Win32 1.60
 * Origin:  (1:3634/12.71)