(Continued from previous message)

BL> was hell on wheels, and there, we all wanted it.

Yep, you havent got a hope in hell Bob.

BL> I would set up a fixed header with spare fields for expansion,
BL> and that's it!

RS> That approach doesnt work because it inevitably breaks when you
RS> have exhausted that fixed header. Thats precisely the problem
RS> with the current QWK format, its fixed, its not readily expandable.

BL> You've just finished telling me I can't expand the PKT header...

And you cant, it wont work they way you want to do that.

Its not as if it hasnt been tried either, the QWK format suffers
very severely from that problem. And its not even used by mailers.
You just get a few proprietary formats like BlueDribble and Silver
Xpress and the rest of the world yawns and keeps using QWK. BECAUSE
its got an inflexible fixed format header. So stuff like netmail is
kludged by putting the To: field in user text and abortions like that.

BL> You need a fixed field to define the overall header, in order
BL> to separate it from the message.

Thats crap too. You dont actually need any fixed header at all,
just a 'message starts here' market of some kind and ^A kludge
lines, some of which are mandatory if you really want to.

The current approach was to put most of the stuff you know you need
in the fixed header, some stuff is fucked up totally by putting it in
user text like the origin line, and an ^A kludge expansion capability.

BL> You can put anything inside that header if you leave enough room.

And you can never leave enough room to allow you to be sure you
wont run out. A ^A kludge line approach to expansion has unlimited
expandability. No fixed header can ever have that.

BL> The existing message header is 14 bytes, plus the Date/time,
BL> To, From, Subject fields. Blind Freddy should have realised
BL> that 14 bytes is not enough...

Yes, but even 200 isnt either. Its not enough for seenbys for example.

If someone wants to be able to do a real file attach, you might well
want to be able to include the modern file data seen in an HPFS type
file system. That uses a minimum of 512 and more of those as required.
No fixed header can EVER be sure its got enough. Which is why EVERY
modern system doesnt use fixed headers anymore, they are too inflexible.

BL> especially when mail is sent compressed, and a string of blanks
BL> compress very well. Pick a number. If 256 bytes is too low, let's
BL> make it 1024. If they're all spaces, it'll compress to 4 bytes anyway!

Yes, when being passed between systems compressed. BUT they arent
always compressed. Many Fido mail systems attempt to keep ALL the
fields available. You have a tad of a problem with your approach.

RS> Not if its fixed as you said you wanted. Spare fields dont work for
RS> long. QWK started off with spare fields, it is fucked expansion wise.

BL> BzzzT! The 128-byte QWK header only has 3 spare bytes.

It had more initially, they got used up.

BL> It looks to me that the guy who wrote in fell in love with 128.

Its again an accident of history, CP/M used to work like that |-)

BL> I sympathise with him for not thinking to allow a double record
BL> of 256-bytes.

Still not enough, wont handle the SEENBYS.

RS> Its still a fixed header which fucks your expansion possibilitys.

BL> Not if it's 1024 bytes long...

Yep, still does.

BL> It has to be backwards compatible, like colour TV.

RS> And you design isnt.

BL> It may be.

Nope, its got no chance. None, zero, ziltch. Even if you can nick
a few bytes from the Subject with impunity, still doesnt help you
to get the graphics into the user text.

BL> We would have to test how existing mailers responded to an increased
BL> "Subject" field. My guess is that they won't know the difference.

Utterly irrelevant even if they did and your guess is worthless anyway.

BL> The extra stuff goes on the end, delimited by CRs.

RS> Adding YET ANOTHER DIFFERENT way of delimiting header type fields
RS> in what is already a format which has FAR TOO MANY different ways
RS> of doing that. What a fucking abortion Bob.

BL> Unfortunately, if has to be something that a files list will
BL> accept as normal, because the Subject field is also used as
BL> a Freq files list.

With severe limitations, only if it they will fit.

BL> You could use anything you like (except 0x00) after the first CR.

You dont even know that, you just assume that.

BL> My idea is to duplicate all the ^a, AREA and seenby lines in the
BL> expander header... padded with spaces on the end to a fixed length.

Wont do a bit of good coz you dont have backward compat coz those older
systems dont know to skip over your expanded header, let alone the
graphics in the user text. They will keep perving thru that stuff
looking for ^As etc and will at times shit themselves at what they find.

--- PQWK202