David Waite wrote:
Mabey you missunderstand me. I want every user to have to log in, and SASL, at least the implementaion I am using, cyrus SASL, holds the usernames and passwords itself. It also alows users to be created within the Challeneg / Responce cycle. If I can not add users using SASL itself, then I need to know how to interface with the SASL password files, because I only want one password list, not 2.Matthew Beacher wrote:Robert Norris wrote:This hasn't really been discussed in any detail. I would suggest joining the XMPP working group and bringing this question up there: http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/
I'll read that as: Use the one built in the standered, not SASL as it is not in any clients. So I ask, Anyone know how to interface with SASL password files? I am guessing they are based on Unix Password Files.
The jabber:iq:register namespace is non-normative within the XMPP IM draft. Implementations can choose to implement registration, but it is not really required or standardized.
The use of Transport Encryption is not up to the server, if a Transport Encryption is negoshiated during SASL, you must use it, if it is nigoshiated. This is according to cyrus SASL docs.<message to='receve-id' from='send-id'>
fexable - Accept this code
hard line - elements not in correct order, dump line.Attributes are always order-independant. Now, if you mean something like <message> <body/> <subject/> </message> The body and subject childs are allowed in any order by the existing DTDs.Well, not for everyone, but all server and clients that support SASL must use it with a minimum level of encription. And then make sure that EVERYONE starts including SASL. It is very easy to include IFF (if and only if) you use the cyrus SASL code relesed by Carnegie Mellon University.
I do not want to use transport encryption, because
1) it does not provide any solid security because of existing non-encrypted connections, and because you cannot guarantee trust of the remote endpoint across hops (in real-world terms, "a friend of a friend of a friend once told me about this guy" should not have the same amount of trust as actually knowing the person being talked about directly.)
2) it is impractical for many embedded applications.
3) it puts unneccessary load on the server
-David Waite
Matt
SyOpReigm
http://www.Reigm.Com
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
