On Thu, Oct 18, 2007 at 01:20AM, Ralph Meijer wrote: > On Wed, 2007-10-17 at 15:48 -0600, Peter Saint-Andre wrote: > > On Wed, Oct 17, 2007 at 02:40:26PM -0700, Justin Karneges wrote: > > > 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. > > > > How is ANONYMOUS used right now? Do XMPP servers (1) create a temporary > > node or (2) create a temporary resource for some anonymous user? I think > > that (1) is probably a safer approach, in which case it might be nice to > > specify the "trace" data in version 1.1 of XEP-0175 (and of course > correct > > rfc3920bis while we're at it). > > It seems to me that ANONYMOUS is inherently not intended to give a user > a more or less permanent handle that has part of the user's identity > encoded in it. > > As I see it, the trace data is for allowing administrators to have some > way to contact the user. The validity of this information is not > verified and also may cause privacy issues if sent automatically by > client implementations.
Yeah, that makes sense to me. -Mark
