Dave Cridland wrote: > On Wed Oct 3 21:39:36 2007, Peter Saint-Andre wrote: >> http://www.xmpp.org/extensions/tmp/xep-0048-1.1.html > > Two comments I think need to be addressed relatively urgently:
<snip/> Let us know if you think version 1.1pre4 addresses your concerns: http://www.xmpp.org/extensions/tmp/xep-0048-1.1.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0048.xml?r1=1260&r2=1298 Or, well, you're an XMPP Council member, you can weigh in at the next meeting: http://www.xmpp.org/council/agendas/2007-10-24.html /psa > 1) The document says it's defining a data format to store XMPP > conference rooms and "HTTP URLs" - is there any problem with storing > other scheme URLs? I can't see a reason for this restriction. > > 2) The format for storing XMPP conference rooms includes a password. > This leads to two things: > > a) The password may be exposed, if TLS is not used, etc, to a third > party sniffing the connection. Although MUC uses the password in > plaintext anyway, it seems likely to me that the password is likely to > be more visible by this method. > > b) The password may be exposed to the server administrator - if it's a > foreign administrative domain holding the conference room. Again, this > exposure can happen anyway, if the MUC room is connected to, it just > seems to me to making the problem worse. > > These should be mentioned in the Security Considerations, and we should > consider alternative options, which may be: > > i) Don't ever put the password element in - clients should handle the > error on joining and prompt the user for the password. > > ii) Do put the password element in, but leave it empty, and say that a > zero length string as a password is a special case meaning that the > conference room requires a password, and the client should prompt the > user for it. > > The latter mechanism might save a round-trip. > > More involved comments: > > There's quite a wealth of prior art in the area of bookmark storage and > roaming. Not only is there XBEL and existing browser formats, but > there's also the ACAP dataset class for storing bookmarks. This is > pretty readable even if you don't know about ACAP. > > http://tools.ietf.org/html/draft-ietf-acap-book-06 - Section 4.2 is the > one to read. > > Both XBEL (which I only vaguely recall) and the ACAP dataset (which I've > implemented) contain more than just title and URL. Some of this data has > been overtaken by trends - a hierarchy of bookmarks is no longer > ubiquitous - but a lot hasn't, such as a description, etc. > > Dave.
smime.p7s
Description: S/MIME Cryptographic Signature
