2010/3/20 Florian Zeitz florian.ze...@gmx.de:
On 2010-03-20 at 11:48, Väisänen Teemu wrote:
Hi.
What do you think about the following:
The server knows client's IP address, so what if the server would also
check country, operator, etc. and send some (location) related
information back to
On 20.03.2010, at 11:48, Väisänen Teemu wrote:
What do you think about the following:
The server knows client's IP address, so what if the server would also
check country, operator, etc. and send some (location) related
information back to the client, if the client requested these types of
On 2010-03-20 at 11:48, Väisänen Teemu wrote:
Hi.
What do you think about the following:
The server knows client's IP address, so what if the server would also
check country, operator, etc. and send some (location) related
information back to the client, if the client requested these types of
Dnia 2010-03-20, sob o godzinie 12:48 +0200, Väisänen Teemu pisze:
The server knows client's IP address, so what if the server would also
check country, operator, etc. and send some (location) related
information back to the client, if the client requested these types of
information, not just
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
client to discover its external IP address.
Changelog: Initial published
On Sat, Mar 6, 2010 at 05:24, Evgeniy Khramtsov xramt...@gmail.com wrote:
XMPP Extensions Editor wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables
a client to discover its external IP address.
On Mon, Mar 8, 2010 at 14:33, Tomasz Sterna to...@xiaoka.com wrote:
Dnia 2010-03-05, pią o godzinie 12:53 -0600, XMPP Extensions Editor
pisze:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
URL: http://xmpp.org/extensions/xep-0279.html
Yet Another Way?
jabberd2 supports
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
client to discover its external IP address.
Changelog: Initial published
Nicolas Vérité wrote:
I am not quite also what would happen with BOSH: if there's separate
BOSH CMs and/or reverse proxies in the middle...
Indeed, I guess this introduces the same problem with backends
separation described by Tomasz.
--
Regards,
Evgeniy Khramtsov, ProcessOne.
On Sat Mar 6 09:33:25 2010, Pedro Melo wrote:
Besides, this is a trivial XEP. The C2S already has your IP address,
so its easier to ask your server for it.
That's not actually clear to me.
In the majority of our deployments, M-Link sits in a DMZ, with
routable access to client IP
On 12 March 2010 10:37, Nicolas Vérité nicolas.ver...@process-one.net wrote:
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
On 12 March 2010 11:57, Dave Cridland d...@cridland.net wrote:
On Sat Mar 6 09:33:25 2010, Pedro Melo wrote:
Besides, this is a trivial XEP. The C2S already has your IP address,
so its easier to ask your server for it.
That's not actually clear to me.
In the majority of our deployments,
This is indeed a trivial XEP, for Audio, it can help know if the
client is behind a NAT, yes. Does it says it is the same NAT to be
used when user places a Voice Call over UDP? Absolutely not. But I'm
quite convinced that it can give hints.
But I still see a point on it, which is when we may have
On Fri, Mar 12, 2010 at 14:02, Matthew Wild mwi...@gmail.com wrote:
On 12 March 2010 10:37, Nicolas Vérité nicolas.ver...@process-one.net wrote:
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract:
On Fri, Mar 12, 2010 at 14:22, thiagoc bara...@gmail.com wrote:
This is indeed a trivial XEP
Maybe too trivial? ;-) I wouldn't say naive... ;-)
, for Audio, it can help know if the
client is behind a NAT, yes.
I would rather say it might help. The chances it helps are quite low
as I
On 12 March 2010 14:15, Nicolas Vérité nicolas.ver...@process-one.net wrote:
On Fri, Mar 12, 2010 at 14:02, Matthew Wild mwi...@gmail.com wrote:
On 12 March 2010 10:37, Nicolas Vérité nicolas.ver...@process-one.net
wrote:
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor edi...@xmpp.org
You are completely right in your points Nicolas.
The question now is, why not have a simple IP querying on XMPP Server?
On Fri, Mar 12, 2010 at 3:24 PM, Nicolas Vérité
nicolas.ver...@process-one.net wrote:
On Fri, Mar 12, 2010 at 14:22, thiagoc bara...@gmail.com wrote:
This is indeed a trivial
IMHO, I'm ok and satisfied using such feature as an IQ. That solves
all the gaps it is meant for.
I do not see reasons to do not have it. As it is simple, optional and clean.
Personal Remarks:
* Having it as a stream feature, it is completely out of bounds.
* Having client sending his own IP, it
On Fri Mar 12 14:26:45 2010, Matthew Wild wrote:
(I hope this bikeshed looks pretty by the time everyone's finished
with it)
If you observe closely, you'll note that much of the discussion is
whether having a free railing we can chain the bike up to is really
that much better than the
On Fri Mar 12 13:05:56 2010, Matthew Wild wrote:
On 12 March 2010 11:57, Dave Cridland d...@cridland.net wrote:
In the majority of our deployments, M-Link sits in a DMZ, with
routable
access to client IP addresses, such that it sees internal
addresses rather
than external. I have no
On Fri Mar 12 14:32:48 2010, thiagoc wrote:
IMHO, I'm ok and satisfied using such feature as an IQ. That solves
all the gaps it is meant for.
I do not see reasons to do not have it. As it is simple, optional
and clean.
It is *not* simple - it is simple to implement, but very hard to
On 3/12/10 8:11 AM, Dave Cridland wrote:
On Fri Mar 12 14:26:45 2010, Matthew Wild wrote:
(I hope this bikeshed looks pretty by the time everyone's finished
with it)
If you observe closely, you'll note that much of the discussion is
whether having a free railing we can chain the bike up to
Dave,
which part of (Yes, we all know STUN is more reliable for UDP). you
did not understand? Did someone mention that this is meant for
overcome STUN? If so, it is completely equivocated.
Did we mentioned that it is meant for Public IP discovery?
As Peter said, it is experimental.
On 12.03.2010 16:36, thiagoc wrote:
Dave,
which part of (Yes, we all know STUN is more reliable for UDP). you
did not understand? Did someone mention that this is meant for
overcome STUN? If so, it is completely equivocated.
Did we mentioned that it is meant for Public IP discovery?
As Peter
On Friday 12 March 2010 07:17:13 Dave Cridland wrote:
All our current enterprise clients, however, run servers in the DMZ,
and see the clients' internal addresses - this includes Isode's own
deployment, actually.
Yes, this is a case I hadn't even thought of until a few months ago, and we
had
On Mar 8, 2010, at 7:52 AM, Tomasz Sterna wrote:
Dnia 2010-03-08, pon o godzinie 15:10 +, Matthew Wild pisze:
Yay, I'm not alone in thinking that each implementation need not
support *every* published XEP :)
Unfortunately this point of view is not shared by software users.
They tend
So, the spec begins with:
There are times when a client might want or need to discover what its
external Internet Protocol (IP) address is, e.g. when gathering transport
candidates for SOCKS5 Bytestreams [1] or Jingle ICE-UDP Transport Method [2].
One way to do so is for the client to ask
On 3/8/10 8:52 AM, Tomasz Sterna wrote:
Dnia 2010-03-08, pon o godzinie 14:56 +0100, Remko Tronçon pisze:
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server implementation has a hard time
Dnia 2010-03-05, pią o godzinie 12:53 -0600, XMPP Extensions Editor
pisze:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
URL: http://xmpp.org/extensions/xep-0279.html
Yet Another Way?
jabberd2 supports http://delta.affinix.com/specs/xmppstream.html#myip
for some time now.
Dnia 2010-03-05, pią o godzinie 12:53 -0600, XMPP Extensions Editor
pisze:
XEP-0279 (Server IP Check) has been released.
This protocol is hard to implement in servers with strong separation of
client connection handling and client session handling (jabberd14,
jabberd2, Tigase AFAIK).
In these
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server implementation has a hard time
figuring it out, don't support it. If all the stories are true, this
XEP is a use case that will only be
2010/3/8 Remko Tronçon re...@el-tramo.be:
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server implementation has a hard time
figuring it out, don't support it.
Yay, I'm not alone in
Dnia 2010-03-08, pon o godzinie 14:56 +0100, Remko Tronçon pisze:
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server implementation has a hard time
figuring it out, don't support it.
On Mon, Mar 8, 2010 at 3:52 PM, Tomasz Sterna to...@xiaoka.com wrote:
Dnia 2010-03-08, pon o godzinie 14:56 +0100, Remko Tronçon pisze:
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server
Tomasz Sterna wrote:
If you don't like it, then don't use it. is not a technical argument.
Indeed, there was no technical arguments. The only argument I saw was:
hey guys, this XEP is simple!
--
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:x...@jabber.ru.
On 8 March 2010 15:52, Tomasz Sterna to...@xiaoka.com wrote:
Dnia 2010-03-08, pon o godzinie 14:56 +0100, Remko Tronçon pisze:
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server
Dnia 2010-03-08, pon o godzinie 16:18 +, Matthew Wild pisze:
How would you propose to do it without tight coupling?
http://delta.affinix.com/specs/xmppstream.html#myip
Some may say it is spamming all clients with a feature that may or may
not be useful.
But it is a case of offering every
Matthew Wild wrote:
People want this, it's trivial to do, we should
standardize a way of doing it. Done.
Actually there is already a standard for address discovery - STUN. By
the way, you didn't tell why this XEP is useful and why it is better
than STUN, or when to use this XEP and when
Hi,
On Sat, Mar 6, 2010 at 5:01 AM, Evgeniy Khramtsov xramt...@gmail.com wrote:
There is already STUN support in ejabberd :P
For me it is unclear why we need another way to discover client's public ip,
that's why I'm asking
Because I already have a XMPP stack, and if I can get away without
FYI: STUN and TURN are two separate mechanisms.
What are the requirements for the client when Jingle is used?
Pedro Melo wrote:
Hi,
On Sat, Mar 6, 2010 at 5:01 AM, Evgeniy Khramtsov xramt...@gmail.com wrote:
There is already STUN support in ejabberd :P
For me it is unclear why we need
Hi,
On Sat, Mar 6, 2010 at 9:35 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
FYI: STUN and TURN are two separate mechanisms.
I meant STUN, sorry.
Bye,
--
Pedro Melo
http://www.simplicidade.org/
xmpp:m...@simplicidade.org
mailto:m...@simplicidade.org
On Saturday 06 March 2010 01:33:25 Pedro Melo wrote:
On Sat, Mar 6, 2010 at 5:01 AM, Evgeniy Khramtsov xramt...@gmail.com
wrote:
There is already STUN support in ejabberd :P
For me it is unclear why we need another way to discover client's public
ip, that's why I'm asking
Because I
On 6 March 2010 18:12, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
On Saturday 06 March 2010 01:33:25 Pedro Melo wrote:
On Sat, Mar 6, 2010 at 5:01 AM, Evgeniy Khramtsov xramt...@gmail.com
wrote:
There is already STUN support in ejabberd :P
For me it is unclear why we
As noted in the XEP, the server actually returns what it perceives to be the
client's IP address.
What the security considerations miss is that doing so may unintentionally
cause disclose information about the network information the server operates in.
Server operators likely don't want to
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
client to discover its external IP address.
Changelog: Initial published version. (psa)
Diff: N/A
URL: http://xmpp.org/extensions/xep-0279.html
On 5 March 2010 18:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
client to discover its external IP address.
Changelog: Initial published version.
XMPP Extensions Editor wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
client to discover its external IP address.
Changelog: Initial published version. (psa)
Diff: N/A
URL:
On 3/5/10 9:24 PM, Evgeniy Khramtsov wrote:
XMPP Extensions Editor wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that
enables a client to discover its external IP address.
Changelog: Initial published
On 3/5/10 9:11 PM, Matthew Wild wrote:
On 5 March 2010 18:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
client to discover its external IP address.
Peter Saint-Andre wrote:
On 3/5/10 9:24 PM, Evgeniy Khramtsov wrote:
Why not use STUN?
Feel free to add that to your XMPP server and client.
There is already STUN support in ejabberd :P
For me it is unclear why we need another way to discover client's public
ip, that's why I'm
50 matches
Mail list logo
