Text 6715, 140 rader
Skriven 2013-02-20 13:45:34 av mark lewis (1:3634/12.42)
   Kommentar till text 6686 av Michiel van der Vlist (2:280/5555)
Ärende: LOL!
============
 MvdV>> It DOES carry the o umlaut in the header field.

 ml> that is NOT an ö single byte character...

 MvdV> Indeed, it is the two byte UTF-8 encoding fot the small o with
 MvdV> diaresis. Your point?

two characters != one character

 ml>> the actual contents from the PKT's To field are

 ml>> 000AA0  31 38 00 42 6A C3 B6 72 6E 20 46 65 6C 74 65 6E  18
 ml>> Bjöœ•£rn Felten

 MvdV>> Which is correct. C3 B6 is the UTF-8 code sequence for the o
 MvdV>> umlaut. My message was encoded in UTF-8, signalled by a CHRS:
 MvdV>> UTF-8 4 kludge.

 ml> again, it is incorrect implementation

 MvdV> Who are you to decide it is incorrect?

who are you to decide that it is correct? isn't is up to the developers to
decide that so that their software can easily interoperate with all the other
software being used? it definitely isn't the FTSC's decision or that of its
chairperson or individual members...

 ml> and is apparently the cause of many character conversion 
 ml> discussions and arguments...

 MvdV> So what's new in Fidonet?

so you propose to continue the fighting and arguing rather than foistering
cooperation and fellowship?

 ml> that no one has actually dug into all of the software to determine 
 ml> this until now is even more telling and depressing...

 MvdV> What actually is depressing is that we now seem to have a new
 MvdV> stranglehold coming up. Now that some have realised the ASCII
 MvdV> only stranglehold was too tight, it seems to be replaced by a new
 MvdV> one: The CP437 stranglehold. 

no... sorry... your vision is narrow and jaded... the new stranglehold coming
up is the forcing of UTF-8 on all systems... even those which cannot handle
it...

 MvdV> Sorry, you are 20 years behind. The rest of the world has moved
 MvdV> in and decided that CP437 only won't do either.

that's fine... there're plenty of others to choose from... as long as they are
not /forced/ on everyone... no one forced the existing stuff on anyone..
everyone chose to use it or develop their own... but everything was still
compatible... the new proposals are going to force breakage of one sort or
another...

 ml>  especially since some are expecting that their software is 
 ml> compliant and doing things correctly when compared to all other 
 ml> software and now it comes out that it is not compliant with 
 ml> existing software :/

 MvdV> Software written under the ASCII only or CP437 stranglehold is
 MvdV> still complient as long as it sticks to ASCII or CP437 only .

the problem is the /USERS/ loosing out when they cannot read what should be a
simple message... email and news are still plain ASCII text... if you don't
believe that, then you should look at the source code of the messages... even
those carrying pictures are in plain ASCII text...

 MvdV>> Sorry to burst your bubble, but CURRENT practise is that text
 MvdV>> in the header field is NOT limited to ASCII only. Has been that
 MvdV>> way for at least ten years.

 ml> where is this documented?

 MvdV> FTS-1

 ml>> yes, they would indicate the same if ù was used

 MvdV>> It WAS used!

 ml> well the problem exists and your message shows it plainly as well as
 ml> excaberating it... i never typed in two characters for ö

 MvdV> Neither did I.

and there's the broken aspect...

 ml> but yet your quotes seem to show that i did...

 MvdV> Only because your reader fails to realise that a multi byte
 MvdV> encoding scheme is used. It is YOUR reader that fails to display
 MvdV> oit properly. Your loss. 

if you didn't type in two characters, how can you say that your software is
right for generating two??

 ml>  i did not so please FixYerShit

 MvdV> Request denied.

pffffft ;)

 ml>  and stop showing that i wrote things that i didn't...

 MvdV> I didn't. All I did was use a different encoding scheme. It is
 MvdV> YOUR software that presents it to you as two characters.

which your software broke by not rendering it as i entered it... especially
when it came back to me...

 ml> it is even worse in the HEX table output from the raw PKT... your
 ml> quote shows too many characters for Björn's first name

 MvdV> Only under the erroneous assumption that one character equals one
 MvdV> byte. 

nope... the HEX table showed the two bytes... your software then expanded the
actual rendering of each of them into two byte each... now you have 4 bytes
representing two which represent one... how is anything supposed to decode that
properly?? has no one learned anything from m$' mistakes with their web
server??

 ml> BTW: here's a neat little item... i'd bet your editor doesn't quote it
 ml> back properly so that i can see it exactly as i entered it without you
 ml> jumping thru some hoops...

 ml>  ÉÍ»ÉÍ»
 ml>  º ù ³
 ml>  ÈÄÙÈÄÙ

 MvdV> So?

interesting... what hoops did you jump through? you had to have changed
something...

)\/(ark

--- 
 * Origin:  (1:3634/12.42)