[standards-jig] Asking the server for my IP address
ben at blahr.com
Wed Nov 27 19:47:02 UTC 2002
-----BEGIN PGP SIGNED MESSAGE-----
Justin Karneges wrote:
| It would simply be a convenience feature. In the case of NAT, a user
| currently have to make a port forward and specify his outside IP
| 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
| 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
| very well. Just look at AIM and ICQ. The only time it is a problem
| 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards