On Tue, 18 Feb 2014, Nicholas Boel wrote to mark lewis:

 ml> no one person moderating one FDN threatened anyone... the decision to
 ml> attempt enforcement again was made higher up than that my concensus of
 ml> the members of the network doing the distributing... it was not one
 ml> FDN area person...

 NB> "Enforcement again was made higher up than that." Now THAT explains
 NB> EVERYTHING!

no it does not... not when you TAKE THINGS OUT OF CONTEXT... you
specifically left out "the decision to attempt"... -=*that*=- is
an extremely important part of the statement...

 NB> At least now I know what crappy software is having problems with
 NB> it. Thanks  for the heads up. :)

you do?? what software would you be thinking of? remember, we've talked
about several DIFFERNT aspects of files' descriptions...

  1. descriptions from TICs' DESC line used in announcement posts
  2. descriptions from TICs' LDESC lines used in announcement posts
  3. descriptions from files' FILE_ID.DIZ used in announcement posts
  4. descriptions from TICs' DESC line used in file area databases
  5. descriptions from TICs' LDESC lines used in file area databases
  6. descriptions from files' FILE_ID.DIZ used in file area databases

AND we must also consider the SYSOPS CHOICE TO WRAP OR NOT... 
 1. the DIZ creator cannot force sysops to not wrap the DIZ contents...
 2. the archive creator cannot force sysops to not wrap the DIZ contents...
 3. the hatcher cannot force sysops to not wrap the DESC, LDESC or DIZ contents...


 ml> i did not jump your case, nick... as i stated before, all i've tried
 ml> to do was to explain robert's post and the whys behind it... nothing
 ml> more... anything else read into that is a huge misunderstanding and
 ml> misreading of my post(s) on this subject...

 NB> And I kept telling you that I wasn't going to change anything. Yet
 NB> you  continually replied like I gave a shit. 

no i did not... i kept replying because you never acknowledged the basic
points of the problem... the main one being SYSOP'S CHOICE to wrap or
not... you asked for the specs and i showed them to you... those specs
state no special formatting or centering and the like... you only looked at
the ascii character aspect and convienently left out the no special
formatting aspect of the spec...

 NB> If that means my infopack won't be  hatched out on that FDN, so be 
 NB> it. I don't really look at that as my loss. :) 

:shrug:

 NB> If the "enforcement" wants to hold Fidonet back from continuing on
 NB> into the  future, that's their problem. Some of us want to make
 NB> Fidonet better, rather  than stick to '80s technology and ideas.
 NB> Some of us are just sitting back and  waiting patiently for the
 NB> right time. :)

this is another problem... others forcing their "advanced ways"
down others throats... just like morals, religion and penises, you can do
with them what you want but don't try to shove them down others throats
without a fight...

 NB>> If Allfix had a Linux version, I'm sure I would have used it by
 NB>> now.

 ml> do you not run any DOS doors on your system? allfix should be able to
 ml> run just like they are... all it needs is access to the PKTs or MSG
 ml> netmail area as well as the files areas...

 NB> Somewhere we lost the fact that I only use currently maintained
 NB> software, and  just as well, most (if not all) of it is open
 NB> source.

allfix is currently maintained... it isn't open source, though... and what
you or i use has not been part of the discussion of the problem... the
discussion of the problem is file descriptions that turn into shit when
they get wrapped or displayed by some sysop's software of choice... all the
rest has been diversionary and only taken away from the discussion of the
actual problem...

 NB>> My BBS seems to display all of these file_id.diz's just fine over
 NB>> here as  well. I'm definitely not seeing the same issue you are.

 ml> then maybe you or your software have figured out how to handle CP437
 ml> characters without them being translated when other CPs are being
 ml> used...

 NB> Maybe..

no maybe about it... i peeked under the hood of your (and similar) site(s)
and discovered at least one aspect of the secret... too bad it may not work
in the future when support for it is dropped by the masses... but for now
it works... when support is dropped, you'll be in the same boat as those
who have been dealing with the problem for the last several decades and
nothing your software can do will fix it without a major change that
appears to be a long way off...

 ml> i never targetted you, nick... i replied to your reply because you
 ml> didn't seem to understand the original request and why it was made in
 ml> the first place... nothing more...

 NB> I don't agree with the request, and I'm not here to watch
 NB> technology go back  in time, either.

the technology hasn't changed in decades... it isn't advancing and it isn't
going back in time... it is, in fact, stagnant and not moving at all... it
is called "retro" for a reason ;)

 ml> hell no... as i've stated several times, i am/was trying to explain
 ml> the problem to you but all you seem to want to do is look at your
 ml> system and use it to justify causing others' systems' files areas to
 ml> look like crap because someone wants to draw fancy stuff in their file
 ml> descriptions...

 NB> My system as well as other's I've pointed out that work fine are
 NB> justification  enough for me. That some people haven't moved on
 NB> from the 90s and upgraded  their systems, using newer, updated, and
 NB> even some currently maintained  software in the process where all
 NB> these issues (amongst many others) could  have been resolved years
 NB> ago.

sorry but again, it is not the software and its operation... it is sysop's
choice #1... another aspect is other software out of our control and how
that software displays the results...

 ml> right... and those using spacing to format ascii characters to form a
 ml> type of logo drawn with ascii characters...

 NB> Looks good to me! You're explanations and requests are directed at
 NB> the wrong  guy here, Mark. I've been doing custom file_id.diz's for
 NB> people since the  early 90s, and have participated in many ANSI art
 NB> groups in the past as well  (even the most recent release a couple
 NB> months ago).

that's all fine and good but it still doesn't negate the fact that the spec
is being broken and all that is being sought is for the spec to be
honored... you say you honor it but apparently not all of it... that
statement is not aimed directly at you, personally, either...

 ml> other than the spaced out formatting, the characters used are ok
 ml> although not specifically within the realm of what the spec was trying
 ml> to convey...

 NB> How do you know what the spec is trying to convey? 

because i was there when it came out, for one thing... i participated in
many discussions on several networks about things like it... i used to be a
user of several networks as well as being a node and sysop in fidonet...

 NB> All of a sudden you're an  original author or attempt to speak for 
 NB> them?

someone has to... they're not here to defend themselves any more... who
better than someone who has been there on both sides of the argument and
knows the history??

 NB> The point is, these types of  file_id.diz's have been created and 
 NB> used for just about as long as  they have been available.

yes, and this particular problem has been complained about since the first
one appeared... granted, it has not been incessent bitching and complaining
like some things but the complaints have still been being voiced... that
you've not been where you can hear them or have chosen to turn a deaf ear
is a different problem...

 NB> The fact that one or two people are whining about  it is 
 NB> definitely not a majority. Just the slim few that are anal 
 NB> retentive,  is all.

bullshit... what was that you said about opinions earlier?

 ml> that's beside the point, nick... i, too, like looking at the logos and
 ml> drawings but not in file descriptions where they are mostly illegible
 ml> and end up mashed together on systems that don't have the capabilities
 ml> of your system or mine...

 NB> Too bad for those systems. I just wont even visit them in that
 NB> case. Most of  the file descriptions I see are mostly legible,
 NB> which is the complete opposite  of what you're saying. With that,
 NB> you can stay on your side, and I'll stay on  mine.

and yet you never think about another sysop's choice to display the
descriptions how they want them displayed... are you expecting ever system
out there to display files in the same way that your system does? i
don't... i'm not that narrow minded or anal...

 ml> i'm not the only one, nick... you certainly have a way of flipping
 ml> things around and seeing them in a way not intended... *I* didn't
 ml> originate the complaints this time... the complaints have been made
 ml> numerous times over the last three decades... each time, things get
 ml> cleaned up and are better for a while and then they slide again...

 NB> You were the one to voice the complaint (which you seem to always
 NB> be the one  who rains on others' parades, 

no, i was not... i added my voice after others brought it up... AND as
stated before, my posts on the topic in /this/ echo are only in defense of
robert's post AND attempting to explain the reasoning behind the posted
statement he made...

 NB> yet as an FTSC member you're just supposed to  document current 
 NB> practice).

this has nothign to do with the FTSC so you can put that little argument
right back on the shelf where you got it from, mmmkay?

 NB> This is the first time I've heard the complaint, and the way you're
 NB> describing  it, there's only a handful of people (or less)
 NB> complaining about it. That's a  minority, IMO.

you're not listening in the right places, then... i can't help that... you
might not even have access to those places... i don't know... it isn't a
problem that i have to deal with... sorry...

 NB> Regardless, The file won't be hatched out in Fidonet anymore since
 NB> I'm not  changing anything (at least until "the enforcer(s)" step
 NB> [or fall] off their  thrones).

there is no "enforcer" so please stop being a dipwad about
that... you misread the statement i made and jumped way off into left field
=again= in the same way you did when you read robert's original post and my
replies to you trying to explain the problem... i'm still trying to get you
to come back out of left field and acknowledge the problem... i don't know
why but i am... i guess i care too damned frackin' much :/ 

)\/(ark