BL> in the PKT message header, are the cost bytes used for anything?
BL> One of those could be used to do the zones, which itself could
BL> be used to define Netmail independently.

Thats a completely fucked way to go. The ^A kludge lines provide a
perfectly viable way to extend the original standard. Its completely
pointless to be reusing old fields now, risking breaking on code
which does actually use them. And if you ever did manage to shift
all the kludge line stuff back into old reused fields, you would
lost one of the few advantages that the PKT format has, a decent
escape mechanism.

BL> The other thing that confuses me is the two attribute bytes in
BL> position 11 and 12 of the message header. In all your packets the
BL> first is set to 0x01 for netmail, and 0x00 in everything else, but
BL> this contradicts what is defined in FTS0001, where bit 0 is Private
BL> and Bit 1 is crash. It makes more sense to define Netmail separately,
BL> in the header, the way QWK does it.

In fact QWK Netmail is an even bigger abortion than it is in PKT.

BL> IMO, the main problem with PKT format is the message header.
BL> It is lacking:

Its far far too late for any of this now, that had to be done when
the standard was formalised in the first place.

BL> 1.  A conference name or number
BL> 2.  A way to show that the message is netmail
BL> 3.  Zone address
BL> 4.  Point address

Yes, they were not done as well as they might have been.
Its too late now tho.

BL> 5.  Seenby and Path space

Just not possible, by definition they are variable length, you
MUST have a storage mechanism which deals with variable length.

BL> The problem is compounded by treating netmail differently
BL> than the rest, instead of making it just an other conference.

Yes, that is indeed a flaw in the original standard. The trouble
is tho with a standard thats out there being used by everyone
all the time, it just aint possible to have second thoughts now.

BL> In the existing header, the only available space to add extra
BL> information is byte#2 [message type]; byte#12 [attribute high
BL> order]; bytes #13, #14 [cost], and the end of the Subject field.

Utterly pointless attempting to use those when there is a perfectly
good expansion mechanism in the standard, the ^A kludge lines.

Again, thats what was DECIDED would be used, far far too late to
change now.

BL> The subject could be further chopped to 58,

You just cant do that with a standard thats in general use NOW.

BL> That would depend on how many mailers were actually checking
BL> for this length. I didn't bother, and I wonder if everyone
BL> else did the same.

And robust standards cant be designed on criteria like that Bob.

BL> We could test it by adding padded spaces before the null,
BL> and it it passed all mailers,

There just aint ever going to be a way to test stuff like that
adequately. And utterly pointless to bother, the ^A kludge lines
provide the expansion mechanism.

BL> we could use 0x0d CR delimiters and just keep adding kludge
BL> lines to our heart's content.

In which case its utterly pointless to be farting around with
the header at all.

BL> What d'yer reckon? Can you see a catch?

Yeah, it wont work. You cant do that to standards already in use.

BL> The idea of an expanded header appeals to me much more than
BL> adding kludges with SOT and EOT,

Oh well, dont give up the day job Bob.

BL> But I now agree with you that SOT has a function in the existing
BL> system (expecially in netmail). Once the message field is invaded
BL> by a control line that *has* to be read, there must *always* be a
BL> control line to act as a delimiter. I disagree with your EOT proposal.

Oh well, maybe you will eventually wake up on EOT too.
Corse you are presumably just playing silly buggers anyway.

--- PQWK202