> -----Original Message----- > From: Peter Saint-Andre [mailto:[email protected]] > Sent: Friday, September 21, 2012 11:40 AM > To: XMPP Standards > Cc: Todd Herman > Subject: Re: [Standards] Question regarding XEP-0077 (In-Band Registration) > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/21/12 9:32 AM, Todd Herman wrote: > >> -----Original Message----- From: [email protected] > >> [mailto:standards- [email protected]] On Behalf Of Matthew Wild > >> Sent: Friday, September 21, 2012 11:17 AM To: XMPP Standards > >> Subject: Re: [Standards] Question regarding XEP-0077 (In-Band > >> Registration) > >> > >> Hi Todd, > >> > >> On 20 September 2012 15:53, Todd Herman <[email protected]> > >> wrote: > >>> I wanted to confirm something in section 3.1.1 of XEP-0077. > >>> It seems to suggest that you can register with a server prior to > >>> authentication, meaning that no account is required. We are > >>> attempting to do this, using OpenFire, right after TLS but before > >>> SASL. The appropriate Iq is sent and we get the correct response. > >>> However, when we send the next Iq with the username and password, > we > >>> get back a Failure element with “Not-Authorized”. I wanted to be > >>> sure that I am understanding section 3.1.1 correctly before I pursue > >>> other > >> options. > >> > >> Which iq do you send and which response do you get? Could you perhaps > >> paste an example XML log? > >> > >> Is in-band registration definitely enabled on the server? > > > > I apologize for not responding sooner but the issue is now resolved. > > It was an issue with SASL still happening do to an asynchronous > > operation running in the background. I think we may have an > > additional question as we have a new discrepancy but we are conducting > > some additional testing before bringing it up. I might be able to > > head off some questions by asking everyone what they think the term > > "service", referenced in the XEP is referring too. > > > > The XEP lays out two distinct uses for in-band registration: a > > service registering (I assume on behalf of another user) and the user > > registering themselves during the negotiation process with a server. > > Actually, the scenarios are user registering with server (necessary in order > to > get on the network in the first place) and user registering with add-only > service once on the network.
Ok. I think I get you. So we have the first one taken care of. The user, without an account on the XMPP server itself, can register themselves then login. If I am understanding the second server, we are talking about registering with some service, such as MUC, and NOT another method for registering with the server itself. Is that correct? > > We have handled the second case and are working on the first. We > > assumed that "service" referred to some application (client or > > component) that already has an account and would simply use the > > registration process to register another use. Is this an accurate > > assumption? > > By "service" we mean something like a multi-user chat service, which you can > access using your "home" XMPP account once you're connected to the > network. See for instance: > > http://xmpp.org/extensions/xep-0045.html#register > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBcikUACgkQNL8k5A2w/vxoOgCgjzHIP8Lu5AVO2ZHclNSO92o > h > wz8AnjnOpEOBOl947PTH2TiEh4DxqjTF > =DWTW > -----END PGP SIGNATURE-----
