[standards-jig] JEP-0077 Use Case Question

JD Conley jconley at winfessor.com
Tue Jan 13 22:22:16 UTC 2004


Ok, so the answer to my question is:

If the get request is sent by an authenticated user, the host will
respond with the username and any other existing registration
information for that user, including any x:data forms or iq:register
fields that the host happens to require, along with the <registered/>
element.  The user can then change their registration data as needed and
submit the set.

JD

> -----Original Message-----
> From: Joe Hildebrand [mailto:JHildebrand at jabber.com] 
> Sent: Tuesday, January 13, 2004 1:49 PM
> To: 'standards-jig at jabber.org'
> Subject: RE: [standards-jig] JEP-0077 Use Case Question
> 
> You send the get request for several reasons:
> - this is the typical pattern for IQ interaction.  
> Get/result,set/result
> - the client may not have stored the register form (keep in 
> mind that there
> may be an x:data form in the get results)
> - the server configuration may have changed between when the client
> registered and when they want to change their registration info.
> 
> Vcard typically isn't affected by registration, but I could imagine
> implementations that tied the two together.
> 
> -- 
> Joe Hildebrand
> 
>  
> 
> > -----Original Message-----
> > From: JD Conley [mailto:jconley at winfessor.com] 
> > Sent: Tuesday, January 13, 2004 10:49 AM
> > To: standards-jig at jabber.org
> > Subject: RE: [standards-jig] JEP-0077 Use Case Question
> > 
> > I thought about that, but I find it really strange that you 
> would send
> > the get request if you're already registered.   If you're 
> > changing your
> > password you know the fields that you're going to send (username,
> > password) so why would you send the 'get'?  Is this a way to 
> > maybe update your registration data (vcard type stuff)?  If 
> > so, I think that should be stated in the JEP.
> > 
> > JD
> > 
> > > -----Original Message-----
> > > From: Joe Hildebrand [mailto:JHildebrand at jabber.com]
> > > Sent: Monday, January 12, 2004 7:05 PM
> > > To: 'standards-jig at jabber.org'
> > > Subject: RE: [standards-jig] JEP-0077 Use Case Question
> > > 
> > > You may have already authenticated.  This is how you change your 
> > > password in-band.
> > > 
> > > --
> > > Joe Hildebrand
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: JD Conley [mailto:jconley at winfessor.com]
> > > > Sent: Friday, January 09, 2004 2:37 PM
> > > > To: standards-jig at jabber.org
> > > > Subject: [standards-jig] JEP-0077 Use Case Question
> > > > 
> > > > Example 3 in the "3.1 Entity Registers with a Host" use 
> > case states 
> > > > that a host can inform the registering entity that it 
> is already 
> > > > registered.
> > > > However, at that point how does it know who the registering
> > > entity is?
> > > > The host hasn't received a username element and the get 
> > request to 
> > > > determine the registration fields did not include a 
> from address.
> > > > 
> > > > So.. Should the initial get request include a from address or 
> > > > username field?  Or should the <registered/> notification occur 
> > > > after the entity attempts to register with the set, 
> including all 
> > > > the required fields from the host.  But this seems to be 
> > handled by 
> > > > the Conflict exception.
> > > > 
> > > > JD
> > > > _______________________________________________
> > > > Standards-JIG mailing list
> > > > Standards-JIG at jabber.org
> > > > http://mailman.jabber.org/listinfo/standards-jig
> > > > 
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > http://mailman.jabber.org/listinfo/standards-jig
> > > 
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> > 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 



More information about the Standards mailing list