Text 8093, 74 rader
Skriven 2016-02-29 22:55:40 av mark lewis (1:3634/12.73)
   Kommentar till text 8092 av Stephen Hurd (71.fido-ftscpubl)
Ärende: FSP-1040.001 draft 0
============================
29 Feb 16 23:59, you wrote to me:

 ml>> with a PKT extension... this is, however, probably outside the range
 ml>> of this document... i dunno...

 SH> Yeah, it was pretty clear it was outside the realm of "Type 2
 SH> compatible packet formats" and, if anyone actually uses it, should be
 SH> documented in a different spec (since by definition it applies to
 SH> non-type-2 packets).

yes and no... Type 2 PKTs and vairants have the same packed message body
format... Type 3 and Type 10 proposals carry a different packed message body
format...

 SH>>> Yeah, but it's not the mailers that do the negotiation, it's the
 SH>>> tossers/packers.

 ml>> i don't see how they can do that without some sort of special PKTs
 ml>> addressed to the tosser where the tossers can communicate back and
 ml>> forth on their own similar to the way operators can send areafix
 ml>> messages to the tossers and the  way that offline mail users can
 ml>> communicate with a BBS' offline mail

 SH> Basically, when you parse a packet, you save the capability word
 SH> associated with the node.  When it comes time to packetize, you look
 SH> at your saved copy of *their* capability word, and pick the highest
 SH> packet format that they support and use that format.

when you parse a PKT with what? the mailer or the tosser or any PKT parser?
some documents seem to assume that the tosser is doing all the packing but
there are mailers that pack messages, too... i'm trying to draw attention to
the distinction between them as far as negotiations of the preferred PKT type
go... how is a Type 3 or Type 10 system going to negotiate a Type 3 or Type 10
preferred PKT format if only the tosser can negotiate this? how is the tosser
going to convey this to the mailer?

 ml>> :) that's ok, i can wait... i'd rather be able to point to certain
 ml>> things in the most recent posted as they progress... personally i
 ml>> think it is a good document so far... just a few tweaks here and
 ml>> there to enable it to stand closer to being on its own...

 SH> I plan to post the next draft in a couple days to give slow routes
 SH> time to provide feedback.

understood but i don't know what qualifies as "slow routes" these days where
99% of the traffic is transmitted via the internet in a crash-me-crash-you
format... my system is one of few that process mail on a timed schedule instead
of an ASAP processing method ;)

 SH>>> Anyway, the message body is defined as NUL terminated unlimited
 SH>>> length and that's it.  Other standards already define control
 SH>>> paragraphs, and the rest of the things that are defined are
 SH>>> presentation details, not packing details.  No packer should need to
 SH>>> worry about soft CRs for example.

 ml>> true... i agree... FTS-0001 covers more than just mail packers,
 ml>> though...

 SH> Yeah, but this is very much *not* a replacement for FTS-0001.  I'm not
 SH> the guy who's going to take that job on.  No sir.  This FSP is just
 SH> for software dealing with packets.

i can understand that! there's not been many folks willing to stand up and
propose a replacement for FTS-0001 in the last few decades though many have
raised the spectre of replacing it and they have proffered<sp?> numerous
reasons why it should be done...

)\/(ark

Always Mount a Scratch Monkey

... The trouble is that you think you have the time.
---
 * Origin:  (1:3634/12.73)