Text 6851, 128 rader
Skriven 2013-02-23 17:11:40 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av mark lewis (1:3634/12.42)
Ärende: ö is o umlaut, œ is the British Pound, ¼ is the Yen.
============================================================
Hello mark,

On Wednesday February 20 2013 13:22, you wrote to me:

 ml>> i know this but this factor was decided long ago and only since
 ml>> then have erronoeus implementations been done...

As the "deciders" had no authority, going against their decision can not be
"erroneous".

 MvdV>> So the new developers decided they were not bound by that
 MvdV>> decision.

 ml> highly doubtful... i dare say that the majority ot "new developers"
 ml> never heard of NET_DEV and if they did, they weren't around to read
 ml> those posts and that then means that they did not know of that
 ml> decision so they could not decide that it did not bind them...

Now that you mention it, that is indeed more likely. The result is the same,
the new developers took another fork in the road. We may never know, but my
guess is they would have done that anyway, even if they had know about what
happened in the early ninetees.

 MvdV>> And rightly so, the participants of the late NET_DEV are not an
 MvdV>> authoritative body that can decide for all eternity what the
 MvdV>> next generation may or may not do.

 ml> NET_DEV was never intended to be authoritive... the FTSC publishes
 ml> documents that it accepts as standards... the developers create those
 ml> standards and the software that adheres to them...

Yes, the FTSC does not create the standards, the developers do that. But once
the FTSC has accepted it as a standard, the developers are no longer free to
create something that conflicts with it.

 ml> this is the main reason why i stated in the MAKENLNG echo that they
 ml> should just go ahead and fix the problem(s) regardless of what the
 ml> standard states because they are setting the new standard...

So what is the point of documenting standards if anyone can just ignore them
and do the opposite. Seems like an exercise in futility to me...

 ml>>  when we lost Goram Eriksson, we also lost NET_DEV and thus the
 ml>> discussion area for this work...

 MvdV>> NET_DEV was dead long before Goran's demise. The professional
 MvdV>> programmers left for greener pastures.

 ml> no sir, it was not... it was slower than it had been in years past,

For all intents and purposes, it was dead. The developers that mattered had
left.

 MvdV>> So just consider the kludge lines part of an extended header
 MvdV>> and parse them too.

 ml> it adds complication when one is performing a header only listing

Yes it does.

 ml> (as was given as a recent example by someone else)... especially since
 ml> control lines can be spread throughout the message body as has been
 ml> done in the past...

Too bad.

Look, I did not invent this mess. I was not me who decided every baylifwick in
the world should have their own language. I was not the architect, nor the
builder, not the realtor of the Tower of Babel. Also it was not me who decided
that every bayliffwick should not just have its own language, but also its own
character set for the written version.

Neither was it me who decided that ASCII should be enough for everyone. I am
also not the one who later decided that CP437 should be enough for everybody.
So don't blame me.

 MvdV>>> Sorry, but current practise is that text in the header uses
 MvdV>>> the same encoding as that for the message body. Like it or
 MvdV>>> not, it IS current practise.

 ml>> i definitely do not agree there...

 MvdV>> You can disagree all you want, that does not alter the facts.

 ml> sure it does... /some/ current practise may be doing that but not
 ml> *ALL* current practise is doing it...

The fact is that the main stream took another fork as the one that you are on.
The reason is simple: limiting the text in header fields to CP437 just does not
work. You do not really believe that a Russian writing in cyrilic is does NOT
use that same character set in the subject field of messages? Of course he
does! having the message body in cyrilic and the subject in CP3437 just does
not work for them.

So like it or not, they use the same character encoding for the message body
and the message header.

Yes, that means having to hunt for the CHRS kludge if you want to properly
display the text in the header.

It could have been avoided if it had been done right from the start and if the
founding fathers had made provisions to extend the header in some way, but they
didn't, they made the header very rigid. So instead of putting the encoding
information in the header where it belongs, it had to be in a kludge line in
the message body. Not nice, but that is the way it is.

 MvdV>> You can moan and groan, stamp your feet and dig up 20 year old
 MvdV>> "decisions", it is not going to turn back the clock. The ASCII
 MvdV>> only age is over and the default encoding is not CP437.

 ml> sure it is... it is one of several used throughout the network... so
 ml> please correct your statement by replacing "the" with "a" and removing
 ml> "not"...

No. One can not have more than one default.

The fact is that the new generation of (mostly Russian) developers took another
fork. They are not going back to what you want - CP437 only in the header -
because that does not work for them.

So... you can either track back to the forking point and follow the rest, or
you can stay on your own.


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20110320
 * Origin: http://www.vlist.org (2:280/5555)