> Hmm. So I could connect with my Jabber client to a JEP-0124
> proxy that would enable me to authenticate directly with,
> say, an IRC server or SIMPLE server?
The intention was only to enable *XML* protocols. For example, (future,
proprietary) non-XMPP AJAX implementations that need to emulate
> Including the host and port still seems fine to me, I'm just not
> convinced it needs to be represented as an xmpp: URI.
> Why not just route="host:port"?
Well, URI's are for "identifying entities that can communicate via
XMPP". And the idea was that, a JEP-0124 proxy should also be able to
sup
> can't the proxy figure out which port to use
> via DNS TXT records? Does the client really
> need to tell the proxy which port to use
> or is that task better left up to the proxy?
> Just asking.
We went through this discussion in a long thread in June. Here is your
concluding email:
http://m
> While handling the route attribute, should the authority
> component of the IRI be used or ignored?
>
> What's the suggested result when the IRI holds no node identifier?
> Should the route attribute be silently ignored, or should an error
> (improper-addressing seems suitable) be thrown? Is it
> Yes, Guus and I discussed that off-list. I reread this
> section and was really quite surprised. Did you change this
> section some time ago or am I just getting slightly mad?
No changes that I remember. We all have our mad moments ;-)
- Ian
> It's a cleverly designed protocol.
Thanks very much Jack... although I've been doing my best to keep that a
secret! (If patenting a technique is against your 'religion', then
building it into a relatively 'obscure' public standard, that is below
your competitors' radars, is the next best option.
> > Alright, thanks, that was helpful. One last question: 'polling' only
> > limits the time between sending two polling ('empty')
> > requests, right? Other requests can be send more frequently?
>
> No, the JEP doesn't refer to empty requests at this point. I
> was wrong about this myself when
> Does this mean the google talk jabber server implementation does not
> support offline messaging (or JEP-160 as we can now refer to, tnx to
> stpeter :-) )
Yes. They have no offline message support yet.
- Ian
> Thanks for your response Ian. Does that mean it's fair to say that
> "Entity Capabilities (JEP-0115) makes "Feature Negotiation"
> (JEP-0020) obsolete?
No.
Feature Negotiation allows the *agreement* of features that may be
specific to the relationship between the entities and specific to the
Hi Guus,
As you noticed, JEP-0115 wasn't designed with extra functionality in
mind. It simply provides a more scalable solution. JEP-0115 makes it
unnecessary for clients to send requests to every entity from which they
receive presence.
- Ian
> This is a problem in a lot of clients.
> For example, both tkabber and gajim display
> contacts with sub=none or sub=from (see (A)),
> and both send presence type=unsubscribe and
> type=unsubscribed when the user "removes" a
> contact from roster.
One policy that fixes all the ambiguities (t
> is there a client which supports EXTVAL for supplying a URL
> as vcard PHOTO?
Not yet, but we plan to.
- Ian
> > So you see my server generating the challenge and validating the
> > response?
> >
> > I think servers should operate the same rules for subscription
> > requests and messages. i.e. I shouldn't even see the subscription
> > request until the other user has passed my server's Bot-Proof
> >
> (I should be able to specify the error message that's
> returned to you when your message to me is blocked
> because you're not in my roster -- at this point we have
> something like a challenge-response system
Yes. IMHO this will be one of the most important anti-SPIM techniques
(along with
Hi,
I just posted on this subject to the Standards-JIG list because IMHO we
need new JEPs.
- Ian
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ian Paterson
> Sent: 28 August 2005 11:40
> To: 'Jabber software development li
Ensuring SPIM will not be worthwhile, even with a network of 'zombie'
client or server machines, clearly needs multiple measures. IMHO we need
to move forward ASAP with some of the good ideas that Tijl, Sander and
others were putting forward on the JDEV list yesterday. (I've tried to
summarise them
Trejkaz wrote:
> The problem with blacklisting is that it
> assumes all new servers are innocent.
> A spammer gets to run amok until they're
> caught, and then change hostnames.
>
> A combination of whitelisting and
> blacklisting would be more effective.
> Server admins apply to a central
I agree with almost everyone that we need to be patient for a few weeks.
I hope it turns out that we are all pulling in the same direction, and
Google just want to get this right.
If they opened up s2s from beta-one day-one, and only later decided they
had to introduce s2s restrictions, then the f
> > "We are also eager to hear from other people in the industry about
how
> > best to build a federation model that is open, scalable, and ensures
> > best-in-class user experiences. If you have thoughts on federation
or
> > suggestions for how we can better enable open communications, please
> We're also announcing Asterisk-IM, a plugin for Jive Messenger
> that provides integration with the Asterisk phone system --
> http://www.jivesoftware.org/asterisk-im
[snip]
> The protocol extensions will eventually be turned into a JEP,
> but are available for experimentation and implementation
The Chatterbox Web client has implemented it. I'll send you instructions
off list about how to access it.
- Ian
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Luis Peralta
> Sent: 19 July 2005 21:44
> To: [EMAIL PROTECTED]
> Subject: Re: [Standar
Hi,
The javascript URL below allows you to quickly open any JEP.
Just create a new button called "JEPs" with the address below on the
Bookmarks/Links/Personal toolbar of your Firefox/Safari/IE/Opera browser
(or in your Bookmarks/Favorites menu).
javascript:n=prompt("Enter\x20JEP\x20number:","")-
> > > subscription="none"
> > jid="[EMAIL PROTECTED]" >
> > Conferences
> >
>
> Ah well in that case it looks like it is some kind of non
> standard hack that if you think about it could cause problems
> with MUC implementations, as it would make
23 matches
Mail list logo
