[Standards] LAST CALL: XEP-0048 (Bookmarks)

[Peter Saint-Andre]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20071018/8ed27bd3/attachment.bin