Text 6665, 51 rader
Skriven 2013-02-19 17:01:07 av mark lewis (1:3634/12.42)
   Kommentar till text 6652 av Sergey Dorofeev (2:5020/12000)
Ärende: LOL!
============
 SD> orig.message to echo FIDONEWS on 19 Feb 13  10:06:47
 SD>> INTL kludge is not requred to be present but is required to be
 SD>> checked for its presence.
 ml>
 ml> really? where is that documented? ;)

 SD> How can you route message if you do not know the zone it destinated
 SD> to? If you do not check INTL you are in risk to confuse message
 SD> addressed to 3:3634/12.42 with addressed to you...

exactly... but it is not documented as being required... and with the network
shrinking as it has been doing for these years, the duplication of nets across
zones has also been eliminated... this problem was actually first discovered
because of the 2D seenby and path lines in echomail and it is directly
responsible for the option to strip seenbys in tossers... some call this "tiny
seenbys"... but there had to be a method to remove that which blocked
distribution... this is another place where a new PKT format would be handy...
type 3 or 4 or whatever with UTF-8 and full 4D or possibly 5D seenbys and paths
and whatever else may be necessary that we've been trying to work around for
years...

truth be told, IMO, we should have been using type 3 PKTs back in the early 90s
when they were proposed... that or type 10 when it was proposed... type 10 had
provision for carrying binary data like JPG, PNG, etc... and it was NOT encoded
in some enlarging process like UUENCODE, XXENCODE or MIME-64 cruft... i have
/always/ hated that a 300k binary would become 400k when encoded for
transmission over non-8bit capable systems... that should be long long long
past these days... the internet might even learn something instead of hiding so
many things behind older technology than FTN stuff ;)

IIRC, there were several proposals for both type 3 and type 10 and each was
written by the same person (type 3 by one person and type 10 by another)...
there was even sample processing code contained within the proposal archives...
i don't think anyone ever did a tosser for either one but that wouldn't be hard
to implement either...

detection of the PKT type simply need only have the first portion of the new
PKT type overlay the existing type 2 format and place a 0x03 or 0x0a in the
proper place so that existing type 2 tossers would not try to toss it... the
PKT header can be expanded from there if really necessary but i think the
stored messages are the real meat where expansion needs to be done... thus my
pointing to a new PKT type to carry the new packed message type so that old
type 2 tossers won't blow up on the new message type... those that can upgrade
will be able to see and use the new format and store it in their message bases
while those stuck with old school software and type 2 PKTs can continue to
carry like they are...

)\/(ark

--- 
 * Origin:  (1:3634/12.42)