RE: [jdev] Re: Two questions regarding JEP-0124 HTTP Binding
> 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 the functionality of a TCP connection over HTTP could reuse code from JEP-0124 clients and proxies. I'm not expecting this to happen, because I believe XMPP will become very successful. However, we can enable this for one of our possible futures without any real impact on the protocol. Like I said, I don't feel strongly about the "xmpp:". I'm just explaining the origins. - Ian
RE: [jdev] Re: Two questions regarding JEP-0124 HTTP Binding
> 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 support non-XMPP protocols too (you never know). The Introduction says: "the protocol is extensible and could be used to implement any bidirectional stream of XML stanzas." That said, I don't have a big problem removing the "xmpp:", if that's what people prefer. We'd have to change existing implementations... Perhaps we could simply define the format within the JEP and not call it a URI? "xmpp:" ihost [ ":" port ] - Ian
RE: [jdev] Re: Two questions regarding JEP-0124 HTTP Binding
> 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://mail.jabber.org/pipermail/standards-jig/2005-June/007818.html Of course we're free to change our minds now. ;-) - Ian
RE: [jdev] Re: Two questions regarding JEP-0124 HTTP Binding
> 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 safe to try to use > the authority component address as an last-resort solution in such a case? The JEP states that the XMPP IRI indicates the "protocol, host, and port". Although the current version of the JEP does not currently explicitly exclude other IRI components, perhaps it should. The XMPP IRI SHOULD be of the form: "xmpp:" ihost [ ":" port ] Can anyone think of a use case that would be prevented if we formalise this in the JEP? If not then I would say that 'route' attribute values with a different form SHOULD be silently ignored. Also the JEP states that "The XMPP IRI specifcation does not currently allow a port in an XMPP IRI; the authors will pursue the matter within the Internet Standards Process." I'd like to fix both these points at the same time. Peter, is there any news about the possibility of including ports in an upcoming draft-saintandre-xmpp-iri-03.txt? (IIRC this was discussed on the Standards-JIG list a few months ago.) - Ian
RE: [jdev] Re: Two questions regarding JEP-0124 HTTP Binding
> 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
[jdev] JEP-0124 HTTP Binding
> 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.) Now that the cat is pretty much out of the bag, the introduction of the JEP should probably be rewritten so people can 'get' the underlying innovative idea easily on first reading. Apologies to everyone here for not doing that from the start. Please understand how tempting it was to either patent the technique, or just to keep it secret, instead of publishing it freely. In defence of the low-profile approach, two years after publishing JEP-0124, Jabber-based HTTP clients are still unique in that they always receive messages in a fraction of a second - they consume less bandwidth too. (MSN Web Messenger takes up to 21 seconds to receive an 'instant' message.) While this state of affairs lasts, I hope it helps to persuade users to adopt Jabber clients instead of those based on closed protocols. I also hope that JEP-0124 will be the 'killer technology' that motivates AJAX application developers to base communications on the XMPP standard instead of proprietary protocols (AJAX -> Asynchronous JavaScript And XMPP). This will allow developers to benefit from the existing Jabber protocols and implementations. It will also help drive our shared vision for XMPP as an XML Routing and Presence protocol (rather than just an IM protocol). - Ian
Re: [jdev] Re: Two questions regarding JEP-0124 HTTP Binding
> > 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 implementing JHB and JSJaC
> latest versions from CVS do have this issue fixed.
In fact Guus was right, 'polling' only limits the time between sending
two polling ('empty') requests:
"If the client sends two consecutive empty requests within a period
shorter than that specified by the 'polling' attribute in the session
creation response, then the connection manager SHOULD terminate the HTTP
session and return an HTTP 403 (Forbidden) error to the client."
In normal (non-polling) mode, the 'wait' period is negotiated to be long
enough that the 'polling' attribute is not relevant.
- Ian
RE: [jdev] (no subject)
> 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
RE: [jdev] Re: Difference between "Feature Negotiation", "Service Discovery" and "Entity Capabilities"?
> 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 particular situation. Entity Capabilities is about *advertising* support for capabilities that are typically available for everyone (a more efficient Service Discovery). [It doesn't make Service Discovery obsolete because entities depend on Service Discovery to find out what each new combination of entity capabilities means.] - Ian
RE: [jdev] Difference between "Feature Negotiation", "Service Discovery" and "Entity Capabilities"?
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
RE: [jdev] Best practices regarding roster management by clients ?
> 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 (there are more than you described) is to only display contacts if the user has given the person a petname and/or placed them in a group. This allows the user/client to control whether or not a contact is displayed, independent of their subscription state. N.B. this policy is not standard, it just works well in practice. > When we reach a consensus, maybe an > Informational JEP about this should be written. Yes. - Ian
RE: [jdev] JEP-0153: vCard-Based Avatars, any client support for EXTVAL
> is there a client which supports EXTVAL for supplying a URL > as vcard PHOTO? Not yet, but we plan to. - Ian
RE: R: R: R: [jdev] about spim techniques
> > 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 > > Challenge. > > I don't think it's my server or my client that does this -- > it's me. Who better to figure out if the other person is human than me? Are you saying that message triggered challenges should be handled by the server, but subscription request challenges should be handled by the user? If so, then SPIM bots will concentrate on sending subscription requests instead of messages. Of course users won't want to be bothered with these bot requests. So why not allow the server to filter out the bots - and then allow the user to filter out the unwanted humans using the techniques you described? (Especially since the server will already have the challenge functionality in place.) > I don't think that automated bot-detection methods > (client-based or server-based) are nearly as effective > as human-to-human communication. Yes. But the point is that humans don't want the job of filtering out bots themselves. Most people hate manually filtering out the SPAM from their email inbox. The cost to users of responding to an occasional Bot-Proof Challenge is small, and perfectly acceptable, when they compare it to the countless bot-generated messages/requests they would otherwise have to filter every day. > > My server should remember which users have passed my anti-SPIM test > > *and which users I have sent stanzas to*. > > Well, my client could simply update my privacy lists once I click the > big "allow communications with this person until further notice" button. Yes, but, simple clients etc. > > RFC 3921 Privacy lists aren't really designed to block presence > > stanzas that are subscription requests (and allow all other presence > > stanzas through). > > RFC 3921 enables you to block all communication from another JID, so > your first sentence is not accurate. I'm not sure you understood what I was trying to say. I meant that RFC 3921 cannot, for example, be used to block while allowing through from the same user. > Sure thing, we've talked about that before on one of these > lists. I'll work on a proto-JEP for that soon. Thank you :) - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
RE: R: R: R: [jdev] about spim techniques
> (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 the others discussed earlier - regarding registration, s2s, etc...). So you see my server generating the challenge and validating the response? I think you're right. (I had been assuming it would be my client!) 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 Challenge. My server should remember which users have passed my anti-SPIM test *and which users I have sent stanzas to*. In future those users could send me messages or subscription requests (unless I blacklisted them with Privacy lists of course). [RFC 3921 Privacy lists aren't really designed to block presence stanzas that are subscription requests (and allow all other presence stanzas through). It should still work though. If it can't be made to work then the client might have to produce the Bot-Proof Challenge itself when it receives a subscription request.] > 1. Automatic vCard lookup (who *is* this person?) Yes. Nice implementation feature. [/me adds to tasks list.] > 6. Ask people in my roster whether they know this person > (could be automated) Yes we do need a protocol for this. Of course it fits perfectly with the public key association techniques we've been discussing. - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
RE: R: R: R: [jdev] about spim techniques
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 list' > Subject: [jdev] [Standards-JIG] anti-spim techniques > > > 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 here.) > > > Has Sander (or anyone else), got some time to write a first > draft of a new generally-useful 'Bot-Proof Challenges' JEP? > This could include inband delivery of images and CPU > challenges (e.g. find a string where the least significant > bits of the hash have a specific value). > > The first application of that new 'building block' protocol > could be another new JEP that either extends or replaces > JEP-0077 (In-Band Registration). > > I'd also like to see a procedure and protocol JEP that allows > a client to complain about the SPIM it is receiving (both to > its own server and to the sending server). This JEP might > also make use of the Bot-Proof Challenges to exonerate people > and to create a barrier against malicious multiple reporting. > > If despite our other efforts we find people are still > bothered by SPIM, then clients could use the Bot-Proof > Challenges (with JEP-0155?) to verify each new correspondant, > who is not on the roster, is human. > > > Server Implementors and Administrators have a lot more weapons against > SPIM: > - Dialback > - Karma > - Invite-only and/or out-of-band registration > - Outgoing message filtering? > - IP blocking > (If admins don't use some or all of these approaches then I > agree they should be accountable for any SPIM their users send.) > > Once enough clients implement e2e encryption then people > could insist that all correspondants use it, making SPIM far > more CPU-expensive. > > > As I am confident we will be able to mitigate the SPIM > problem to the extent that: > > 1. People do not need to block all messages from people not > on their rosters. 2. All public servers are free to > interconnect (as long as they have a domain cert from a JSF > approved authority and do not appear on the authority's black list). > > As Sander mentioned, the JSF-approved certificate agreement > should legally disallow SPIM and provide tough penalty > clauses for clear abuses. (These agreements would probably > need to be drawn up under the laws of countries that are not > friendly to spammers.) > > > > what will happen if a CA gets blacklisted? > > Any certs it issues after the blacklisting are invalid. Certs > issued before *may* become invalid later if their owners > abuse (another CA could be appointed to handle that). > > > providers even might want to send email over XMPP... ;-) > > Seriously, I do expect email SPAM will motivate most people > to switch from email to offline IM delivery within the next > few years (as long as we minimise SPIM and improve our > offline message handling implementations). > > > The call to Google to open their network now, today, is not very > > realistic, because we have a lot of work to do first. > > Yes. > > - Ian > > ___ > jdev mailing list > jdev@jabber.org > http://mail.jabber.org/mailman/listinfo/jdev > ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
[jdev] [Standards-JIG] anti-spim techniques
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 here.) Has Sander (or anyone else), got some time to write a first draft of a new generally-useful 'Bot-Proof Challenges' JEP? This could include inband delivery of images and CPU challenges (e.g. find a string where the least significant bits of the hash have a specific value). The first application of that new 'building block' protocol could be another new JEP that either extends or replaces JEP-0077 (In-Band Registration). I'd also like to see a procedure and protocol JEP that allows a client to complain about the SPIM it is receiving (both to its own server and to the sending server). This JEP might also make use of the Bot-Proof Challenges to exonerate people and to create a barrier against malicious multiple reporting. If despite our other efforts we find people are still bothered by SPIM, then clients could use the Bot-Proof Challenges (with JEP-0155?) to verify each new correspondant, who is not on the roster, is human. Server Implementors and Administrators have a lot more weapons against SPIM: - Dialback - Karma - Invite-only and/or out-of-band registration - Outgoing message filtering? - IP blocking (If admins don't use some or all of these approaches then I agree they should be accountable for any SPIM their users send.) Once enough clients implement e2e encryption then people could insist that all correspondants use it, making SPIM far more CPU-expensive. As I am confident we will be able to mitigate the SPIM problem to the extent that: 1. People do not need to block all messages from people not on their rosters. 2. All public servers are free to interconnect (as long as they have a domain cert from a JSF approved authority and do not appear on the authority's black list). As Sander mentioned, the JSF-approved certificate agreement should legally disallow SPIM and provide tough penalty clauses for clear abuses. (These agreements would probably need to be drawn up under the laws of countries that are not friendly to spammers.) > what will happen if a CA gets blacklisted? Any certs it issues after the blacklisting are invalid. Certs issued before *may* become invalid later if their owners abuse (another CA could be appointed to handle that). > providers even might want to send email over XMPP... ;-) Seriously, I do expect email SPAM will motivate most people to switch from email to offline IM delivery within the next few years (as long as we minimise SPIM and improve our offline message handling implementations). > The call to Google to open their network now, today, is not > very realistic, because we have a lot of work to do first. Yes. - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
RE: R: R: [jdev] about spim techniques
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 > authority (e.g. the JSF) to get on the > whitelist. The power of a single central authority would be open to abuse in the future. If we really have to maintain server whitelists (I hope we don't), then multiple 'independent' authorities based in different parts of the world would be more acceptable. [Of course the JSF would be better than a large corporation, like Google. Only whitelisted servers would attract users, so the corporation could effectively control the network!] > The application process > must not discriminate, but must take > some time, so that it discourages repeated > applications. That way, new servers > are assumed guilty, and the only way > spam gets to users is if the spam > server's admin took the time to register > their server. That server then gets > blacklisted, and they have to wait a > whole new week to register again. What stops a spimer registering more servers before the first one is blacklisted? - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
RE: [jdev] jabber @ google talk ?
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 fallout from users who had got used to the freedom would be *much* worse. IMHO they are going about this in a very sensible way. I think the technical motivation for this beta launch is to experience how their servers cope with real load (and perhaps to test the voip too). The client we see is too feature poor to impress users of other clients (real feedback from my Aunt Tillie). > They want to get IM federation right. If that means developing some > policies around server-to-server interconnection - e.g. use TLS only > and require that the other side have a non-self-signed certificate That wouldn't stop people sending IM SPAM, but it would make it much harder. > I think that the Jabber community should take this as an > opportunity for finding and adding to the servers anything > that will prevent email problems. Yes, maybe we're all going to gain from seeing how Google approach this? [Although we'd all hate to see them require a legal agreement before allowing interconnects - imagine if all servers required that!] The only problem I have with Google's approach today is that they are claiming openness without providing any. [Today their service is no more open than AIM, Yahoo or MSN - we can use Gaim on any of those networks too.] However, IMHO their marketing department is unlikely to be positioning their service against the others on a benefit that will never exist. Their service is playing catch-up, and it doesn't need the bad publicity that would be generated if people realised it is just another closed service. What other benefit can Google offer? Skype and the other services offer more mature feature sets. They all have massive user bases with sticky buddy lists. Google has none yet. So, if the IM market is opened up to a 'level' playing field, Google has relatively little to loose, and everything to gain by being the 'first'. - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
RE: [jdev] jabber @ google talk ?
> > "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 > > share them with us at the Google Talk Interoperability Google Group." > > http://groups.google.com/group/google-talk-open > IMO the JSF should really jump into this. It sounds to me that they want > a system that prevents (or strongly supresses) SPAM on the XMPP network. Yes. - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
RE: [jdev] [ANN] Jive Messenger 2.2.0 and Asterisk-IM
> 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 now. This is exciting, congratulations! :) Does the plugin also allow two clients to talk directly using IAX without involving an Asterisk server at all? [I understand this is not always possible, e.g., if ports cannot accept connections] Do you have any very rough documention of the protocol extensions? - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
[jdev] RE: [Standards-JIG] UPDATED: JEP-0085 (Chat State Notifications)
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: [Standards-JIG] UPDATED: JEP-0085 (Chat State > Notifications) > > > On Tue, 19 Jul 2005, JEP Editor wrote: > > > Version 0.13 of JEP-0085 (Chat State Notifications) has > been released. > > How many clients out there have implemented jep-85? I have > been working lately on chat state notifications for Gajim and > I would like to test it against a different client. > > BTW, Gajim code in svn has some basic support for this JEP > (the GUI part > is überhaupt not ready). Regards, > -- > Luis Peralta > http://spisa.act.uji.es/~peralta/ > ___ > Standards-JIG mailing list > [EMAIL PROTECTED] > http://mail.jabber.org/mailman/listinfo/standa> rds-jig > ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
[jdev] All JEPs bookmark button
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:","")-0;void(location="http:
//www.jabber.org/jeps/"+(n?"jep-"+(n+1+"").substring(1)+".html":"all
jeps.shtml"))
Whenever you click on the button you'll be prompted to type the JEP
number (leave it blank for the list of all JEPs).
I hope some of you find it useful.
- Ian
___
jdev mailing list
jdev@jabber.org
http://mail.jabber.org/mailman/listinfo/jdev
RE: [jdev] 'Conference' category in roster
> > > 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 you appear > to be in the room to the MUC server as soon as you log > in to your jabber account when infact you arnt, you would be > far better implementing the above mentioned standard. With the supplied example you wouldn't appear to be in the room because the subscription is "none". [MUC implementations are unlikely to try to subscribe to a user's presence.] I agree it is a non-standard hack. RFC 3921 does not permit a 'category' attribute in a roster item. - Ian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
