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: > > 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.
That was the original use case (in fact I don't know of any jabber clients that bookmark web pages, but there may be some). I think that it was not intended as a generic way to store any URI, but that it was specific to web pages. Naturally if we want a way to store any URI, we could write a separate spec for that. :) > 2) The format for storing XMPP conference rooms includes a password. Password protected rooms are rare (typically people create members-only rooms). I wonder if we even need this feature. > 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. Correct. That's bad. > 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. Agreed. > 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. Might. But if I bookmark the room as requiring a password but the room owner changes the room to no longer require a password, then we have possible confusion. So I would vote for (i) don't include the password elemenet (and deprecated ASAP). > 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. Thanks for the pointer! Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
