(Continued from previous message)

RS> pointless Bob, we are talking about whats a viable improvement
RS> to the current extensible design. And if we are going to
RS> contemplate a completely fresh design, we need to FIRST decide why
RS> we cant use one of the CURRENT completely fresh designs like X.400

BL> I don't want a new design that obsoletes every BBS in the World;

Well, thats what you were proposing, whether you realise it or not.

BL> I want a system can run compatibly with those mailers without breaking
BL> messages, but offer advantages to an updated mailer (like graphics).

And your proposal wouldnt do that.

If you do want to kludge on a graphics capability there is a much
much simpler approach, a normal ^A kludge line which contains a
byte count of what to skip after it. BUT that cant be dropped in
totally transparently to current message processors. BUT it would
be much easier to drop on top of the current approach than what
you were proposing coz it involves absolutely minimal changes,
just recognition of the new kludge keyword and skipping the bytes.

You would be much better off just continuing with Hi Ascii when
its enough, and UUCODING when its not.

BL> I don't know X400 but I assume that it is not compatible with
BL> Type2 PKT format. This means a new net to supercede Fido.

Nope, formats have nothing to do with nets. Fido has already
seen a number of new formats added on top of existing ones.

BL> It may be the best way to go, but this is not what I am
BL> proposing in spite of Paul's assertion. He apparently does
BL> not understand the concept of backwards compatibility.

He understands it fine, and your proposal doesnt have it.
It attempts it and fails.

UUCODING is totally backwards compat, nothing else is for graphics
in the user text. It cant be done.

The only real 'problem' with UUCODING is that its a tad cosmetically
grotty, but thats the only way you can really get backward compat with
the current PKT format. Yours doesnt.

BL> I know of two examples: the TV system that changed up to
BL> colour, and the FM radio system that went up stereo. FAX
BL> is another. It's the cheapest and cleanest way to do things.

No one is arguing about the desirability of it. They are saying
that your proposal ISNT backwards compat. It just claims it is.

BL> Digital phones took the other approach and we will have two
BL> incompatible systems running alongside inefficiently for years.

Yes, at times it just isnt possible to be backwards compat. Thats not
the first time that happened with mobile phones either, it happened the
time before that too. Thats life, its not always possible. CDs arent
backward compat with black vinyl records or phillips cassettes either.

Even with TV, UHF isnt backward compat with VHF really.

BL> All this should go in the header, with room for expansion.

RS> You are now just sitting down and redesigning PKT how you think it
RS> should have been done in the first place, a different matter entirely.

BL> Not so. I am proposing a compatible system.

Nope, you only claim you are.

BL> I suspect that no mailers check the 72-byte maximum for the subject
BL> field; it is an unnecessaary complication that adds nothing.

And backwards compat aint about 'I suspect's Bob. It dont work.
Partly because software is so much more prone to have 50 ways
of processing a message in various bits of software which do,
it will inevitably break something.

You only have to apply your 'I suspect' to the question of Hi Ascii
in messages. Although most systems dont mind, it does break some.

BL> It would be easy to test for this: add 256 bytes padded
BL> with spaces and a hidden message on the end of the subject
BL> field (inside the null) and see what happened.

And thats another fundamental you totally overlook, it just aint possible
to 'see what happens' with Fido. So many systems just silently file
exceptions in the bin and hope for the best. Some deign to have a garbage
bin directory and many of the sysops never look inside it at all, ever.
If for example you change fangs a Mac mailer, it may well lurk there for
years until a particular sysop has asked for particular message from a
particular person, repeatedly fails to get it, has enough technical
knowledge to look closely and see where it went. Even then, if the Mac
mailer is a hop or two upstream of him, it may well just not be possible
to work out what happened to it with a reasonable amount of effort.

BL> If the message passed unbroken, we could simply add the
BL> information inside the header,

And you STILL cant eliminate the possibility that someone will write
message processing code based on the specs and THEY break it later.

There is only ONE way to do what you want, get a kludge which includes
a byte skip count approved, somehow get everyone to implement that. You
have buckleys. Particularly when you can UUCODE right now.

BL> and padd the Subject field to give a fixed-length message header.

And here you are completely mixing up two quite different problems.
There is just NO POINT WHATEVER in a fixed length header. NONE.
The current approach of a fixed header for the stuff you know you
want, and an ^A kludge line expansion past that is far far superior.
Absolutely NOTHING to do with the question of graphics in user text.
This where you really do trip off into a whole new format. Even if
you dont realise you are doing that.

BL> This is all we need to protect the message field to send graphics.
BL> The packet header would be unchanged.

It changed, you have fucked around with the subject field.
It will inevitably break things when you do.

BL> Initially, the ^a kludges would remain, and new mailers would
BL> be written to include both. The new standard would not affect
BL> old mailers (if the tests proved it first), but the old mailers
BL> would not be able to handle graphics. The change would be rapid...

Bullshit it would, you would get howls of rage and the most that
would happen is that you would get a ute which strips messages
like that out of PKTs and files them in the bin. More likely the
source of those messages would be told to stop putting them into
the system or else get their feed cut.

BL> Even if come mailers broke the expanded Subject field,
BL> it might be possible to modify those mailers first.

Nope, they will just tell you take your messages away or
have your feed cut.

BL> This happened to some TV sets when we tested for colour
BL> compatibility, and those sets were modified retrospectively.

Yes, you can at times do that, and at times, say with mobile phones
and other handheld radio transmitters becoming more common showing

(Continued to next message)

--- PQWK202