BL> The *last* origin line is the real one.

 RS> STILL missing the point utterly. The SOT EOT is MUCH easier to
 RS> use as the borders of the user text that that sort of farting
 RS> around. BUT there is a problem when hardly anyone uses SOT EOT.
 RS> SO you have to write the code without relying on them UNTIL
 RS> they are widely used.

  I'll say it one more time... because I've actually done it in
code both ways. If you use Paul's EOT, you have to look for that in
particular - first - to mark the end of the text. Then you have to
look for the tear line and origin line because both have to be added
back into the message shown on the screen. You have to read both of
them and add them to the message - again! Then you have to look for
the "SEENBY" line to make sure it's there, following the Origin line.
If not - you look for another Origin line and so on until you find the
last one with a "SEENBY" following.

  Without Paul's EOT, you look for the Origin, and then read "SEENBY".
Then you try again - staying inside the null terminator - until you
find the last pair.

  The point I keep repeating ad nauseam, is that once you do this,
what the fuck do you need EOT for? It's an extra! Even if it existed
in *every* message (which it doesn't and never will), you still have
to look for the tear line (you don't need to do this without EOT
because it will always be *inside* the origin line), then the origin
line, and then read "SEENBY" as a fallback. This identifies the
correct "SEENBY" unambiguously... the one following the *last* Origin
line.

  I began by writing the code to do all this, and I understood as
clearly as St Paul saw Jesus on the Road to Damascus that EOT was
surplus! I was using the same code, twice! The esisting system can 
be totally foolproof at the end of the message. Whether mailers do it 
properly or not is another story that applies equally as well to how 
they treat SOT/EOT.

  Paul's poisition is that the Origin line is not always included,
even though this breaks FTS1. So... we find the seenby and use that to
mark the end of the message. It's still foolproof. I say that if a 
braindead mailer leaves out an Origin line that everyone needs to be 
able to reply to the message, then why would this same braindead mailer 
add EOF that no one but Paul gives a stuff about? Paul says it is easy 
to do. I agree with him. I did it. No worries. I also added a tear line 
and an origin line, and it uses exactly the same code with different 
characters. Instead of writing "^aEOT:" I put " *
Origin". What's the 
difference? The only difference is that " * Origin" goes in the right 
place - at the end.

 RS> I've deleted you repetition of you utterly missing the point on
 RS> all the rest. NO ONE is saying that PKTs CANT be processed with
 RS> the deficient design, JUST that the addition of SOT and EOT is
 RS> much BETTER, because it absolutely unambiguously delimits user
 RS> text.

  Who gives a stuff? What is the point of excluding a tear line and
origin line if we have to put them back in again? The only advantage I
can see is that if we were then able to enter graphics in the message
area - but EOT doesn't let us do that.

  Paul's argument that SOT/EOT makes it easier falls in a heap when it
may bot be there, and offers no advantage ever the existing system in 
the case of SOT and a positive handicap with EOT! If a mailer has a
problem identifying "SEENBY" correctly, then rewrite the mailer or use
a different one! The only time to change the system is when it is 
*impossible* to correctly identify the correct "SEENBY" or the correct 
"AREA" at the top.

  I don't mind ^aSOT so much. It's harmless because there is no need
to change the mailer code, and it does offer an advantage if you
process mail the way Paul does, by reading the address in the header
first, and if the address is not yours, passing it on without reading
the "AREA:" line at the top of the message to see if the
"AREA:" is
valid. SOT will let that braindead system work... as long as the
braindead system reads the first line of the message at all! I somehow
doubt it...

 RS> And so is that. Like I said, there is absolutely NO reason why
 RS> NOW, you cant just process the PKT the way you would do if SOT
 RS> and EOT did not exist at all. Just drop them as unknown kludges
 RS> lines. That has ABSOLUTELY NO penalty.

  I can do that... if I know they are there, but what about existing
mailers? That takes care of ^aSOT with the other ^a lines at the top
of the message, but what about ^aEOT at the foot of the message? If I
drop ^a kludges I will lose "^aPATH:" that I may find of interest. If
I read my message by finding the origin line, ^aEOT will be inside
that, and shown on the screen unless I change my algorithm. Do you
like looking at the little red EOT's? They drive me to distraction!
The only way to get rid of EOT is to drop *all* ^a kludges.

  Personally, I find "PATH:" of interest.

 BL> I agree that we need a protected message area, but only because
 BL> I look forward to the time when we transmit graphics over the
 BL> BBS.

 RS> You can right now.

  How?

 RS> And you go on about a completely fresh design. Thats utterly
 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
 RS> why we cant use one of the CURRENT completely fresh designs
 RS> like X.400

  I don't want a new design that obsoletes every BBS in the World; I
want a system can run compatibly with those mailers without breaking
messages, but offer advantages to an updated mailer (like graphics). I
don't know X400 but I assume that it is not compatible with Type2 PKT
format. This means a new net to supercede Fido.

  It may be the best way to go, but this is not what I am proposing in
spite of Paul's assertion. He apparently does not understand the
concept of backwards compatibility. I know of two examples: the TV
system that changed up to colour, and the FM radio system that went up
stereo. FAX is another. It's the cheapest and cleanest way to do
things. Digital phones took the other approach and we will have two
incompatible systems running alongside inefficiently for years.

 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
 RS> it should have been done in the first place, a different matter
 RS> entirely.

  Not so. I am proposing a compatible system. I suspect that no
mailers check the 72-byte maximum for the subject field; it is an
unnecessaary complication that adds nothing. It would be easy to test
for this: add 256 bytes padded with spaces and a hidden message on the
end of the subject field (inside the null) and see what happened. If
the message passed unbroken, we could simply add the information
inside the header, and padd the Subject field to give a fixed-length
message header. This is all we need to protect the message field to 
send graphics. The packet header would be unchanged.

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

  Even if come mailers broke the expanded Subject field, it might be
possible to modify those mailers first. This happened to some TV sets
when we tested for colour compatibility, and those sets were modified
retrospectively.

  I would expect that Paul and you would take this tack, saying that
some mailers read the mength of the Subject field, rather than making
a mad assertion that the idea breaks Type2 Fido. It may not.

 RS> Thats mostly got nothing to do with the format of the header,
 RS> its mostly just that quite a bit is dropped from the PKT to get
 RS> the QWK, particularly the PATH and SEENBY stuff.

  No... I actually tested that. QWK has lots of consecutive spaces
that compress almost as well as if they are deleted.

 RS> Yes, you can indeed get weird effects. Someone proposed a
 RS> binary format for nodelists for size reasons. Turns out that
 RS> once you archive it its marginally BIGGER than the text one
 RS> archived.

  ROFL!! Amateurs, Rod. Amateurs never bother to test; they think it
can be done in their minds. Engineers have to work at it, or our
bridges keep falling down and nothing works.

 BL> If we allowed a fixed 256-byte message header in PKT, padded by
 BL> spaces, it would give tons for future change, and clear out the
 BL> message field so that only message was in there.

 RS> Yes, its a possible approach, but its far far too late for that
 RS> now.

  Maybe not... if existing mailers accept it. If you create a new
system, you'll end up with two running  together for 20 years.

 RS> In fact the movement to a new standard from an existing one
 RS> with no backward compat needs far far more than 'show a
 RS> benefit' to get people to shift.

  Exactly. You see it with digital phones. A better system becomes
stalled because manufacturers have already recovered costs for the
linear phones, and can cut prices. A compatible system is much nicer,
but it's not always possible.

 RS> Even thats not right. If you have for example a size field
 RS> which is included in a ^A kludge line which precedes that block
 RS> of graphics data, there is no limit on what you can have in
 RS> that graphics block And its readily backward compat.

  The problem is that ^a could be part of the graphics, and could
appear in an inconvenient place (unless you exclude 0x01 as part of
the graphics). It would work if you could put the size field outside
the message in a fixed-length header to identify it.

 RS> A message reader which doesnt want to bother to display the
 RS> graphics chunk can just skip over it. You can even use a format
 RS> ID kludge to specify the format of whats in that graphics
 RS> block.

  That could work - as long as you have a protected keyword like 0x01.

 BL> This is the way changes should be made... like colour TV. It
 BL> doesn't take long before everyone upgrades.

 RS> Thats crap Bob, software standards are nothing like that. You
 RS> wont be getting the whole of Fido adopting your new mail
 RS> standard just because you say 'hey you can include graphics in
 RS> a message with this' It doesnt work like that.

  Rubbish! Microsoft has built their business on that principle. You 
offer something new, and 90% of the market upgrades whether they need 
it or not. Explain to me the advantages of Word 6, for instance...

  The hard part would be getting the new standard adopted, even if it
were perfect. Writing the Colour TV standards was hell on wheels, and 
there, we all wanted it.

 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
 RS> expandable.

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

  You need a fixed field to define the overall header, in order to
separate it from the message. You can put anything inside that header
if you leave enough room. The existing message header is 14 bytes,
plus the Date/time, To, From, Subject fields. Blind Freddy should have
realised that 14 bytes is not enough... especially when mail is sent 
compressed, and a string of blanks compress very well. Pick a number. 
If 256 bytes is too low, let's make it 1024. If they're all spaces, 
it'll compress to 4 bytes anyway! 

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

  BzzzT! The 128-byte QWK header only has 3 spare bytes. It looks to
me that the guy who wrote in fell in love with 128. I sympathise with
him for not thinking to allow a double record of 256-bytes. 

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

  Not if it's 1024 bytes long...

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

 RS> And you design isnt.

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

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

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

  Unfortunately, if has to be something that a files list will accept
as normal, because the Subject field is also used as a Freq files
list. You could use anything you like (except 0x00) after the first
CR. My idea is to duplicate all the ^a, AREA and seenby lines in the 
expander header... padded with spaces on the end to a fixed length.

 BL> It would have to be Type-2 compatible.

 RS> And it isnt.

  You've fallen into your old tricks of repeated assertions, Rod, so
this is where I get off. It's not a discussion any more, and life is 
too short.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---