Re: [jdev] obtaining XMPP accounts

[Justin Karneges]

On Tue, Dec 8, 2015, at 01:04 PM, Kevin Smith wrote:
> On 8 Dec 2015, at 21:01, Dave Cridland  wrote:
> > On 8 December 2015 at 20:53, Peter Saint-Andre  wrote:
> > On 12/8/15 1:07 PM, Dave Cridland wrote:
> > 
> > Certainly I do have the feeling that as an
> > end user, obtaining an XMPP account is now very hard, with the effective
> > closure of end-user services from jabber.org  (the
> > obvious go-to public server) and the dropping of XMPP by Google Talk -
> > 
> > I'm not sure I'd say "very hard" - there are still plenty of servers listed 
> > at xmpp.net. Could it be easier? Probably. It might be good to have a page 
> > about that at the new xmpp.org website.
> > 
> > By comparison to ${ARBITRARY_IM_SERVICE}, yes, I think it is very hard. Our 
> > on-boarding process is nothing like as easy as the somewhat commonplace 
> > "Download app, run app, do some registration dance" - instead it's 
> > "Download app, go to some website, go to some other website and try to 
> > figure out how to create an account, configure app."
> > 
> > It was better - for the user - when XEP-0077 was commonplace, since at 
> > least a client should ship with a list of servers. Of course, that level of 
> > simplicity brought its own problems, but I think we could make that process 
> > a lot smoother without compromising security entirely.
> 
> I think there’s a fair argument for simply having an advertised HTTPS
> endpoint for servers that clients could then present to the user. It’s
> not as satisfying to do it out of band, but it’s also very often what
> these easy-to-register-with apps do, and it’s somewhat richer than 77.

To me, the big issue with registration is making it easy for a user to
determine which server is right for them. It's a decision most of us
wouldn't take lightly. The user needs to realize it's more than just a
JID domain name selection, but a relationship that they are entering
into with the service provider. I like the idea of tossing the user to a
website because it helps start building that relationship.

*crawls back into cave*
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] Silicon Valley Realtime meetup

[Justin Karneges]

Hi folks,

I've started a meetup in the SF bay area to discuss realtime topics.
This would be the place to discuss XMPP in the absence of an active
XMPP-specific meetup. We are keeping the scope wide, so it's not just
about push technologies. Topics like stream processing or reactive
user interfaces would also be fair game. Hopefully this leads to a
larger membership.

http://www.meetup.com/Silicon-Valley-Realtime/

If you're in the bay area, please join the group! First meetup
tentatively August 12th.

Also let me know if you'd like to present. The plan is to select 2-3
speakers for each event.

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] Fanout hiring (SF bay)

[Justin Karneges]

Hey folks,

Fanout ( http://fanout.io/ ) raised money this summer so we can actually 
afford to pay people. Hooray!


If you're a high scalability person that can hack in C/C++/Python and 
you live in the SF bay area, let me know.


Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Buddycloud. Hosted.

[Justin Karneges]

On 04/18/2014 08:23 AM, Abmar Barros wrote:

The Buddycloud team is pleased to announce the release of the Buddycloud
hosted platform.

Buddycloud hosted enables developers to quickly start using Buddycloud
by providing a self hosted version of the full stack, which means an
XMPP-enabled domain, all Buddycloud components, a webclient and an
XMPP-FTW proxy.

Besides creating new subdomains under the *.buddycloud.com
http://buddycloud.com namespace, developers are also able to bring
their own domains by adding a few DNS records, or even bring their own
XMPP servers with an existing user base.


Very cool!

___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] [Security] Spoofing of iq ids and misbehaving servers

[Justin Karneges]

On 01/31/2014 01:51 PM, Thijs Alkemade wrote:

Only two clients I've looked at verify that the 'from' actually matches the
'to' the iq was sent to:

* Pidgin (libpurple): incrementing counter starting from a random value
* Swift: UUID


Also Iris-based clients (Psi, Kopete, Kadu). Iq ids aren't random but 
the from address is checked.


Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] Early-stage startup opportunity in SF area

[Justin Karneges]

Hi list, here's some job spam. :)

I'm looking for a smart developer to join the Fanout team for equity only
(no salary). Check us out at http://fanout.io/

Keywords: Realtime, Push, HTTP, XMPP, Python, C++, ZeroMQ, Redis, APIs

At Fanout, we're making realtime technology more accessible and scalable.
Our core product is a CDN service for realtime data delivery. Unlike other,
similar offerings, Fanout goes further by placing emphasis on versatility,
standards, and openness.

If you don't have kids yet, can afford to burn money for a few months, and
are bored at your stable, well-paying job, try taking a risk and hit me up.
It'll be a lot of fun.

We've also applied to Mozilla's WebFWD accelerator program. If we get
accepted this July, then you get to participate in that, too.

To be clear this is pre-funding, equity-only. Commitment should be
part-time or full-time. Concurrent full-time employment elsewhere is not
acceptable. Must be in the SF Bay area and willing to meet regularly near
Mountain View. If interested, email me privately.

Thanks!

-- 

Justin Karneges

Fanout, Inc.

530-220-7222
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] decentralized omniscience

[Justin Karneges]

On 03/29/2013 09:55 AM, Kevin Smith wrote:

On Sat, Mar 16, 2013 at 12:11 PM, Justin Karneges jus...@affinix.com wrote:

The reason I bring this up here is to discuss some protocol. I think all
that is really needed for a system like this to work is for the smart entity
to act as a proxy.


Is this the same idea as the BC inbox, where you request lots of feeds
and you have a local service that massages them to send to you?


I'm not familiar with BC inbox but it sounds similar. The tricky part is 
making sure the smart entity in the middle (the inbox or such) has 
access rights to the feeds. For example, if the feed is private but has 
granted access to your JID, then you'd need a way to have access granted 
to the inbox JID as well. Does BC have a solution for that?


My suggestion is to generalize the approach of having one entity act on 
behalf of another.


Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] decentralized omniscience

[Justin Karneges]

In thinking about federated social networks, I started to wonder if certain 
features enjoyed in monolithic systems might not carry over very well to our 
world. There are many situations where Facebook tailors your view based on its 
all-knowing graph database, but these kinds of things may be hard to pull off 
when there isn't any all-knowing entity.

Take, for example, the case of viewing a Facebook post that contains many 
likes. If any of your friends liked the post, then their identities will be 
placed in the data summarization of that post. This scales well, too. A public 
post which might have 1 likes will still manage to include your 1 friend 
that liked the post in the summary.

I'm not sure if it's possible for these kinds of features to exist fully 
decentralized (or at least not without it being insanely complex), but we of 
course we don't want a wholly centralized system either. Maybe there's a 
middleground, whereby complex brainpower can be offloaded to special services 
dedicated to the task, without putting everything in that basket. I'm thinking 
of a model like the web and search engines. The web is functional without 
Google, but Google adds a lot of all-knowing value to those who wish to use 
it. So, perhaps services like Buddycloud could take care of all the storage, 
actions, federation, etc, but then separate smart searchy entities could be 
optionally integrated to augment the experience.

The reason I bring this up here is to discuss some protocol. I think all that 
is really needed for a system like this to work is for the smart entity to act 
as a proxy. So, when fetching a post, you'd send a request to the smart 
entity, which then requests out to the post source. If the post has 1 
likes, then the smart entity would need to download all of these and create a 
customized summarization to be returned to the initial requester. Oh, and of 
course we'd need a way for the post source to validate that the smart entity 
can act on behalf of the initial requester. The smart entity should not have 
full access to everything, but only what it is able to see based its users. 
The end result is that there isn't necessarily any smart entity that knows 
*everything*, but perhaps several that independently know enough to get the 
job done for their users. Like search engines on the web, these smart entities 
of federated social networks could be proactive in crawling, subscribing to, 
and caching data, such that in many cases they will immediately have answers 
for their users without needing to proxy out every time.

Perhaps this could be accomplished with something like XEP-291 (to allow your 
JID to vouch for a third party JID allowed to act as you), and SHIM (for the 
proxied request to stamp who the original requester was).

Is that it? Can anyone think of a smart feature they've seen on Facebook or 
Google+ that could not be accomplished with this very simple protocol? Maybe 
there are some features that absolutely require a central entity?

Justin___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] XMPP APIs

[Justin Karneges]

On Saturday, January 12, 2013 01:03:59 PM Jonas Wielicki wrote:
 It seems just natural to me to use XMPP for that purpose, however, I'm a
 bit cautious with just accepting the XMPP servers authentication. I know
 that I'm pretty safe when I'm doing that between my own servers running
 on the same machine, but from outwards I could easily be MITM'd.

Good point. I think this problem can be mostly solved with TLS and s2s. My 
plan, which I have not yet implemented, is to allow setting a TLS required 
flag on any whitelisted JID. The XMPP server itself would not enforce TLS, and 
instead negotiate it opportunistically, but I'd need to hack it to tell my 
server app whether an incoming stanza arrived from a TLS-protected stream or 
not, so that my server app could make the choice of whether to accept or 
reject.

 In another project, we thought about using XMPP for a website commenting
 service. We didn't come to a coherent design though, mainly as one has
 to consider that not everyone has s2s-capable XMPP (which would require
 an HTTP alternative) and that most XMPP clients are not made to create
 longer comments.

True, it's a steep requirement to insist that someone have an XMPP server in 
order to access your service. I think whether you can get away with this or 
not depends on the nature of your service. If it's sufficiently advanced, like 
say, Buddycloud federation, then I think people can accept it as the rules of 
the game. But if it's just CRUD stuff that you want people to be able to whip 
up simple apps for, then you pretty much have to offer HTTP at minimum.

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] XMPP APIs

[Justin Karneges]

On Saturday, January 12, 2013 10:07:02 PM Waqas Hussain wrote:
 Another thing we have discussed in the past is exposing Prosody APIs
 (our internal public APIs, used by plugins) using something like
 HTTP+JSON or XML-RPC or even SOAP. The ability to fully orchestrate,
 manipulate, script a server using the language of your choice would be
 fairly interesting and powerful. SOAP isn't pretty, but it does have
 the nice property of being supported by various languages and IDEs. In
 some IDEs you can add the HTTP SOAP end-point as a library, and write
 code as if it was a local library, including getting code completion,
 etc. Such a thing would be a non-trivial amount of work, but
 interesting nonetheless.

Neato. SOAP is one of those protocols that always seemed like a good idea to 
me but I somehow never encountered in real life. :)

HTTP+JSON built into an XMPP server? That just might be useful and the irony 
kills me.

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] XMPP APIs

[Justin Karneges]

Hi people,

The web service API world seems to be all about HTTP, but I'm hoping to show 
that XMPP can be useful here too. For Fanout.io, I've made it so that the 
entire functionality is available via HTTP *and* XMPP. This means that for 
every REST endpoint there is an equivalent XMPP ad-hoc command. Additionally, 
there is a chat bot that you can interact with using an IM client, which 
supports much of the functionality as well.

One nice aspect is that auth is a breeze. You whitelist a JID and you're done. 
No futzing with per-call auth tokens like with the REST API.

This has actually been in place some months. Can't remember if I mentioned it 
at the summit. But I finally wrote about it now:
  http://blog.fanout.io/2013/01/12/using-the-api-via-xmpp/

Is anyone else doing this sort of thing?

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Local history storage

[Justin Karneges]

On Wednesday, December 19, 2012 08:14:34 AM David E. Ammouial wrote:
 I'm currently switching from Gajim to Empathy (trying it out becomes I'm
 discovering GNOME 3), and as a user I'd like to express a wish to client
 developers: IMHO, clients should store the chat history at the same place.
[...]
 Of course, the exact format would need to be thoughtfully defined, but
 does the goal itself sound reasonable?
 
 (I'm well aware of the efforts to store history on server side, but I
 think local history will still be around for a while.)

I've been wanting this since forever. Email has mbox and Maildir. IM could use 
something similar. Maybe we could even just use an email format (conversations 
in RFC822 format anyone?). I say it now just so it gets said.

Early revisions of XEP-136 included a XML file format spec, though it was 
removed due to being out of scope. Maybe someone can start a new XEP that 
specifically discusses a file format. Even though it's not a network protocol, 
I 
think the XSF is not a terrible place to pursue this. It reminds me of XEP-38 
(emoticon file format).

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] message queuing

[Justin Karneges]

Hi people,

At my last job we used an XMPP server to route messages among components. This 
was my first time building a multi-node server architecture, after spending 
years as primarily a client developer (though heavily engaged with fellow 
server developers in the XMPP community all that time). Things worked well at 
first, but broke down as the number of dependent components grew and we needed 
functionality like load balancing and high availability of individual XMPP 
components. We first addressed these issues by writing custom XMPP queuing 
behavior code, but then eventually dumped everything for Celery, a non-XMPP-
based job queuing system.

Today I posted an article about how XMPP is often misapplied, or at least can 
easily become misapplied as a service grows. I argue that XMPP makes most 
sense as a public edge interface and not as any kind of core engine:
  http://blog.fanout.io/2012/10/17/standards-at-the-edge/

Of course, if anyone were to build a message queuing solution on top of XMPP 
then this would mostly invalidate my article. But I don't think this has 
happened yet? Also, don't misread this as hate on XMPP. The protocol does what 
it does, and this is a fine thing.

Curious about others' experience in the clustered server space.

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] Announcing Fanout.io, the versatile push service

[Justin Karneges]

Hi folks,

I want to let you know about my new project, Fanout.io. I've been working on 
it since last October, but it is now ready for real use.

Basically it's a CDN service for outbound XMPP or HTTP traffic. For example, 
suppose you're building an XMPP service that may have a lot of instantaneous 
outbound traffic (e.g. a pubsub service with many subscribers). Instead of 
trying to send a thousand stanzas yourself from a single server, you send a 
single stanza to Fanout, and it will delegate the transmission to a set of 
worker servers that each handle a slice of the deliveries.

It's also got some really good HTTP stuff, for those that need it, like 
webhooks and long polling. Your one stop shop for scaling push.

Here's the full announcement:
  http://blog.fanout.io/2012/09/03/realtime-multicasting-over-http-xmpp/

I'm very interested in feedback. :)

Thanks,
Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

[jdev] _jabber._tcp needed anymore?

[Justin Karneges]

I'm curious if anyone still needs to put this in their DNS to support legacy 
servers?  Does anyone do it?  I noticed I had it in mine.  Anyone know when 
_xmpp-server showed up in jabberd1?

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] KRTConf

[Justin Karneges]

On Wednesday, November 09, 2011 04:16:48 PM Peter Saint-Andre wrote:
 On 10/27/11 1:48 AM, Julien Genestoux wrote:
  Hello all,
  
  I hope nobody will be upset at me, but I'd like to make sure everyone
  knows about this event.
  Next month (Nov 7+8), the first Keeping it Realtime conference will be
  held in Portland OR : http://krtconf.com/
 
 How was the conference? Unfortunately I was unable to attend...
 
 Peter

It was really awesome.  There wasn't a whole lot of XMPP but it's not like the 
talks were particularly HTTP-focused either.  Most of the discussion 
surrounded frameworks, the challenges of writing realtime code and scaling it, 
and business aspects.  Pretty cool to have a whole conference about realtime.

Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Fwd: XMPP in the browser -- your thoughts?

[Justin Karneges]

On Monday 21 February 2011 11:11:09 Matthew A. Miller wrote:
 (Apologies for the delay in publicizing; sickness overtook me)
 
 One of the guerilla conversations at the XSF Summit was about XMPP usage in
 the browser.  Below is the first documented follow-on.  Most of the rest
 of the responses were about general acceptance of the concept, hence
 they're omission.
 
 I'll try to forward the more substantive comments soon (and/or urge the
 original participants to respond again here).

Very nice.

I'll add some comments:

  2. XMPP doesn't scale and doesn't belong in serious high-volume web
  services. It is my understanding there's compelling real-life data
  showing the high level to which XMPP can be scaled. I'm not the right
  person to provide and discuss this evidence, however.

XMPP can be scaled fine, but the web works differently than IM.

Typical IM connections are long-lived and low traffic.  The web on the other 
hand generates far more transactions during normal use (some web pages require 
100+ HTTP requests to load), and caching (at all layers: browser, different 
tiers on the server) is what allows high-volume services to be possible.  If 
every page hit were to result in an XMPP session being instantiated, and your 
web service is largely utilized through new page hits (e.g. you're a typical 
website, and not some long-running webapp like a chess game), then this will 
incur significant load.  Indeed I can't imagine any serious service working 
this way.

If XMPP is used in the browser, it should be done in such a way that the XMPP 
session transcends individual page loads.

  3. Websockets would be better.
  I think Websockets would be different—better in some ways, for
  certain—though without XMPP's instant depth of features and flexibility.
  And I would hope to see an adoption of Websockets. This isn't either/or.

Websockets is here already and it is only interesting for pushing to a specific 
web page.  You would not go into your browser preferences to set up some 
global Websockets user account like you might with XMPP.  One could make a 
case for some XMPP over Websockets transport binding, but beyond that these 
are two separate technologies with different purposes.

-Justin
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] s2s implementation

[Justin Karneges]

On Sunday 31 October 2010 07:10:26 pablo platt wrote:
 server1 has 100 online users
 server2 has 100 online users
 the servers are disconnected.
 
 Now the servers connect.
 The online users won't send probes so they won't know about users on the
 other server
 until they sign out and login again.

Are you saying there are two servers with many users, but the network 
connection between the two is unusable (e.g. network outage) for some time 
period?  If so, then you are correct.  If presence fails to deliver, then in 
general it is lost for good.

 It might be acceptable but it's not completely in sync unless the server
 send probe on behalf of already online users.

Which it could (and probably should).

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Best ways for a JID to advertise what services it uses?

[Justin Karneges]

On Tuesday 21 September 2010 07:15:40 Dave Cridland wrote:
 On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote:
  The answer to this is key to interoperability for pubsub. If I can't
  discover the location your nodes I cannot interoperate with you.
 
 Right, and the ideal answer is to use PEP - or rather,
 pubsub-onna-jid.
 
 But in some cases you don't want to (because your PEP service is
 minimal) or can't (because you have no PEP at all).
 
 It's not yet clear to me that a solution is possible.

And maybe you're not always looking for a pubsub service.  There's all sorts 
of additional metadata and application logic that one might want to associate 
with a user account.  However, it's not practical that every XMPP user account 
server in the world implement every extension.  And having to limit your 
application to only those user accounts with special baked-in extensions 
sucks.

At Livefyre, we've attempted to solve this problem by introducing the idea of 
delegate services.  Instead of adding extensions to the user accounts 
themselves, any arbitrary user account is able associate itself with a 
delegate service which provides the extensions.  The problem with this, of 
course, is the same as that of the pubsub problem: given a user account JID 
alone there is currently no way to know what or where the delegated services 
for that JID are.

Something like this might help:

iq type=get to=u...@example.com id=1
  query xmlns=http://jabber.org/protocol/delegate/
/iq

iq type=result from=u...@example.com id=1
  query xmlns=http://jabber.org/protocol/delegate;
service type=pubsub jid=users.freepubsubforall.com/
service type=livefyre jid=services.livefyre.com/
  /query
/iq

Just tossing it out as a rough idea to start from.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] presence subsription rejection notifications whi le offline.

[Justin Karneges]

On Wednesday 12 May 2010 08:54:14 Peter Saint-Andre wrote:
 On 5/12/10 9:12 AM, Philipp Hancke wrote:
  Daniel V. Grillo wrote:
  Hi Folks,
 
  I've built a minimal xmpp client to keep track of contacts presence
  status.  In previous versions, if a user asked a contact for a
  subscription to presence, my client automatically granted it.  Now I
  want to notify a
  contact of such a request and let them grant or reject it. I have it
  working according to rfc 3921 section 8.
 
  I do have one question/issue though.  If a users presence request is
  denied by the contact while the user is online, he gets notified of the
  rejection as defined in section 8.2.1 (using the ejabberd server).  I
  can then pop up a notification stating so and so rejected your
  request. But if the user is offline when the rejection happens, and
  then logs in, he gets no such notification.   He just gets his roster
  with that contact in the none state with the ask flag stripped and
  no indication of how that contact got that way. Since  a contact can end
  up in the none state in various ways, I can't use that fact to pop up a
  notification. So my question is, how can I give a user notification that
  his subscription requests were rejected while he was offline?  I see
  that psi has the same issue and so does Exodus. They give rejection
  notifications while the user is online, but not when he got the
  rejection while logged off and then logs on. Any way to implement such a
  feature?
 
  This might be possible by storing the unsubscribed stanza on the server
  when the user is offline, ie. adding a rule similar to the fifth rule of
  section 3.1.3 in section 3.2.3 in 3921bis-06, and then sending this when
  the roster is fetched.

 Yes, I suppose we could add a note about this to rfc3921bis (currently
 we assume that the unsubscribed is merely an FYI and not something that
 the receiving server needs to continually poke the client about).

I wondered if servers lately were not relaying unsubscribed events, at least 
in the case of breaking an active subscription, because many people find the 
event to be rude.  I know that breaking an active subscription isn't the same 
as denying a subscription request, but I'm sure there's overlap in the code 
so I just wanted to throw that out there.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Working around NAT problems: pwnat

[Justin Karneges]

On Saturday 17 April 2010 17:21:39 David Ammouial wrote:
 Hi, I just came across pwnat[1], that facilitates communication between
 two NAT-ted computers. I'm forwarding the information here, in case it
 can help in any Jingle-related research.

Yup, previously discussed here:
  http://mail.jabber.org/pipermail/jdev/2010-March/088164.html

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] about GSOC idea on psi( Jingle RTP Encryption)

[Justin Karneges]

Hi,

On Wednesday 31 March 2010 00:49:15 yu xue wrote:
 Currently my understanding about this project is just to implement in SRTP
 in Psi, either in avcall module or in a lower module according to the
 relationship that SPTP needs with the RTP session.Could some developers
 please give me some detailed or instructions on how to better understand
 and prepare this project or suggestions on writing proposal.Thank you!

Psi's Jingle voice calling support spans three modules:

  psimedia: Small wrapper to the GStreamer library.  It handles multimedia 
device access and device selection, codecs, and RTP processing.  It does not 
directly access the network.  It is the application's responsibility to 
obtain RTP packets from the network and feed them to psimedia.  Likewise, RTP 
packets produced by psimedia must be sent over the network by the 
application.

  iris: This library provides XMPP and ICE functionality.

  avcall: This is part of Psi itself and contains two subparts:

jinglertp: Implements XEP-0166 (Jingle), XEP-0167 (Jingle RTP), and 
XEP-0176 (Jingle ICE-UDP) all at once.  It uses the XMPP and ICE facilities 
of iris.  Long term we'll want to break this code up so that we can support 
more Jingle things than just voice calls, like file transfer.  But, for now, 
this all-in-one blob is what we have, and it offers a simple API: connect to 
a JID, and you are given an abstract packet pipe that you can read/write RTP 
packets with.

main avcall code: bridges the jinglertp and psimedia parts together and 
offers a user interface.

  Also of note is the qca library, which we use for our security needs and 
contains most of the common cryptographic primitives.  Probably SRTP can be 
implemented using qca functions.

Where SRTP fits into this stack depends on what kind of knowledge it needs 
about the RTP session state.  So you must first read the SRTP specification 
and fully understand its requirements.  Further, make sure you know how SRTP 
may be used with sessions involving more than 2 participants (group 
multimedia conferencing), since that's an area we'd like to explore someday.

If it turns out that SRTP can process arbitrary RTP packets, then probably it 
can be kept out of the psimedia layer.  SRTP encryption could be applied to 
packets after they come out of psimedia, and incoming packets from the 
network could be SRTP decrypted before being fed into psimedia.

Let me know if you have further questions or need more explanation.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] New(?) NAT-to-NAT client-server tunneling method

[Justin Karneges]

On Monday 29 March 2010 05:10:42 Pedro Melo wrote:
 Hi,

 found this today, seems to work between my office and home networks,
 both behind NAT.

 http://samy.pl/pwnat/

Clever. :)  The core mechanism should be slightly less effective than normal 
STUN.  What's novel about it is that it doesn't require an external signaling 
channel.  It is quite hacky though.  Particularly the ICMP trick would send 
lots of useless packets when you're not using the service.  But, if you have 
a strong need to set up a proxy server on a network where you have no NAT 
control and don't want to have to use or maintain an intermediary service to 
act as a signaling channel, then this looks like a neat tool.

It probably has no fit with XMPP though.  We have a signaling channel where we 
can use STUN correctly.  And we can do more than just STUN, too.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] questions about gsoc: file transfer over jingle

[Justin Karneges]

On Saturday 27 March 2010 01:35:18 Zhenchao Li wrote:
 the problem: AFAIK there isn't an XEP defined for
 ICE-TCPhttp://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-08,
 it's a work in progress. What we have is one for
 ICE-UDPhttp://xmpp.org/extensions/xep-0176.html.
 But unlike voice or video transmission, file transfer needs to ensure
 packet integrity, which rules out FT using ICE-UDP only. Implementing a
 ICE-TCP stack requires much design and careful implementation, and even
 sounds like another gsoc project. After some search I find that the libnice
 library implements ICE-UDP as well as a pseudo TCP
 implementationhttp://nice.freedesktop.org/libnice/pt03.html.
 Perhaps that's one viable way to transfer file?(At the risk of rewriting
 this transport method sometime in the furture when ICE-TCP is
 standardized.)

IMO, we should prefer pseudo TCP together with ICE-UDP if we need a reliable 
stream, instead of ICE-TCP, as it is more likely to succeed without needing 
to use a relay service.  This way, file transfer would operate just as well 
as voice/video transmission, instead of being slower or failing.

ICE-TCP is still useful (clean usage and transition to IPv6, or for networks 
that block UDP), but just not nearly as useful.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Resource binding

[Justin Karneges]

On Thursday 11 February 2010 19:53:10 Peter Saint-Andre wrote:
 On 1/30/10 9:22 AM, Tomasz Sterna wrote:
  Dnia 2010-01-29, pią o godzinie 07:52 -0700, Peter Saint-Andre pisze:
  You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose.
  It's not clear to me if we absolutely need multi-resource support in
  order to have private MUCs. And I wouldn't want to have a dependency
  on the server to provide private MUCs anyway.
 
  One may always establish multiple connections to bring up more
  resources.
  But I think resource binding is way simpler method.
 
  BTW: What was the exact reasons for dropping it?
  I didn't find it nor confusing, nor hard to implement.

 That's helpful feedback.

  Pros:
  - does not add another flow, just reuse existing one
  - easy to implement (servers already support one resource bind and
  multiple connections from one client)
  - very straightforward once you get what resource bind is
(and you need to bind one)
 
  Cons:
  - ??

 - Changing the existing flows for resource binding
 - Managing multiple resources on the client side
 - Knowing when the session is really finished

 I'm sure were other reasons but I'd need to re-read the list archives to
 remember them.

Also, the feature seemed to come out of left field.  Maybe I missed the 
discussion, but to me it felt like this feature was just a case of Why Not? 
rather than being born from real necessity.  That doesn't make it a bad 
thing, but I want to remind that we should be conservative about our changes 
to the core specs.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Login with SASL credentials unrelated to domain username

[Justin Karneges]

On Sunday 15 November 2009 11:59:24 Kurt Zeilenga wrote:
 Anyways, some servers might have authcid which are not JIDs.  For instance,
 my authcid might be Kurt Zeilenga.  XMPP clients should, just like most
 email clients do, the option to enter a authcid that's different than the
 user's JID (just like email clients allow for authcids which are different
 than the user's email address).

I'm not 100% sure if it works since I've never tested it personally, but in 
Psi you can go to the Misc section in the account settings and use 
the Authenticate as area to set a specific username (authcid).  If 
unspecified, then the authcid is assumed to be the JID node.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] XEP-0153 Avatars conflict with several resources

[Justin Karneges]

On Tuesday 22 September 2009 12:43:22 Robert Quattlebaum wrote:
 I know google talk does this, or something similar. I believe they do
 this because they found several clients which were not properly
 calculating the hash or the image in te vCard.

It also has the nice effect of making your avatar continue to work even if you 
use a client that does not support avatars (e.g. temporarily using a mobile 
client or something).
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] wildcards vs. multiple certs

[Justin Karneges]

On Wednesday 26 August 2009 13:31:13 Peter Saint-Andre wrote:
 As a result, it is possible that admins might feel the need to request
 multiple Class 1 certs in order to deploy an XMPP service (if they are
 not able to obtain a Class 2 certificate). For example, at the
 jabber.org service we might use one Class 1 certificate for the domain
 name jabber.org and another Class 1 certificate for the domain name
 conference.jabber.org. This would require our XMPP server software to
 present the jabber.org certificate when a peer server attempts to open
 an s2s connection to the jabber.org domain, whereas it would present the
 conference.jabber.org certificate when someone from a peer server
 attempts to join a chatroom at the conference.jabber.org MUC service. I
 do not know of any XMPP server software that can present two (or more)
 different certs for s2s connections depending on the domain name
 specified by the peer server.

You can put many names into one cert.  For a short set of domains, this ought 
to be practical.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] a vision

[Justin Karneges]

On Thursday 12 March 2009 10:24:21 Pedro Melo wrote:
 As for the IM service, I would keep it running and continue to accept
 new users as the backup route for new jabber users: if they are not
 introduced to a more local jabber service then you can always have
 Jabber.org.

A friend once said to me: I hate Jabber, it's always down!  True, jabber.org 
had gone down for several minutes while he was in the middle of chatting, on 
multiple occasions.  He can be rightfully angry about that, but I had to 
explain to him that it was jabber.org, not Jabber which was at fault.

From then on I always recommended Google Talk to new users.  It doesn't really 
matter if Google has better uptime.  The point is to get the blame right.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] a vision

[Justin Karneges]

On Tuesday 10 March 2009 16:24:50 Peter Saint-Andre wrote:
 None of this would be exclusive. We'd still strongly encourage people to
 run their own XMPP services and join the network. But we'd also work
 hard to have worldwide coverage under the jabber.org banner.

This proposal reminds me of our discussion in Portland last year with 
Christopher Zorn, about the future of Psi.  I was all tied up in a knot 
because I felt that to truly target average users, Psi would have to be bound 
with a service, but that doing so would taint Psi's image and go against the 
point of Jabber.

You see, I have this idea that there's generic Jabber services and clients and 
then there's integrated services like Google Talk and SAPO, but only the 
generic offerings count as being part of the Jabber ideal.  Christopher 
basically said this view is too limiting.  Is Chesspark not part of the 
Jabber ideal then?  His point was that in the end it's all about offering 
great software and services, and holding on to this generic client idea is 
self-defeating.  Normal people don't want generic building blocks.

One compromise we discussed was to have Psi affiliate with jabber.org (rather 
than some Psi-specific service) to attempt to retain client/service 
separation while still making it easier for end-users to get set up.  I think 
Christopher also felt this was silly (again, why *not* capitalize on this 
opportunity to offer your own service?), but what can I say I'm a Jabber 
philosophy idiot.  In any case, we reasoned that users would find the 
dual-branding confusing.  First they visit the Psi website, then suddenly 
they are signing up for a jabber.org account...  WTF?  Seems shady.

Speaking of first they visit the Psi website, Christopher argued that users 
will start at the client, mainly because it is the face of the service.  They 
will see the software running on a friend's computer, or they'll see a 
screenshot or such, and think Hey, that's pretty cool, I want that.  The 
approach of going to jabber.org and having to pick a client is backwards.

If your vision is to take on Skype directly, it sounds like what is needed is 
a strong front-running client that has matching branding of the service 
itself.  To most users, the client and service would be synonymous with each 
other, as is the case with Skype, MSN, etc.

The big question of all is whether it is the job of jabber.org to compete with 
Skype.  Aren't there others in this space already trying to do that?  If 
jabber.org is truly competitive, and no longer a self-defeating reference 
service, is it still fair to use the Jabber name?  Peter, you may remember, 
one of the options we discussed was to actually get rid of jabber.org 
entirely. ;-)

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] a vision

[Justin Karneges]

On Wednesday 11 March 2009 18:57:36 Peter Saint-Andre wrote:
 Well, we have 400,000+ users of the jabber.org IM service. Shutting down
 the service seems unworkable. So the questions are:

Right, you wouldn't want to really remove it.  Instead:

 1. Do we turn off registration for new users and redirect people elsewhere?

Yes.

 2. Do we leave the jabber.org service as basic IM but nothing more?

I don't think there's anything wrong with improving the service for the people 
already using it, but it would be with the understanding that jabber.org is a 
very generic IM service, only good for testers, geeks, and anyone who already 
has an account there.  It would no longer be a place you'd send your mom.  
You'd send your mom to Google Talk, or any service competing on that level.

Feel free to spearhead such a competing service.  I didn't disagree with your 
vision.  In fact, this idea of a collaborative, open, world-wide service 
sounds incredible, if you can pull it off and maintain five nines. :)  I just 
don't think using the name Jabber is wise.  A giant service named Jabber, 
with a client named Jabber (JIM? :)) only adds naming confusion, and may be 
perceived by competitors as unfair (we want them to use the word Jabber as 
much as possible, and not be afraid of it).

I think you'd have just as much success calling the client+service Andre-IM 
(ahn-dream?), which could then be promoted as a Jabber-based Skype killer.  
This would be fair as well as easier to market.

 3. Do we try to deploy the kinds of services that are needed in order
 for people to have a better experience? As far as I can see, those
 services are SOCKS5 and TURN relays for file transfer and voice/video.
 But we can't deploy just one of those (it would be overloaded) so we
 need to deploy them more widely -- perhaps just Europe and North America
 to start, but eventually in many locations so that people can use local
 relays everywhere.

I don't think it can hurt to do this, if the resources are there.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Scope of current RFC3920 SASL implementation

[Justin Karneges]

On Sunday 25 January 2009 10:30:39 Dirk Meyer wrote:
 If you only do SASL, you can not be sure that someone changes the data
 after the SASL authentication. Maybe you don't need to if you trust the
 XMPP servers involved.

It depends on the SASL mechanism.  With DIGEST-MD5, for example, you can have 
a mutually authenticated session with integrity protection (and encryption).

I think our e2e proposal should promote TLS + SASL EXTERNAL as the common 
case, but we should not require TLS and we should allow any SASL mechanism.  
This way, someone could create a password-based service running at a JID.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] facebook jabber?

[Justin Karneges]

On Sunday 25 January 2009 13:03:12 Tim Julien wrote:
 anyone heard any updates on this?

 http://developers.facebook.com/news.php?blog=1story=110

http://bugs.developers.facebook.com/show_bug.cgi?id=3152

The latest word as of November is: some people are working on this.  it will 
probably be done in a few months.  sorry the timeline isn't more clear.
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] GSSAPI and service hostname

[Justin Karneges]

On Thursday 15 January 2009 08:51:30 Peter Saint-Andre wrote:
 As we discussed in the jdev room yesterday, I think you would use the
 machine-name that you discovered via SRV lookup:

 http://logs.jabber.org/j...@conference.jabber.org/2009-01-14.html#16:01:06

Yes, this is the consensus.

There is, however, some worry about DNS-based attacks, since the connect host 
is derived insecurely through the SRV lookup.  One obvious but totally 
impractical fix is to use DNSSEC.  Another is to use XEP-233.  Yet another is 
to offer some explicit trust mechanisms in the client (e.g. a field where the 
user can type the connect host in advance, to mark as trusted).

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] GSSAPI and service hostname

[Justin Karneges]

On Thursday 15 January 2009 10:02:24 Matthew A. Miller wrote:
 Besides, XEP-233 isn't any more secure than the SRV lookup.
[...]
 *  If you trust the XEP-233 result because you've got a secure channel
 (STARTTLS) and trusted their certificate, then why can't you now trust
 the SRV result?

Hmm, this is an interesting question.

TLS validates the XMPP domain, not the connect host found in the SRV result.  
So an attacker could feed you an incorrect SRV result here, and then route 
your traffic (as-is, not attacking TLS) to the real XMPP server.  This would 
be enough for an attacker to cause you to use the wrong host in the Kerberos 
negotiation.

However, it's not clear to me if there is a real attack here.  With the wrong 
host, you may obtain a wrong Kerberos ticket but you'll attempt to use it 
with the right host which will result in a failed authentication (a DoS).  
Maybe if the right host has multiple host keys for the xmpp service, the 
attacker could cause you to successfully authenticate to the wrong XMPP host?  
Well, whether that attack is really a problem or not, at least XEP-233 does 
close it off.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___

Re: [jdev] Initial presence and contact capabilities

[Justin Karneges]

On Thursday 04 December 2008 07:10:25 Jonathan Schleifer wrote:
 That's the problem, the presences are often not synced when an s2s
 connection is established. Not all presences are pushed out in the s2s
 connection. And offline presences often aren't as well, so that people
 are online for ages. Sending all of them, even the offline ones, in
 one stanza would fix that.

In rfc3921bis, section 4.3.2 #2, the remote server being probed SHOULD reply 
in the offline case.

Granted, there's no guarantee that the server actually will, but the idea with 
the 'SHOULD' here is that we'll start encouraging the behavior.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] How to do SASL authentication in C/C++

[Justin Karneges]

On Tuesday 11 November 2008 20:17:19 ashiraz wrote:
 Is it possible for me to setup my own jabber server on local machine,
 log in to that server (on my local machine) and THEN try to send
 messages as an account holder to something like [EMAIL PROTECTED] (a
 chatroom)?

If your local machine is publicly reachable and has a valid domain name, then 
yes.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] How to Do Groupchat in Jabber

[Justin Karneges]

On Tuesday 11 November 2008 22:03:03 ashiraz wrote:
 After a long pause I get this response :

 presence from='[EMAIL PROTECTED]/IETF Announcer'
 to='[EMAIL PROTECTED]/MyResource' type='error'

 error code='404' type='cancel'remote-server-not-found
 xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/
 /error
 /presence

 message from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]/MyResource'
 type='error'
 bodyhello my friend .../body
 error code='404' type='cancel'
 remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/
 /error
 /message

These are essentially generic bounce responses indicating that a working XMPP 
stream could not be established between your server and jabber.ietf.org.

The problem is that 'henryviii' isn't a valid domain that is publicly 
accessible.  When your server connects to jabber.ietf.org, your server states 
that it is henryviii.  The jabber.ietf.org server then separately connects 
back to henryviii to verify that this is true (it resolves 'henryviii' via 
DNS, then TCP connects to the result on port 5269).  You need to make sure 
the domain of your server exists, and that resolving and connecting to port 
5269 will reach your machine.

This dialback procedure is a standard mechanism in Jabber to prevent domain 
spoofing.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] How to do SASL authentication in C/C++

[Justin Karneges]

On Monday 10 November 2008 21:39:06 ashiraz wrote:
 I have started to write socket level code for interaction with a jabber
 server like gtalk.

 I am sending this thing xml strings but in the authentication phase it
 requires SASL encryption. Is there an expeditious way of encrypting
 authentication code?

It's common to use libraries for SASL, but we've already had a discussion 
about libraries.  That said, it's also very common to not use libraries for 
SASL.  Lots of people write their own code for one reason or another.

You need to decide what mechanisms to implement.  Probably you'd do PLAIN 
and/or DIGEST-MD5.  Consult the RFCs.  You should only do PLAIN if you plan 
to protect the stream with TLS.

Long ago, somebody wrote the smallest tutorial ever for DIGEST-MD5, and it's 
even written in the context of XMPP:
http://web.archive.org/web/20050224191820/http://cataclysm.cx/wip/digest-md5-crash.html

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] Talk To Jabber Server Using Sockets

[Justin Karneges]

On Sunday 09 November 2008 20:44:46 ashiraz wrote:
 Has anyone talked to a jabber server using socket programming?

Of course.  How do you think libstrophe works? :)

 I just need to connect a server and send one phrase to one of the
 account holders.

 How difficult is doing something straightfoward like that?

Not incredibly difficult, given the huge number of Jabber implementations out 
there.  However, doing so is certainly harder than using an existing library.

If the 'cl' command isn't working from within the Visual Studio Command 
Prompt, then there may be something wrong with your compiler installation.  I 
suggest taking that issue to a different forum.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] BOM

[Justin Karneges]

On Thursday 06 November 2008 12:49:30 Jonathan Dickinson wrote:
 Much obliged. As a case of interopability, maybe something like: entities
 MUST NOT send byte order marks, however, they MUST tolerate them.

As I understand it, BOM are used only for UTF-16.  At the XML layer in 
Psi/Iris, I believe we support any text encoding, and if UTF-16 is detected 
(via presence of BOM) then the BOM are honored.  The ?xml ...? line is then 
read to confirm the encoding.  Of course, soon after that the stream is 
destroyed due to the attempt at using an encoding that isn't UTF-8. :)

I'm not sure what happens if BOM is present in the UTF-8 stream or what is 
supposed to happen.  My guess is that they should get ignored, but that it's 
also wrong to be putting them in there in the first place.  So I think your 
proposed text is what we want, but perhaps an encoding guru should 
double-check..

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] Presence hiccups

[Justin Karneges]

On Thursday 02 October 2008 16:16:27 Adam Pisoni wrote:
 As far as probing goes, I guess you could probe if you haven't seen
 activity in a while, though I wonder whether that wouldn't be frowned
 upon by other services.  I'm not sure if its seen as outside the spec
 if you will. We're talking about a potentially VERY large number
 of JIDs so it seems eventually you'd be constantly probing, which
 other servers might not like.

Generally speaking, s2s presence loss is uncommon.  Unfortunately, when it 
happens the problems are severe (e.g. ghost user in MUC for all eternity).  
Periodically reacquainting yourself with remote servers is really the only 
solution.

Now, it could be the problem is that the other server is reporting the wrong 
presence to you.  Maybe s2s is fine and it's just that the remote server 
doesn't know what it is talking about when it comes to the state of its own 
connected clients.  This is a widespread problem with c2s connections, 
usually among wi-fi or mobile users.

Anyway, the c2s case is not your problem.  The s2s case you just do the best 
you can.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

[jdev] s2s and xep-198 session resumption

[Justin Karneges]

On Thursday 02 October 2008 21:09:37 Justin Karneges wrote:
 Periodically reacquainting yourself with remote servers is really the only
 solution.

(... to clearing away stale presence)

Suppose you want to check on interesting JIDs every 10 minutes.  Instead of 
connecting to a remote server in the usual way, and then presence probing 100 
JIDs, how about simply using XEP-198 session resumption?  Have the remote 
server set the session expiry to 15 minutes, and if you reconnect within 10 
minutes and the server still remembers that session token, then you would 
know the server hasn't died and you haven't lost any presence stanzas.  No 
actual presence probes needed.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] parsing xml (xmpp) with ruby

[Justin Karneges]

On Monday 29 September 2008 00:29:18 Michal 'vorner' Vaner wrote:
 Hello

 On Mon, Sep 29, 2008 at 09:19:17AM +0200, Remko Tronçon wrote:
   I tried to create my own XMPP parser/library (for, ehm, educational
   purposes). I never come across this issue. As far as I understand it, I
   get proceed, but no more binary data.
 
  You mean you don't get binary data when you did a read() of
  proceed/? You can't rely on that on a TCP connection.

 I could rely on that if the server sent them only as a response to _my_
 binary data. If it is this:

 S: proceed/
 C: Binary greeting
 S: Binary response

 Then everything is OK, because I can get ready for binary before I send
 my binary part. I'm not sure it is this way, but whenever I looked on a
 TCP dump or expected this behaviour, it always worked this way.

 Of course, If this could happen too:
 S: proceed/
 S: Some binary data
 C: Binary response

 Then I would be out of luck and couldn't expect it to come out as two
 separate reads.

 I expect the proceed is ment as server telling me he is ready for _my_
 binary data. It won't send me any binary data unless I do it first.

True, for TLS this is mostly an academic problem.  In the TLS protocol, the 
client speaks first, so you shouldn't receive TLS data from the server until 
the client has sent his data.  You'd probably have to do something like this:

starttls/[tls handshake] (client assumes starttls will succeed)
proceed/[tls handshake reply]

Tony Finch has suggested behavior like this for round-trip optimization.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] ruby xmppd, and Psi

[Justin Karneges]

On Wednesday 17 September 2008 14:22:33 Eric Will wrote:
 When I switch to offering PLAIN alone, Gajim and Digsby work, and Psi
 works unless I do what the new draft says, which is success
 blah=/success. Psi rejects that, and none of the others care, so for now
 I just have it with success blah/.

I don't think you're supposed to send response data with PLAIN, are you?  
success/ (no response data) is correct, not success=/success (response 
data of zero-length).

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] Communicate between two client instances of the same ID

[Justin Karneges]

  Requests will be a few KBytes, replies a few KBytes to a few hundred
  KBytes typically. For larger replies, I suppose I can chunk them up
 
  Hmm. XMPP is not optimized for sending around 100k+ messages.

 Would 64KB chunks a reasonable thing to do?

That's probably still too high.  There is currently no specified maximum size 
for XMPP stanzas, but individual implementations may enforce different 
values.  The original jabberd 1.0 server had around a 10KB maximum.  The 
general consensus is that stanzas should be small, and this is largely in 
part because large stanzas block transmission of other stanzas (you cannot 
send many stanzas in parallel over one stream).

Any XMPP-based protocol which might need to transmit large datasets should 
have a mechanism for chunking or paging.  See XEP-47 or XEP-59 as building 
blocks.

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] Presence leak test suite

[Justin Karneges]

On Wednesday 09 July 2008 07:55:58 Kevin Smith wrote:
 On Wed, Jul 9, 2008 at 3:46 PM, Peter Saint-Andre [EMAIL PROTECTED] 
wrote:
  you also test presence leaks using guessed well-known resources like
  client names (Psi, Gajim, Miranda, QIP, Adium etc.) or places (Home,
  Work, School etc.)? I think it could push client authors to use
  random-generated resource names.
 
  I don't understand why this would be something we'd want to push for.
 
  Because some people are paranoid?

 Paranoid people can use as random a resource as they want to - it
 doesn't mean the rest of us need to :)

And a random resource isn't necessary anyway, just good privacy control on the 
server.  (/me still wants a server that will bounce all iqs from people who 
don't have his presence.)

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] Presence leak test suite

[Justin Karneges]

On Wednesday 09 July 2008 09:33:32 Peter Saint-Andre wrote:
 Justin Karneges wrote:
  On Wednesday 09 July 2008 07:55:58 Kevin Smith wrote:
  On Wed, Jul 9, 2008 at 3:46 PM, Peter Saint-Andre [EMAIL PROTECTED]
 
  wrote:
  you also test presence leaks using guessed well-known resources like
  client names (Psi, Gajim, Miranda, QIP, Adium etc.) or places (Home,
  Work, School etc.)? I think it could push client authors to use
  random-generated resource names.
 
  I don't understand why this would be something we'd want to push for.
 
  Because some people are paranoid?
 
  Paranoid people can use as random a resource as they want to - it
  doesn't mean the rest of us need to :)
 
  And a random resource isn't necessary anyway, just good privacy control
  on the server.  (/me still wants a server that will bounce all iqs from
  people who don't have his presence.)

 Including directed presence?

Yep, that's the idea.  If I send someone directed presence then they'd be 
temporarily authorized.  In current practice, this would really only be used 
with MUC rooms.  However, I can imagine a future practice of sending directed 
presence to unsubscribed contacts or sending directed presence when invisible 
(fortunately these are edge cases, so there's a lot to be gained even without 
clients handling them yet).

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] Yahoo / Google Talk interop

[Justin Karneges]

On Wednesday 18 June 2008 18:30:18 Peter Saint-Andre wrote:
 On Wed, Jun 18, 2008 at 04:39:25PM -0700, Steven Peterson wrote:
  As seen on the InterWebs:
 
  http://online.wsj.com/article/SB121366428372879463.html?mod=googlenews_ws
 j
 
  Does anybody know if Yahoo / Google Talk interop will use XMPP?

 I have no idea. But given that Yahoo has been experimenting with XMPP in
 Yahoo Live, Fire Eagle, etc., it would not shock me. Of course, I don't
 know how the Google-AIM interoperability happens, either (is that just a
 dual protocol stack in the Google Talk client?).

At the very least, you need an AIM account to use AIM through GTalk, so it's 
clearly not federated.

What's interesting is that Yahoo federates with MSN.  Somehow I don't see 
Microsoft's blessing on a Yahoo-GTalk federation due to the doors that 
would open.

My hopes are on Facebook..

-Justin
___
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [EMAIL PROTECTED]
___

Re: [jdev] Authentication Process For Jabber.com

[Justin Karneges]

On Monday 10 March 2008 2:01 am, Sergei Golovan wrote:
 On 3/10/08, Justin Karneges [EMAIL PROTECTED] 
wrote:
   Further, since some XML parsers throw error when an unrecognized prefix
  is encountered, those clients/servers would most likely respond not with
  a stanza error, but with an xml-not-well-formed *stream* error and close
  the connection.
 
   I think we have to be very careful about how this stuff is routed. 
  Obviously clients shouldn't be generating invalid XML, but servers
  shouldn't be routing it either.  A good server would disconnect whoever
  sent gajim:die rather than routing it and DoS'ing other clients.

 I would like to see (probably in a separate section) rules for closing
 streams like the following:

 1) If an entity sends non-well-formed XML as defined in
 http://www.w3.org/TR/2006/REC-xml-20060816 then the receiving entity
 MUST close the stream and return xml-not-well-formed error.

 2) If an entity sends namespace-non-well-formed XML as defined in
 http://www.w3.org/TR/REC-xml-names then the receiving entity MUST
 close the stream and return xml-not-well-formed error (or may be it's
 better to introduce a separate error for this case).

 3) IF an entity defines XMLNS prefix in a stream header and use it in
 a stanza (which means that the stanza isn't routable as is) then the
 receiving entity MAY close the stream and return xml-non-well-formed
 error, but SHOULD move namespace definition to a stanza level (or
 convert namespace prefix into xmlns attribute) and process the stanza.

 (The third rule is arguable though.) These rules ensure
 namespace-well-formedness of XMPP streams, and no custom XML parsers
 will be necessary to parse XMPP streams. Currently, general XML
 parsers either ignore namespace prefixes at all (which means that
 clients using them will loose some data) or break on unbound prefixes
 (which means disconnections on gajim:die/).

+1

-Justin

Re: [jdev] Authentication Process For Jabber.com

[Justin Karneges]

On Sunday 09 March 2008 5:49 pm, Peter Saint-Andre wrote:
 Sergei Golovan wrote:
  On 3/9/08, Peter Saint-Andre [EMAIL PROTECTED] wrote:
   Therefore, this is wrong:
 
 
   stream:stream
  xmlns:stream='http://etherx.jabber.org/streams'
messagegajim:die//message
   /stream
 
  It means that it's wrong to send this stanza. But it doesn't mean that
  it's wrong to accept this stanza.

 Correct. The spec currently does not say that the server must enforce
 that rule. But naturally the recipient (or the sender's or recipient's
 server) could return a stanza error on receiving it. A not-acceptable/
 error seems appropriate:

 message type='error'
   error type='modify
 not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/
   /error
   gajim:die/
 /message

Hmm, you should probably not send the original XML back in this case, since it 
is invalid.

Further, since some XML parsers throw error when an unrecognized prefix is 
encountered, those clients/servers would most likely respond not with a 
stanza error, but with an xml-not-well-formed *stream* error and close the 
connection.

I think we have to be very careful about how this stuff is routed.  Obviously 
clients shouldn't be generating invalid XML, but servers shouldn't be routing 
it either.  A good server would disconnect whoever sent gajim:die rather than 
routing it and DoS'ing other clients.

-Justin

Re: [jdev] Sharing a single connection for multiple users

[Justin Karneges]

On Tuesday 26 February 2008 7:48 pm, Andrew Miehs wrote:
 Would I need to create one connection to the jabber server for each
 web user, or can
 I use one connection per web server? I am a little worried about how
 well thousands
 of connections per server would scale.

This is not a protocol issue, but an internal server implementation issue.  If 
you feel you need to handle so many connections that a single computer cannot 
handle the load, then the answer is to distribute the load across many 
computers.  Look for server software that supports clustering, such as 
ejabberd, or one that supports edge servers such as jabberd+jadc2s.

-Justin

Re: [jdev] Sharing a single connection for multiple users

[Justin Karneges]

On Tuesday 26 February 2008 10:51 pm, Andrew Miehs wrote:
 I do not see the issue as a too high load problem.

 Let us assume 50,000 users online.
 Most of the users never send any traffic, so they do not actually
 create a load problem.

 However, there is a difference between 50K tcp connections to the
 jabber server, versus 50 (1 per server) connections in total.

Sure.  And this is what I was talking about.  For example, if you use 
jabberd/jadc2s, then you set up 50 edge servers running jadc2s.  Each edge 
server is capable of handling 1000 client connections, and each connects just 
once to a master jabberd.  So the master jabberd only has 50 connections, 
each connection handling 1000 clients worth of traffic.

The protocol between jadc2s and jabberd is internal and specific to that 
combination of software.  From the outside, jadc2s appears like any normal 
XMPP service.  Connecting clients do not know or care about how the overall 
system works internally.

One possibility for you would be to make each web server an edge server.  
That is, you run jadc2s on each web server, and the backend of the web client 
simply connects to the web server's own local jadc2s instance (localhost 
connection).  Then each web server maintains just one connection to a single 
backend jabberd.

To be honest I don't know how relevant the jabberd/jadc2s combination is 
anymore.  Ejabberd or Openfire may offer better load-balancing options.  My 
point is simply that this is not really a protocol issue, but a server 
deployment/implementation issue.

-Justin

Re: [jdev] Why is my jabber server kicking out a remote user on an error?

[Justin Karneges]

On Monday 18 February 2008 1:33 pm, Tom Kalafut wrote:
 We have developed some middleware that handles some errors.  When it
 does, it reverses the from and to elements and adds an error element to
 form an error message.  But the jabber server is kicking the remote
 user out of the chat room where the original message came from.

I believe this is a bug in ejabberd muc.  I don't know the status of a 
solution.

-Justin

Re: [jdev] last presence confusion

[Justin Karneges]

On Monday 28 January 2008 1:06 pm, Tomasz Sterna wrote:
 On Pn, 2008-01-28 at 13:55 -0700, Peter Saint-Andre wrote:
   Besides the coolness factor I see the usefulness factor:
   Went to Aruba. Be back on 12.02.
 
  Oh yes, you can do that now with some clients (I know Psi does it). I
  keep worrying that someone will post a 5k story about their wonderful
  trip to Aruba (OMG I just got back from Aruba and I had such an
  awesome
  time, here's the full trip report.) and use that as their status
  message while they sleep off the trip. ;-)
 
  But maybe I need to stop worrying so much...

 Is it really that different from setting this story + XA and leaving the
 client online?

I think this is an important point.

Many people enjoy having a status while being gone.  What is the difference 
between setting your status in Facebook to gone fishing (which persists 
even after the browser is closed) and setting your status in Jabber to gone 
fishing and wanting to close the client?  Is a status string associated with 
unavailable presence less interesting than a status string associated with XA 
presence?  Should the type of presence (unavailable vs XA) affect the 
efficiency in which it can be received?

Today I noticed a Gadu-Gadu transport that replies with presence for all of 
your GG contacts, whether offline or not.  So you get maximum efficiency in 
receiving offline presence.  I believe this feature was inspired by the fact 
that offline messages are quite popular in Poland.

Whether this feature becomes a SHOULD or stays a MAY, we still have the 
problem that a client cannot rely on the feature being present nor can a 
client even determine if the feature is supported.  When should a client 
resort to jabber:iq:last?  I think we should come up with some best practices 
here, or possibly some protocol elements.

-Justin

Re: [jdev] last presence confusion

[Justin Karneges]

On Friday 25 January 2008 7:06 am, Maciek Niedzielski wrote:
 On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
  On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
  2.  Else, if the contact has no available resources, the server MUST
  either (1) reply to the presence probe by sending to the user
   the full XML of the last presence stanza of type unavailable received
   by the server from the contact, or (2) not reply at all. So a nice
   server will return the last unavailable presence information (with a
   Delayed Delivery flag), thus obviating the need for a flood of
   jabber:iq:last requests.
 
  How about emphasizing the first option as a SHOULD?  This would hopefully
  encourage new servers to always reply, while not causing existing servers
  to become non-compliant.

 On the other hand, usually just 1/3 of my roster is online. So if server
 starts sending presence for all contacts, initial presence flood from
 the server increases 3 times.

The price of avoiding a jabber:iq:last flood.  Sounds like the caps 
discussion. :)

-Justin

Re: [jdev] last presence confusion

[Justin Karneges]

On Friday 25 January 2008 11:09 am, Peter Saint-Andre wrote:
 Maciek Niedzielski wrote:
  Peter Saint-Andre wrote:
  Maciek Niedzielski wrote:
  On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
  On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
  So a nice server will return the last unavailable presence
  information (with a Delayed Delivery flag), thus obviating the need
  for a flood of jabber:iq:last requests.
 
  How about emphasizing the first option as a SHOULD?  This would
  hopefully encourage new servers to always reply, while not causing
  existing servers to become non-compliant.
 
  On the other hand, usually just 1/3 of my roster is online. So if
  server starts sending presence for all contacts, initial presence
  flood from the server increases 3 times.
 
  So do I take that as an objection to the modified text in rfc3921bis?
 
  Not an objection. But I am a bit worried by this change when I look at
  my roster. However, at the same time I know that my roster is most
  probably not a very typical one. Do we have any stats? What's the
  percent of offline contacts? And what's typical roster size? Maybe it
  doesn't matter that presence list increases 3 times if this means
  increasing from 3 to 9 presence stanzas?

 I have 1770 people in my roster, so yes I'm concerned. :)

 I'll look up some stats on the jabber.org service to see what the
 average roster size is.

It seems funny that it should be a concern if all of your contacts are 
available at the same time.  It is possible for it to happen, and your client 
and internet connection shouldn't explode if it does.  However, maybe it is 
best to optimize out the offline contacts, if a presence response from an 
offline contact isn't useful enough to justify the increase in traffic.

My interest in having the server return a presence response for every contact 
was to aid in determining when a client login is complete.  Right now 
there's really no way to know when a client is finished receiving an initial 
list of presence.  Clients often want to give the user a notification when 
presence activity changes, but only for changes after the initial list.  Psi 
considers the initial presence list to be received once 10 seconds have 
passed after the roster was received.  This is, of course, not very accurate, 
and when Peter takes more than 10 seconds to login, probably 1000 contacts 
trigger sound events.  However, maybe there's a better solution to the 
initial presence list problem.

That clients may want jabber:iq:last information available for all contacts, 
and without polling for it, is valid, IMO.  It relates very much to the 
desire to have jabber:iq:version information without polling.  I smell a 
push-based solution ahead...

-Justin

Re: [jdev] last presence confusion

[Justin Karneges]

On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
2.  Else, if the contact has no available resources, the server MUST
either (1) reply to the presence probe by sending to the user the
full XML of the last presence stanza of type unavailable
received by the server from the contact, or (2) not reply at all.

 So a nice server will return the last unavailable presence information
 (with a Delayed Delivery flag), thus obviating the need for a flood of
 jabber:iq:last requests.

The problem is that the server might choose the second option, which is to not 
reply at all, and a client cannot know the difference between a slow server 
or a no-reply server.  Thus, the client still has to make a decision to send 
iq:last to everyone or to no one.

How about emphasizing the first option as a SHOULD?  This would hopefully 
encourage new servers to always reply, while not causing existing servers to 
become non-compliant.

-Justin

Re: [jdev] Google to Connect to Other IM Networks Using Jabber Transports?

[Justin Karneges]

On Wednesday 05 December 2007 1:45 pm, Ernest Nova wrote:
 Note that an AIM account is required to use this feature. AIM in Gmail
 is not a Google Talk and AIM federation; it's the ability to sign in to
 your AIM messaging account from Gmail. Gmail uses Open AIM to provide
 this feature.

Right, so... not very interesting.

But, let's consider some positives...

According to the article, AIM connectivity presumably only works through the 
gmail web interface.  I predict this will eventually work via the Google Talk 
desktop client.  We can *hope* that this would be implemented (or eventually 
be implemented) using a Jabber-transport mechanism, so that non-Google Talk 
clients connecting to the Google Talk network can use AIM.  I suspect that 
we'll never see a publically accessible transport though.  You'd probably 
always need a Google Talk account to access AIM.

In any case, Jabber-transport or not, if Google can provide a good user 
experience for AIM within the Google Talk client, then we may be willing to 
convince more users to use Google Talk (and thus XMPP).  I know a lot of 
people who have gmail accounts and use only AIM for IM.  If they could use 
Google Talk for AIM, they might be compelled to switch to it since it is a 
nice client and they already enjoy google services.  This puts users in the 
same position as iChat does, with XMPP right under their nose.

Totally random thought: I wonder if Google is legally required (say, by 
contract with AOL) to thwart attempts by third-parties to access the AIM 
integration.  What if someone wrote a new Jabber transport that required 4 
fields: gmail account name, gmail password, aim account name, aim password?  
Would this give the rest of the XMPP world legit access to AIM via 
double-transporting?

-Justin

Re: [jdev] XEP-0198 implementation

[Justin Karneges]

On Monday 03 December 2007 6:48 pm, Peter Saint-Andre wrote:
 Magnus Henoch wrote:
  I've started hacking a server-side implementation of XEP-0198 (stanza
  acking).  Connect to bazarhoff.cd.chalmers.se and try it out.

 Super.

 I think Justin Karneges may still have some changes to make in the spec.
 Justin?

 Peter

Maybe there are some clarifications left to make.  I'll check.  I was 
wondering what the next steps were for last call.  Does Joe have anything 
further to add?

-Justin

Re: [jdev] [ANN]VTD-XML 2.2

[Justin Karneges]

On Friday 26 October 2007 7:05 am, Peter Saint-Andre wrote:
 jimmy Zhang wrote:
  XimpleWare is proud to announce the the release of version 2.2 of
  VTD-XML, the next generation XML parsers/indexer/slicer/editor.

 How is this relevant to XMPP? Please announce your software releases
 somewhere else. I have set the moderation flag for your email address,
 so that future messages from you must be approved by the list admin.

For what it's worth, I announced my DNS library on jdev a couple of years ago 
with no objections:
  http://mailman.jabber.org/pipermail/jdev/2005-September/022069.html

I didn't even tie the announcement to XMPP, leaving the readers to figure it 
out.

-Justin

Re: [jdev] How to specify username with SASL ANONYMOUS

[Justin Karneges]

On Wednesday 17 October 2007 2:11 pm, Mark Doliner wrote:
 So I've read through XEP-0175[1], and I think I have a pretty good idea of
 how SASL ANONYMOUS login is supposed to work (I love the protocol
 flow--thank you).

 But it's not clear to me how the client is supposed to specify a username. 
 This is supposed to be possible, right?  Or is the node always assigned by
 the server no matter what?  Should I just send the base64 encoded username
 as text within the 'auth' element?

XEP-175 doesn't seem to mention the fact that SASL ANONYMOUS can send data.  
The rfc3920bis-04 document even indicates that transmitting an initial 
response with ANONYMOUS is is invalid (section 7.5.5).  This is wrong, 
ANONYMOUS can send data, and it can be an initial response or not.  See RFC 
4505.

The client response for ANONYMOUS is trace data.  This is just supposed to 
be some generic id string, possibly an email address (like how anonymous FTP 
would often ask you to put your email address as the password, that's what 
this essentially replaces).  It might be interesting to specify in XEP-175 
that the trace data may be used as a node suggestion.

-Justin

Re: [jdev] Child nodes of DOM Attr

[Justin Karneges]

On Monday 17 September 2007 6:20 pm, Joonas Govenius wrote:
 On 9/17/07, Joonas Govenius [EMAIL PROTECTED] wrote:
  Hi all,
 
  I ran into this problem with the Qt DOM implementation when writing
  some code for shared XML editing:
 
  If I try to insert a DOM Text node to a DOM Attr node using
  appendChild(), nothing happens. Does anyone know for sure whether
  that's the correct behavior?

 I guess this is standard. Firefox tells me Modifications are not
 allowed for this document if I try to do this with JavaScript:

What on earth are you doing?! :)  Attributes have a single value.  They do not 
have child text nodes.

You mentioned Qt DOM.  In that case consider QDomAttr.setValue(value).  More 
conveniently, just call QDomElement.setAttribute(name, value).

-Justin

Re: [jdev] File Transfer Interoperability

[Justin Karneges]

On Tuesday 07 August 2007 10:29 pm, Sergei Golovan wrote:
 On 8/8/07, Peter Saint-Andre [EMAIL PROTECTED] wrote:
  3. IBB (XEP-0047) is a great fallback if all else fails.

 IBB couldn't be a great fallback. It's very inconvenient to use in the
 fillowing circumstances (which don't so rarely happen):

 1) JID A offers file to JID B and waits for the answer (note that to
 answer, B must return an IQ result, and the time interval might be
 quite long).

 2) JID A decides to abort file transfer and closes the
 file-transfer-window-or-whatever-GUI-she-has.

 3) JID B replies with IQ result, but
 a) File transfer doesn't start (A aborted it)
 b) JID B will NEVER know about A aborted file transfer and
 will stuck with file-receiving-GUI forever since there's no mechanism
 to recognize this unwilling to transfer.

 Wouldn't it better to add an extra query from B to A after stream
 negotiation part? If A doesn't want to send file anymore, she will
 return error to B.

I wouldn't put this at the IBB level.  A negotiation timeout will work well 
enough there.

The problem you speak of, which does indeed happen a lot, has more to do with 
the SI exchange.  If someone offers a file, and you take too long to accept, 
they may cancel the file offer and you'll never know.  This will happen 
regardless of whether you use S5B or IBB or anything.

In Psi we solved this by adding a timeout to the accept phase.  The sender 
must begin the S5B negotiation within 30 seconds of the receiver 
pressing Accept.  If the timeout expires, a dialog is presented to the 
receiver that says something along the lines of the sender probably 
cancelled.

I believe Jive added a protocol extension so that the receiver can know if a 
file transfer was cancelled.  Maybe it is worth documenting.

-Justin

Re: [jdev] File Transfer Interoperability

[Justin Karneges]

On Wednesday 08 August 2007 12:22 am, Sergei Golovan wrote:
 On 8/8/07, Justin Karneges [EMAIL PROTECTED] wrote:
  I wouldn't put this at the IBB level.  A negotiation timeout will work
  well enough there.
 
  The problem you speak of, which does indeed happen a lot, has more to do
  with the SI exchange.  If someone offers a file, and you take too long to
  accept, they may cancel the file offer and you'll never know.  This will
  happen regardless of whether you use S5B or IBB or anything.

 Any other file transfer method requires opening a socket by the
 receiving party. If the socket can't be opened then the stream is
 obviously invalid. IBB lacks this part, and I think it would be good
 to add it. It would make a file transfer working essentially the same
 regardless of the SI method used.

If the sender offers a file and then cancels it before the receiver accepts, 
then S5B hasn't even started yet.  In other words, the sender hasn't sent the 
iq-set for the S5B open.  Therefore, there are no sockets to time out, and 
the receiver will wait forever.  Just like with IBB, just like with anything.  
It's an SI issue.

If the sender cancels the file transfer immediately after the receiver 
accepts, then there is a chance that the sender may have started an IBB or 
S5B negotiation.  This is much less common than the SI problem, and I think a 
timeout in IBB here would be enough to solve this situation of bad luck.

FWIW, S5B also doesn't specify any timeouts.  If the receiver goes offline 
instead of replying with an iq, then the sender will wait forever (and this 
is the case today with Psi).  As you can see, endlessly waiting is not a 
feature of just IBB.  We generally don't specify timeouts in XEPs.  For 
example, how long should you wait for a vcard request to be answered?  Today, 
all of these possible timeouts are left to implementations to decide.

-Justin

Re: [jdev] File Transfer Interoperability

[Justin Karneges]

  Spark uses a special variant of XEP-96 that apparently breaks
  compatibility with every other client, most likely due to x:data
  ambiguity.  I'd suggest the Spark guys make an extension that is less
  prone to misinterpretation. 

 I don't know what the best solution is in this situation. We want Spark to
 be compatible as can be in this case but if we were to move to strictly
 interpret the XEP this would cause a degradation in the file transfer
 experience in Spark, as you can see it was a lose, lost situation.

As I wrote, maybe it is possible to make an extension that won't be 
misinterpretted.  Rather than fiddling with the x:data form, how about going 
the traditional route and adding some new namespaced elements/attributes?

We can take a time machine back to 2003:
  http://mail.jabber.org/pipermail/members/2003-August/002570.html

-Justin

Re: [jdev] File Transfer Interoperability

[Justin Karneges]

On Sunday 05 August 2007 8:49 am, Michael Laukner wrote:
 Hi,
 I have been reading the discussions about Basic/Intermediate Client 2008
 because I was interested in file transfer interoperability. Although
 there is a standard (XEP-96) file transfer does not work properly
 within the XMPP famliy of clients.

 http://www.igniterealtime.org/forum/thread.jspa?messageID=152457#152457
 http://forum.psi-im.org/thread/4174
 http://thread.gmane.org/gmane.network.jabber.standards-jig/10468

 Wouldn't it be nice if file transfer worked as seamless as an e-mail
 attachment? I would love if at least the main players (recommended
 clients in jabber.org) could agree on an implementation guideline.

The igniterealtime thread has a post containing compatibility test data 
between Spark, Pidgin, Psi, and Pandion.  Here is my explanation of the 
results:

Pandion doesn't support XEP-96, and Pidgin/Gaim is notoriously buggy for file 
transfer.  The problem with these two has nothing to do with a lack of an 
implementation guideline.  Someone just needs to step up and fix things.

Spark uses a special variant of XEP-96 that apparently breaks compatibility 
with every other client, most likely due to x:data ambiguity.  I'd suggest 
the Spark guys make an extension that is less prone to misinterpretation.

As far as I can tell, Psi works properly.

Keep in mind that these are not the only clients.  Gajim, iChat, and Trillian 
are also popular clients that support file transfer, and they may not have 
any of the problems described in the igniterealtime thread.  The situation 
may not be as bad as you think.

-Justin

Re: [jdev] sending presence to specific transport

[Justin Karneges]

On Monday 21 May 2007 11:45 pm, Eugeny N Dzhurinsky wrote:
 On Mon, May 21, 2007 at 07:32:48PM -0700, Chris Chen wrote:
 This is possible.  My way to test this would be to use another client
 (ie. Psi) and see if the server is giving the same response.

 With Psi it is not possible to emulate such behavior, since it sends
 broadcast presence packet once conect and login to the server. I did in a
 bit different way - I send that global presence packet once connect to
 jabber server, and then send online status to each of gateways - and they
 respond!

 So looks like it is not possible to login into jabber server only, all
 registered transports becomes online immediately :(

Well, one thing you can do is not subscribe to the transport jids, and instead 
send directed presence to them (this is possible with Psi, right-click on a 
transport and choose Login).  This way, you can login to the Jabber server 
only, and then individually login (or logoff!) transports.

-Justin

Re: [jdev] RE: [Standards] Re: compliance levels for 2008

[Justin Karneges]

On Saturday 05 May 2007 7:16 am, Norman Rasmussen wrote:
 On 5/5/07, Chris Mullins [EMAIL PROTECTED] wrote:
  - File transfer. Come on guys! :)

 Which of XEP-0047, XEP-0065, XEP-0066, XEP-0095, XEP-0137, XEP-0166,
 XEP-0176 are you thinking about in particular?

XEP-96 and its dependencies is the only standard file transfer.

-Justin

Re: [jdev] Which open-source Jabber client is best to develop?

[Justin Karneges]

Yes.  Also Jabbin, SAPO Messenger (Mac), and more..

Psi/Iris has a steeper learning curve than the other options, but it is a 
well-proven client platform.

Also, I like to think of the Qt dependency as a feature. :)

-Justin

On Monday 23 April 2007 11:55 am, Nathan Fritz wrote:
 Doesn't KoPete use Iris as well?

 On 4/23/07, Norman Rasmussen [EMAIL PROTECTED] wrote:
  On 4/23/07, Tran Thai Son [EMAIL PROTECTED] wrote:
   By the way, did anybody play around with a Jabber C/C++ library or
   client which can be a good base to develop?
 
  Iris [1] is good (it's what Psi uses), although it has a Qt dependency.
 
  [1] http://delta.affinix.com/iris/
 
  --
  - Norman Rasmussen
  - Email: [EMAIL PROTECTED]
  - Home page: http://norman.rasmussen.co.za/

Re: [jdev] What is the purpose of the rspauth?

[Justin Karneges]

On Tuesday 17 April 2007 7:22 pm, LUKE wrote:
 I know Step 1.2. is rfc-2831.And i can understand the calculation process.

 But  The step 3:  rspauth=ea40f60335c427b5527b84dbabcdfffd

 Where the value(ea40f60335c427b5527b84dbabcdfffd) come from?
 And what is the purpose of the rspauth. The XMPP document
 (http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-01.html)
 does not have any example about rspauth.

As far as I know, rspauth is DIGEST-MD5's way for the server to authenticate 
itself to the client.  This extra step is commonly known as mutual 
authentication.  I don't know how this value is calculated or verified 
though.

This should be described in RFC 2831, read deeper. :)

-Justin

Re: [jdev] end-to-end encryption -- making it happen

[Justin Karneges]

On Tuesday 09 January 2007 11:33 am, Peter Saint-Andre wrote:
 It's time for us to get serious about end-to-end encryption (e2e).

 Ian Paterson has been working hard on specs for e2e. I think we now have
 the pieces in place for strong e2e between any two users, in a way that
 even Aunt Tillie can use. Now we need to make it happen.

I read through the XEPs, and my initial reaction is ... holy smokes this is a 
lot of material!  And we're worried programmers will have trouble parsing 
CPIM? :)

I think the e2e XEPs may be great in the long term, but it will be years 
before this is implemented widespread.  First, we need thorough security 
reviews of all the specifications by multiple parties.  Then we can 
implement, and that will take time too.  Just to bring reality home here..  
show of hands for developers even doing certificate validation with TLS?

Also, Ian also has a tendency to incorporate bleeding edge security algorithms 
and procedures, that I'm not sure have received proper scrutiny..

The main thing I'd like to see are some security reviews by people who 
actually design and implement crypto.  Let's hear from Peter Guttman or Eric 
Rescorla.  We need prominent members in the security community that not only 
will do a basic error check, but will also ask important questions like, why 
the hell are you doing it this way? :)

I'll be implementing RFC 3923 until then.

-Justin

Re: [jdev] end-to-end encryption -- making it happen

[Justin Karneges]

On Tuesday 09 January 2007 12:24 pm, Peter Saint-Andre wrote:
 Justin Karneges wrote:
  First, we need thorough security
  reviews of all the specifications by multiple parties.

 All the existing specs (RFCs/MUC/etc.) or the esession specs?

 Security reviews of all the existing specs is a good idea, but that
 doesn't solve the e2e problem.

e2e.

RFC 3920 doesn't need the same scrutiny, because it uses the off-the-shelf TLS 
protocol.  Problems in the RFC should stick out like a sore thumb to any 
security-conscious developer.  No need to bring in the security mafia.

Esessions, on the other hand, is very low level, and this means a large 
opportunity for errors (both in design and implementation).  Most of us are 
unqualified to review the esessions design, and so we definitely need experts 
to step in here and assist.

  Also, Ian also has a tendency to incorporate bleeding edge security
  algorithms and procedures, that I'm not sure have received proper
  scrutiny..

 The SHA family is broken. It's only a matter of time before SHA-256 and
 even SHA-512 are cracked (but those at least are a damn sight better
 than SHA-1). In any case these are negotiation options and we need to
 remain flexible with regard to algorithms as old ones are comprimised.

Not just SHA, but also SIGMA.

 See Step 1 in my previous email. A full security review of the esession
 specs by a prominent member of the security mafia is going to be part of
 this.

I'd like to see at least 2 people review it, with at least one of them 
unsympathetic to XMPP.

  I'll be implementing RFC 3923 until then.

 Yes, and I see that you sign your email with a digital certificate using
 S/MIME. :-) IMHO RFC 3923 is simply not a go-forward technology because
 of the dependency on end-user PKI (hell, even very few members of the
 security mafia use S/MIME). The lack of a CPIM parser is the least of
 the problems with RFC 3923.

If only KMail S/MIME wasn't a mess. :)

-Justin

Re: [jdev] Re: XHTML-IM XEP implementation

[Justin Karneges]

On Thursday 04 January 2007 12:07 pm, Alexander Gnauck wrote:
 ya this looks nice.
 AS also Peter mentioned the problem will be the binary inline content if
 it's getting to big. Then receiving this message blocks your whole XMPP
 connection. For small inline content (small images) this will work fine.

This begs the question: what is too big?  Currently, we consider stanza size 
to be somewhat unbounded, as XMPP-Core imposes no size maximum.  But I 
believe we do need some mechanism for a stanza maximum size, otherwise XMPP 
software is prone to denial-of-service attacks.

However, email has no maximum size, and we probably have a great many XEPs 
assuming an unbounded size as well.  Thus, as soon as we apply a stanza size 
maximum (which, I'm prepared to argue, is 100% necessary), we may run into 
trouble with our existing protocols.

I think this is something we need to discuss.

-Justin

Re: [jdev] XHTML-IM XEP implementation

[Justin Karneges]

On Thursday 04 January 2007 1:04 pm, Maciek Niedzielski wrote:
 Norman Rasmussen wrote:
  Whitespace is significant in the body/ element, no?
 
  True, so we need to remind client developers that it's significant in
  the html node too, and that it's the job of the _receiving_ client to
  ensure that the whitespace is preserved (not the sending client)

 Just a question I always wanted to ask: Is it possible for a server to
 rewrite a stanza (and break the whitespaces)?

Whitespace is always significant.  That's XML.  If a server rewrites XML, the 
whitespace must still be there.

As for XHTML, whitespace significance really depends on how XHTML is supposed 
to work.  Yes, the whitespace is there, since XHTML is XML, but what is the 
meaning of the whitespace to an XHTML renderer?  I don't believe this is ours 
to decide.

If XHTML is just like HTML, where any length of whitespace simplifies down to 
one character for presentation, then we should probably respect this in 
XHTML-IM.

-Justin

Re: [jdev] XMPP Ping method?

[Justin Karneges]

On Wednesday 01 November 2006 9:17 am, Peter Saint-Andre wrote:
 Justin Karneges wrote:
  This seems unlikely
  though, as I think the RFC revision has already been made, and there was
  no consideration for these features.

 It is not accurate to say that the RFC revision has already been made.
 I published -00 versions of rfc3920bis and rfc3921bis, but that is the
 start of discussion, not the end.

Well let's test the waters. :)  I've put together some RFC text that unifies 
the acking mechanisms proposed by myself and Dave Cridland.  I'll post it to 
standards-jig.

-Justin

Re: [jdev] Re: XMPP Ping method?

[Justin Karneges]

On Friday 03 November 2006 8:29 am, Peter Saint-Andre wrote:
 Norman Rasmussen wrote:
  It might make sense in rfc3920bis to make a small note that SCTP can
  be used as a 'drop in' replacement for TCP as long as both hosts
  supports it.

 Will do. I still think it's not a great idea for us to be solving things
 at the XMPP layer that belong at the TCP/SCTP layer...

It's bad enough that not all environments allow monitoring of TCP acks.  I 
don't think SCTP is any better of a recommendation.  If we want something 
universal, we have only plain TCP and UDP, really.  Of course, SCTP can be 
layered over UDP, but that's a hefty requirement.

Keep in mind that we have HTTP Binding, to assist platforms with very 
restricted environments.  It's okay to be a purist, when it is reasonable, 
but sometimes it is better to make exceptions like this.

In my opinion, XMPP over SCTP over UDP is too much to ask for, when just an 
element or two in XMPP over TCP will solve our problems.

-Justin

Re: [jdev] Re: XMPP Ping method?

[Justin Karneges]

On Friday 03 November 2006 11:00 am, Michal 'vorner' Vaner wrote:
 On Fri, Nov 03, 2006 at 10:50:37AM -0800, Justin Karneges wrote:
  On Friday 03 November 2006 8:29 am, Peter Saint-Andre wrote:
   Norman Rasmussen wrote:
It might make sense in rfc3920bis to make a small note that SCTP can
be used as a 'drop in' replacement for TCP as long as both hosts
supports it.
  
   Will do. I still think it's not a great idea for us to be solving
   things at the XMPP layer that belong at the TCP/SCTP layer...
 
  It's bad enough that not all environments allow monitoring of TCP acks. 
  I don't think SCTP is any better of a recommendation.  If we want
  something universal, we have only plain TCP and UDP, really.  Of course,
  SCTP can be layered over UDP, but that's a hefty requirement.
 
  Keep in mind that we have HTTP Binding, to assist platforms with very
  restricted environments.  It's okay to be a purist, when it is
  reasonable, but sometimes it is better to make exceptions like this.
 
  In my opinion, XMPP over SCTP over UDP is too much to ask for, when just
  an element or two in XMPP over TCP will solve our problems.

 However, I would like to see XMPP over SCTP. Simply because it's ability
 of multihoming (I may have written about it, I take laptop, start WiFi,
 unplug ethernet and want to be still connected).

Sure, I don't mean to discourage the general idea of XMPP over SCTP, I just 
think it is overkill for the particular problem we are discussing.

And to reply to the earlier posts: I also don't think SCTP can be reduced to a 
footnote in the XMPP-Core RFC.  More likely, it would have to be an entire 
spec of its own, similar in nature to HTTP Binding.  There's a lot to 
consider about how the various features may be used in an XMPP context, and a 
whole boatload of issues when you start talking about federation.  That said, 
I, too, would find an SCTP Binding spec interesting.

-Justin

Re: [jdev] XMPP Ping method?

[Justin Karneges]

On Wednesday 01 November 2006 9:17 am, Peter Saint-Andre wrote:
 But the latest discussions about this (a month or two ago?) were that
 this is most appropriate as an XMPP extension (XEP), so please send me
 the latest version and we'll get that on the docket for the next XMPP
 Council meeting.

http://www.xmpp.org/extensions/inbox/ack.html

-Justin

Re: [jdev] XMPP Ping method?

[Justin Karneges]

On Tuesday 31 October 2006 4:49 pm, Scott Robinson wrote:
 What is the proper method of performing a ping across a client XMPP
 connection.

There isn't.  There was a JEP/XEP proposal to add Acking and Ping features to 
the protocol, but it wasn't accepted as a XEP (that is, it died before it 
even got a XEP number).  The JSF Council recommendation was to take care of 
these features in the XMPP-Core RFC instead of a XEP.  This seems unlikely 
though, as I think the RFC revision has already been made, and there was no 
consideration for these features.

-Justin

Re: [jdev] forum for jabber

[Justin Karneges]

On Tuesday 12 September 2006 09:50, reno wrote:
 Is there a forum for jabber developer? I'm really not comfortable using
 mailing list format.

Hmm, better get used to them.  Lots of development communities use mailing 
lists. :)

But, you can try posting on the Psi web forum:
  http://forum.psi-im.org/

The Help and General Chat section is for anything at all.  There are many 
Jabber developers reading the Psi forum so you'll probably get help.

-Justin

Re: [jdev] Discovering the Federation.

[Justin Karneges]

On Tuesday 29 August 2006 21:07, Daniel Noll wrote:
  I just got an idea: Why not use DHCP for this? It can already be used to
  discover your default IRC server (8.19 in RFC-2132), so why not your
  default XMPP server?

 We already have another way to do it too, DNS Service Discovery.

That's true.  For those not in the know, DNS-SD lets you query a domain for a 
list of services.  DNS-SD is commonly used in conjunction with Multicast DNS 
to scan the local network for services, but DNS-SD can also be used with 
regular DNS.

DNS-SD is essentially one more layer above SRV.  Instead of asking for the 
Jabber server at example.com (with SRV), you ask for Jabber servers at 
example.com (with a specially encoded PTR query).  This results in a list of 
friendly, user-readable names (not hostnames!).  Then you can SRV resolve any 
of the names.  The idea is that a user can browse his domain, see a list of 
named services, and then pick one.  For example, browsing a domain for ftp 
servers might result in Joe's Shared FTP and Mike's Vault.

However, this is really only useful if you plan to have more than one Jabber 
server in a given domain, and you want a friendly way for the user to pick 
the right one.  For Hal's purposes, SRV alone is probably enough.

-Justin

Re: [jdev] Re: help needed to implement a P2P Chat Client

[Justin Karneges]

On Monday 28 August 2006 14:36, Peter Saint-Andre wrote:
 Ravi wrote:
  I have an idea of what I am up against. As well as little surprised that
  nobody tried P2P for chat. I will reconsider my options.

 Nobody in the Jabber community has, because our technology has worked
 just fine so far. But ICQ and Skype (mostly) take the p2p approach.

As I understand it, ICQ primarily sends messages over the server, now that it 
uses the OSCAR protocol (just like AIM).

To answer Ravi:

P2P could allow for more optimized routing, but there are far too many 
firewalls to even consider it.  AIM and MSN have proven that server-based 
message routing isn't a problem, even if you have millions of users.  And if 
you don't have millions of users, then it also isn't a problem.  This is the 
nice thing about XMPP decentralization; it is not jabber.org's job to host 
the whole planet.

Additionally, a design goal of XMPP is to allow for easy client development, 
and having the server do a lot of the work sure is easier than P2P.  You can 
see evidence of this by comparing the number of clients that support plain IM 
vs the number that support any kind of P2P extension (e.g. File transfer or 
VoIP).

-Justin

Re: [jdev] jabber server name by ip

[Justin Karneges]

On Saturday 22 July 2006 06:09, Matthias Wimmer wrote:
 Oleg Motienko schrieb:
  Does anybody know a method of discovering jabber server name by ip
  address if port 5269/tcp is opened and jabber server listening there?

 Jabber servers provide virtual hosting and have typically no default
 domain. Therefore, I think it will be at least hard to find out the
 domain name this way.

From RFC 3920, 4.7.1:

... if the initiating entity provides an unknown host in the 'to' attribute 
(or provides no 'to' attribute at all), the server SHOULD provide the 
server's authoritative hostname in the 'from' attribute of the stream header 
sent before termination.

This could happen if there is an error while the stream is being set up, like 
if you telnet to port 5269 and type jibberish.

-Justin

Re: [jdev] s2s lookup cascades

[Justin Karneges]

On Tuesday 04 July 2006 05:21, Norman Rasmussen wrote:
 Most jabber servers seem to give up and _not_ do the dns cascade, but
 Wildfire seems to do the cascade DNS, generating lots of 'Failed to
 lookup .de', or 'Failed to lookup .org' records in the log files.

Definitely don't cascade.  Wildfire does it so people can have jabber 
subdomains without modifying the DNS, but all this does is break the network 
for non-Wildfire users.

-Justin

Re: [jdev] help needed in communicating with jabber server

[Justin Karneges]

On Saturday 01 July 2006 13:50, ali wrote:
 VB.net Client:-

 starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/

 Jabber Server Responds:-

 proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/

The proceed response means you're supposed to proceed with the TLS 
negotiation.  TLS is a binary protocol, where the client and server exchange 
some data in order to establish a secure channel.

My guess is that you didn't do it, which is why when you send this:

 VB.net Client:-

 stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='jabber.com'
version='1.0'

You get this:

 Jabber Server Responds:-

  failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'//stream:stream

-Justin

Re: [jdev] cert handling in xmpp server implementations

[Justin Karneges]

On Thursday 25 May 2006 05:47, Jonathan Siegle wrote:
 Tony Finch said the following on 5/25/06 8:08 AM:
  On Wed, 24 May 2006, Peter Saint-Andre wrote:
  I am working with a certification authority on adding XMPP support to
  the certificates they issue.
 
  Has anyone written a straightforward description of how to generate a
  proper XMPP cert with all of the id-on-xmppAddr stuff using OpenSSL?

[...]
 Open up your openssl.cnf file and look for the new_oids section. They
 have an example there too. Oh and look at the man page for req. It has
 lots of examples of OIDs.

And if you're wondering how to do it in code, have a look at the qca-openssl 
plugin from the QCA project:
  
http://websvn.kde.org/trunk/kdesupport/qca/plugins/qca-openssl/qca-openssl.cpp?rev=540405view=auto

Search for 'XMPP' in there.

-Justin

Re: [jdev] cert handling in xmpp *client* implementations

[Justin Karneges]

On Wednesday 24 May 2006 14:46, Peter Saint-Andre wrote:
 Speaking of cert handling, how do jabber/xmpp clients currently handle
 server certificates? One approach would be to use the existing Mozilla
 NSS store, which is on Linux distros and even many Windows distros. But
 it would be good for clients to do the right thing in handling the
 certs for jabber/xmpp servers (I guess that would mean following best
 practices derived from the browser and email client markets).

 Perhaps it would be good to document such best practices? Section 14.2
 of RFC 3920 talks about this, but the text there may be a bit opaque for
 many client developers...

Psi 0.10 and prior contains a copy of the Windows root certificates from a 
couple of years ago and uses that on all platforms.

Psi 0.11 (e.g. the betas) and onward uses the root certificates of the 
operating system, and does not bundle certificates anymore.  The benefit of 
this approach is that a user can install a root certificate systemwide and 
then it just works in Psi.  This functionality works on Windows, Mac, and 
Debian (or compatible Linux distros).  For operating systems that don't have 
root certificates (other linuxes or unixes), Psi bundles the Mozilla root 
certificates.

IMO, I consider this to be the best practice.  However, Mozilla doesn't do 
this for some reason.  On Windows, for example, they ignore the operating 
system certificates and instead use their own bundled set.  I'm now curious 
what Opera does.

  IE - system
  Safari - system
  Firefox - bundled
  Thunderbird - bundled
  Psi 0.11 - system

-Justin

Re: [jdev] cert handling in xmpp server implementations

[Justin Karneges]

On Wednesday 24 May 2006 13:46, Peter Saint-Andre wrote:
 I am working with a certification authority on adding XMPP support to
 the certificates they issue. My contact there wants to know about how
 various jabber/xmpp server implementations handle certificates. That is,
 do the servers operate like Apache (where you install a key, certificate
 and various CA files) or can they handle pkx files (like IIS or Domain
 Controllers of the Microsoft type)?

Speaking for Ambrosia (which is not very relevant, but...), currently PEM 
files are used, but PKCS#12 files (e.g. pkx) sure are convenient. :)  It is a 
standard format by the way, not a Microsoft-ism, and OpenSSL has supported it 
since forever.  I plan to support both methods.

And that will go for Psi too, when specifying a client cert (something I don't 
think you mentioned in either thread?).

-Justin

Re: [jdev] Re: GNUPG as DLL

[Justin Karneges]

On Monday 24 April 2006 05:52, George Hazan wrote:
 Yep, probably because that EXE should be completely rewritten to allow to
 use the existing code as DLL.. For example, right now it uses global
 varibles instead of context structures. That's why I was looking for a
 brave guy :=)

I believe their rationale is that a single exe is more secure (less 
possibility of the app tainting it) and makes support easier (only one way to 
use gpg, less variations).

... and it is probably full of globals. :)

 Even on a PIV/2800 with 1GB RAM it takes about 200-300 msec to launch the
 gnupg.exe and process its result. Such a delay itself is a mess for a user
 who can type quickly.

Which is why I said on average.  I don't think users are going to type 3-4 
messages per second on average.  With proper pipelining of the app, there 
shouldn't be a problem.

Someone brought up Psi as an example of GnuPG slowness being bad for fast 
typers.  However, this has more to do with Psi's disabling (graying) of the 
chat input field during encryption than the speed of GnuPG.  The behavior in 
Psi is intentional, but it is not the only behavior possible.

-Justin

Re: [jdev] GNUPG as DLL

[Justin Karneges]

On Friday 21 April 2006 06:44, George Hazan wrote:
 Does anybody know about an attempt to compile the GNUPG sources as the DLL
 for Win32? It takes too much time  resources to call that EXE every time I
 want to decode/encode a message in a Jabber client, so the chat becomes
 very slow...

As far as I know, the GnuPG developers intentially don't provide a DLL form of 
the program.  This is why even GPGME (GnuPG Made Easy, the official library 
for apps to use) calls gpg.exe behind the scenes.

Anyway, the slowness is more likely due to the cryptographic operations and 
other GnuPG housekeeping.  Having GnuPG in DLL form would only save you the 
time to load GnuPG into memory, which is probably not where your cpu cycles 
are going.

How fast is your computer?  Encrypting a GnuPG message for Psi is on average 
faster than the rate someone would chat, I think.  Yes, it is slow, but 
acceptable.

-Justin

Re: [jdev] Local proxy for multiple applications

[Justin Karneges]

On Friday 21 April 2006 08:52, Michal Vaner (Vorner) wrote:
 someone to comment on this a bit, if it is a good idea. I'm sending it
 here, because I think it has nothing to do with standards, it is just
 another way for a design for client software

It is a good idea, and not a new one either, but so far it hasn't really 
caught on.  There have been a couple of attempts at a client daemon, the 
most recent being Edrin's xcd for Windows.

I'd like to revive this idea sometime in the future, but I'm not sure when.

-Justin

Re: [jdev] Security-related thought experiment

[Justin Karneges]

On Friday 24 March 2006 22:32, Robert B Quattlebaum, Jr. wrote:
 Limiting the size of a single stanza may or may not fix the problem,
 depending on implementation. If the stanza size filter is applied to
 the stanza after it has been parsed, then this isn't good enough--the
 attack will still be successful because the stanza will never finish
 parsing. However, if the parser kept track of how large the stanza
 was getting as it was parsing it, then this attack can be avoided.

 Any thoughts, or other methods of preventing this attack from being
 successful? Or has this already been considered and fixed?

Just count the network bytes before they go into your XML parser.

Iris uses a SAX parser, and I had a limiter that would just count all the 
network bytes put into it, and reset the bytes whenever a full event (e.g. 
stanza endElement) completed.  The connection could just be dropped if the 
limit were exceeded.

However, I ended up throwing this mechanism out, because from a client 
perspective it doesn't really help at all.  The problem is that you don't 
know what your Jabber server's stanza size limit is, and some servers may not 
even have a limit.  This means that even with a limit in your client, anyone 
can DoS you by just sending a stanza larger than your client limit but 
smaller than your server limit (easily done if your server has no limit), and 
your client would happily disconnect from your own server.  Oops!

I'd say until we get a size negotiation for c2s, this problem is not fixed.

-Justin

Re: [jdev] JID and X.509

[Justin Karneges]

On Wednesday 08 March 2006 05:39, Heiner Wolf wrote:
 I understand that the certificate holds keys as OIDs. Any idea how this
 fits to the mentioned key-value pairs? I doubt that X.509 APIs know the
 OID for id-on-xmppAddr. So I doubt that putting
 id-on-xmppAddr-[EMAIL PROTECTED] into my API does any good. Ideas?

You are correct.  Many APIs work with a set of known keys.  You need an API 
that is either aware of xmppAddr, or one that will allow you to set an 
otherName extension with an OID (that dotted string thing) and everything.  
Some APIs won't even have this, in which case adding xmppAddr would be 
impossible.  However, even if you're able to set an extension, you'll still 
need to create the value part, which would be some sort of binary packed 
ASN.1 (but fortunately for xmppAddr, it is rather simple).

Below is a snippet of one of my mails with Jack Lloyd (of Botan) last November 
discussing the otherName support in QCA (my security library).  I had to 
learn up on ASN.1 to get this right.  Maybe it will be useful:

--
To be sure that I'm doing OtherName properly, here is a sample SubjectAltName 
value that contains the XMPP OtherName (from 
http://www.xmpp.org/specs/rfc3920.html Section 5.1.1).

30 = 0011 - universal, constructed, type 16 (sequence)
35 = 00110101 - 53 bytes
 81 = 1001 - context specific, primative, type 1 (email)
 12 = 00010010 - length 18
  6A 75 73 74 69 6E 40 61 66 66 69 6E 69 78 2E 63 6F 6D ([EMAIL PROTECTED])
 A0 = 1010 - context specific, constructed, type 0 (otherName)
 1F = 0001 - length 31
  06 = 0110 - universal, primitive, type 6 (object id)
  08 = 1000 - length 8
   2B 06 01 05 05 07 08 05 - 0x2B = 43, x = 1, y = 3 (1.3.6.1.5.5.7.8.5)
  A0 = 1010 - context specific, constructed, type 0 (otherName value)
  13 = 00010011 - length 19
   0C = 1100 - universal, primative, type 12 (utf8 string)
   11 = 00010001 - length 17
6A 75 73 74 69 6E 40 61 6E 64 62 69 74 2E 6E 65 74 ([EMAIL PROTECTED])

The DER was generated by some openssl-based code that I shared with you eons 
ago, and this is my hand-decoding of the resulting OCTET STRING found inside 
SubjectAltName.  Maybe you can check this to see if it looks right (and I've 
attached the cert to this email if you want to parse it).

Right now, QCA has direct support for the XMPP OtherName.  However, I'm 
considering taking it out and having my XMPP code use the QCA extension API 
instead, as a way to prove the extension system.  Here's an example of what 
it might look like in use:

  #define XMPP_NAME 1.3.6.1.5.5.7.8.5

  QString jid = [EMAIL PROTECTED];
  QByteArray buf(19);
  buf[0] = 0xC0; // universal, primative, type 12 (utf8 string)
  buf[1] = 17;   // length 17
  buf += jid.toUtf8();

  altNames.addOtherName(XMPP_NAME, buf);

Of course, I'll probably want more advanced length encoding for larger 
UTF8String values, but you get the idea.  I think this interface shouldn't be 
too painful for minimal extension values, such as XMPP.  I guess if things 
get complex then the user will want to bring along an ASN.1 parser, but at 
least it will be possible.
--

Good luck,
-Justin

Re: [jdev] JID and X.509

[Justin Karneges]

On Tuesday 07 March 2006 12:05, Peter Saint-Andre wrote:
  Canditates for storing the JID are: userID id-on-xmppAddr

 RFC 3920 is clear on this. I would say that userID is not a candidate
 (although RFC 3920 does not prohibit that, since it says only that the
 JID MUST be stored as an otherName in the subjectAltName, IMHO it is not
 a good idea to store the same information in two places).

Currently, everyone puts the domain of a server in the commonName.  And this 
is also consistent with RFC 3920's recommendation of using the HTTP methods 
to verify if a certificate in a c2s/s2s connection is valid.  Thus, it should 
be quite acceptable to put the value in three fields: commonName, dNSName, 
and xmppAddr otherName.

We should probably not put nodes into the commonName and dNSName fields.  
These fields should only be used if your JID is domain-only.  However, it is 
not clear if this is forbidden (maybe something to note in 3920bis?).

As I think about this some more, it seems to me that in a Jabberized world, 
the only field we'd care about is xmppAddr.  dNSName and commonName are 
really only there for compatibility with existing CAs and restrictive TLS 
implementations.

As I think about this even /more/, I wonder if we should allow fallback of 
JIDs with nodes into the rfc822Name field.  This may help with 
similarly-restrictive S/MIME implementations, as well as CAs.  I agree that 
putting the same information in two places is not a great idea, but there 
seems to be a standard practice of already doing it with domains, so I think 
it is worth considering for jid-email.

  Any other ideas? BTW: What means id-on- in id-on-xmppAddr? Why nt
  just xmppAddr?

 It's ASN.1 madness, don't ask.

And just shorthand for documentation purposes.  The string is basically like a 
namespace, and the prefix helps give an idea of what it is for, which I think 
is Identity-OtherName (just a guess).  This namespace string doesn't appear 
in the Certificate anywhere, only the OID does, so there's no reason to get 
too hung up about it.

-Justin

Re: [jdev] Re: JEP-0027 (OpenPGP) implementation question

[Justin Karneges]

On Tuesday 07 March 2006 09:13, Peter Saint-Andre wrote:
 Looking at JEP-0116 again, I see that public keys are used to verify the
 identity of the parties, but that the stanzas themselves are signed and
 encrypted with session keys. So identity is asserted and preserved in
 the initial negotiation, but not attached to each stanza. Or so it seems
 (I need to read JEP-0116 again in depth).

I believe identity is attached at all times.

For the OTR feature, though, something is done later to make the packet 
signatures worthless.  The idea is that both parties can have full trust in 
each other's identity during the conversation, but it is not possible to 
later prove that each party actually said what they said, since forgery 
would be easy at that point.

Calling OTR anonymous is a stretch.  Anonymous is room full of people and 
having to guess the one that did it.  OTR is more like a Matlock show, where 
Andy knows who did it, even if he doesn't have court-admissable evidence yet.

-Justin

Re: [jdev] Re: JEP-0027 (OpenPGP) implementation question

[Justin Karneges]

On Tuesday 07 March 2006 14:12, Peter Saint-Andre wrote:
 So the repudiability and perfect forward security aspects of OTR don't give
 me much comfort in the real world.

Exactly.

Interesting of you to bring up forward secrecy here.  I believe that's where 
if your public key is compromised, your past session keys aren't.  TLS has 
this (and probably SSH also), and I'd consider this to be a generally useful 
feature.  However, in the context of IM, where you're sending your content to 
another party with a large chance of it being logged, forward secrecy seems 
to be a lot less useful.

-Justin

Re: [jdev] JEP-0027 (OpenPGP) implementation question

[Justin Karneges]

On Saturday 04 March 2006 14:19, Michal Vaner (Vorner) wrote:
 the point with PGP is that user checks and signs the key (if he trusts it).
 Therefore, key exchange can not happen automatically, since it would break
 one of the main idea of PGP, that user knows who he is encrypting to.

With that in mind, another way to think about JEP-27 is that it is meant for 
people who have already traded PGP public keys and put trust in them.  For 
these existing users of PGP, secure chat just works.

Now, if one or both parties were using Jabber first and have no idea what PGP 
is, things get more tricky.

-Justin

Re: [jdev] virtual hosting and certificate checking

[Justin Karneges]

On Friday 03 March 2006 01:41, Tony Finch wrote:
 On Fri, 3 Mar 2006, Jesus Cea wrote:
  In current TLS, client gives the host it is trying to connect, BEFORE
  negociating crypto. So if you are using a modern webserver and a modern
  browser, you can share the IP.
 
  I just don't remember if this feature is present in TLS 1.0 or in the
  current draft for next revision.

 This is an RFC 3546 extension to TLS 1.0 - the server name indication.
 It appears that this is not supported by OpenSSL but it is by GnuTLS.
 Modern browser in this situation means released within the last few
 months.

Hmm, there shouldn't be a need to introduce server names into TLS, which is 
technically supposed to exist independently of TCP/IP.

IMO, a better way would be to use RFC 2817, which allows upgrading a plaintext 
HTTP connection to TLS dynamically.  It works essentially the same way as 
XMPP's starttls.  Sadly, no one actually uses this great spec.

-Justin

Re: [jdev] virtual hosting and certificate checking

[Justin Karneges]

On Wednesday 01 March 2006 15:49, Peter Saint-Andre wrote:
 Yes, CAcert is great and I've been working with them to get support for
 id-on-xmppAddr into their certs. But that doesn't necessarily make it
 easier for people who are hosting a *lot* of XMPP domains to support TLS.

SSL/TLS is supposed to be end-to-end, in the sense that the client and server 
are the ends.  Even if two domains are hosted at the same hosting service, I 
would definitely not condone sharing of the private key unless the domains 
are intimately related (e.g., they are owned by the same customer account).

-Justin