[standards-jig] Asking the server for my IP address

Ben Schumacher ben at blahr.com
Wed Nov 27 19:47:02 UTC 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Karneges wrote:
| It would simply be a convenience feature.  In the case of NAT, a user
would
| currently have to make a port forward and specify his outside IP
address into
| the client application.  I want to eliminate the latter step.
|
| I agree that JOBS is the most reliable.  However, we can't be doing
all of our
| file transfer through the server, can we?  Just because the user is
too lazy
| to make a port forward?

I'm sorry Justin, but user's don't always have the knowledge or the
capabilities to do this sort of thing, even if they aren't behind a
corporate firewall. Many large ISPs have started giving out NAT'd
addresses on broadband accounts (to discourage file-sharing services),
and dialups (to avoid IP exhaustion). This is the state of the Internet,
and end users can't do anything about it. In fact, I think it likely to
be going more and more in this direction, as companies try to reduce
costs as a result of the economic situation of the world.

| In practice, providing internal/external IP addresses for P2P activity
works
| very well.  Just look at AIM and ICQ.  The only time it is a problem
is in
| the double-NAT with no possibility of a portfw (say, both are corporate
| employees), and that is where JOBS comes in.

In practice, users want something that they can install that will just
work, JOBS gives us this. In fact, I would agree that a proxied
connection may not be necessary in all cases, but this can be dealt with
programmatically. The load is (and should be -- in most cases) on
developers to make this easy for end users. If it was up to me, I'd
write a single interface for sending a file to another user, then do
magic behind the scenes to figure out how best to accomplish this. From
an end user perspective, it would be straight forward. From a developers
perspective, I would attempt a direct file transfer, and if that fails,
fall back to a proxied connection.

The point is, this a problem in The Real World(TM), and a lot of work
has gone into finding a solution that works in The Real World(TM). While
it is true that JOBS lacks implementations, the JSF doesn't (and
shouldn't) base protocol decisions on "me first" implementations -- it
should instead weigh the pros and cons of each proposals, and choose
based on which proposal solves an issue in a manner that works for all
people, all of the time, rather than a solution that solves an issue for
some people, some of the time.

It is unfortunate that developers have rushed to implement JEPs that are
still in the *EXPERIMENTAL* stage, but that is a choice they made. Being
experimental means these protocol enhancements could still change
significantly, and MAY NOT ever be accepted by the Jabber Council. Any
effort or time lost as a result of this enthusiasm is an unfortunate
casualty of the JEP process.

bs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE95SE0UpoGqensAXIRAuLOAKCg829AU57bbE5wgqsV08zh2mcJbwCgpBvb
MdNcZw6wv6EvATSJEhQgs/A=
=zXjW
-----END PGP SIGNATURE-----




More information about the Standards mailing list