Subj : linked
To   : Frank Vest
From : Gordon Lewicky
Date : Mon Dec 16 2002 07:46 am

 Quoting Frank Vest to Gordon Lewicky 
 Subj. linked, dated 15-Dec-2002 19:48 

Hi Frank,

 FV> One picky technical difference. :) Binkp and the other IP flags are
 FV> protocol flags, not connectivity flags in the respect that the Fidonet
 FV> Nodelist expects.

Yes they are, and so are all those V flags for modems. Or in
otherwords, the handshake. Do we do away with all the V flags
because they sure as beans are protocols as well! :)

Now, for PSTN the address is the phone num.
For internet the address can be in 2 forms.

So maybe one solution, since the phone num field accepts alpha
numerics, is to have the first character of the phone field be I for
inet addressing. This way, there is only one address field, good
for both POTS and ION

As to whether this will puke every nodelist accessing processor,
compiler out there, I don't know. And neither do I know if the
string length is long enough to accept email addys or domain
names.

But if you want to stick with the strict technical definition of a
protocol flag, and not have attached addys, then this would be the
only and and most elegent soultion. One common field for the
address, and then we can just use modem or inet flags.

This would work great if one was POTS or ION, but not both!

So that means we need 3 address fields, a phone num, a domain
name/IP and a email addy, since we should allow for a system which
has the 3 means of addressing, or are you saying we should only allow
1 INET method and not 2 or 3 or 4?

Now, I do know that adding 2 new addressing fields to the line will
most certainly blow up all the existing software.

And we don't want to get into the nodelist stuffing argument where
we decide that we must separate out the 3 types and just have one
type addressing per node.

So I see the existing method of either placing the addy in the
system name field or attaching it to the I flags as being the best
method so far, since it is already working for just about all
software. The only thing holding back the ability to have a system
fly all means, is the line length limitations in the current
processors, and that is a very easy thing to fix. Much easier then
farting around with adding new fields and changing location fields
to addy fields.

And I certainly see no need or justification for telling any node
that they can only fly 1 or 2 Inet protocols. If they have the
means for all methods, then let them, and if each method has a
different name, port, then that only means increasing the line
length to fix!

The real problem is how to distinguish the difference between a
POTS and ION, without having to force them to use PVT or HOLD!

But I just can't see how holding the I protocol flags to just being
them by themselves is going to fix anything. It would only make
things worse. And for what? Because of a strict technical
definition? Nah... doesn't make any common sense doing it that way.
Why fix something that really isn't broken?


 FV> Agreed... to a point. Not all should be needed.

No they are not normally needed, but who are we to tell someone that
they can't make themselves available by all means, or tell their
downlinks that they must use this or that because we resticted
their uplink to a few methods?

The real problem is differentiating between POTS ands ION and line
length, not how we enter inet protocols.

Just a few of my rambling thoughts. :)

Cheers...
Gordon Lewicky (Pdk)

Sysop - Milky Way 1:153/307 NC 153
AdventureNet 33:500/150
email glewicky@telus.net

--- EzyBlueWave/2 V2.00 00F90260
 * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)

.