Re: [Standards] Markdown in XMPP IM
On Tue, Jan 5, 2016 at 4:49 PM, Peter Waher <peterwa...@hotmail.com> wrote: > Hello > > Does anyone have experience in using markdown in XMPP IM chat applications? I would suggest just converting the markdown to XHTML client-side and sending that one, so you're backwards-compatible. The plain text could just be the markdown text, as Travis Burtrum suggested (although embedded links look a bit strange that way). Regards, Andreas Monitzer ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Stream Management and Acks (XEP-0198)
Having worked on protocol servers for many years I have learned that clients will send you junk. (I see ESMTP/IMAP in your sig, so I know you know what I'm talking about :-) Thus, I cannot assume that whatever I'm talking to is well-behaved. I try to follow the be strict on what you send, liberal on what you receive principle. I want the end-users to have a good experience when enabling XEP-0198, and so, I'd like to mask as many errors as possible, including ones from buggy clients. As an XMPP client developer, I beg you to be as strict as possible with the protocols. If I unknowingly use a lenient server to check whether my implementation works, I would be misled into thinking that it's ok, when in fact it's not. Then it would fail with some other server I haven't tested. Dropping the connection on every minor implementation issue is the easiest way for me to identify and fix bugs that inevitably come up. XEP-0198 is a special candidate for those issues, since it's very hard to test in laboratory conditions (I had to constantly add and remove an IP address on my loopback device to simulate dropped connections). Regards, Andreas Monitzer
Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities
On Montag, 12. September 2011 at 23:22, Peter Saint-Andre wrote: One of the major problems with the current approach is that there's no hard border between identities and features, and between features and extensions. As a result, malicious software can define certain clever identities and features and extensions that bleed over into adjacent parts of the input string. One way to solve this problem is to define a new algorithm, either in a revision to XEP-0115 or in a new spec with a new namespace. To conserve space in presence, we'd prefer to avoid a new namespace. So that it is possible to continue using the vast majority of existing caps hashes, we'd prefer to keep the algorithm the same, if that can be accomplished in a secure way. While your solution is pretty ingenious, it strikes me as a huge workaround, and I wonder whether that's really what you want. Keep in mind that this spec is pretty central to XMPP, so every client has to implement it, and it shouldn't change that often (meaning this will stick around for a decade or more). A consequence of this is that it should be as simple as possible. The algorithm is already a mess (I know what I'm talking about, I had to implement it a few weeks ago), and this modification makes it even worse. Regards, Andreas Monitzer
[Standards] Proposal for XEP-0302
Hi, I'd like to propose XEP-0084 User Avatar to be included for the advanced client in the 2012 compliance suite. The vcard-temp-based avatars are a huge legacy that I'd be very delighted to see gone. User Avatar is already supported in all libpurple-based clients and I believe in others as well (unfortunately, Psi uses an incompatible old version of the protocol), and it's much easier to implement than XEP-0153. I'm fine with vcard-temp being in there until XEP-0292 is no longer experimental, but avatars should move forward. Right now, the Facebook and GTalk servers only support XEP-0153, which is very unfortunate. By the way, I think it's a bit strange to require PEP in the advanced client, but not a single PEP-based XEP. A client that supports PEP but no protocol based on it is not distinguishable from a client that does not support PEP at all. Regards, Andreas Monitzer
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
On Mar 16, 2009, at 12:42, Pedro Melo wrote: I like the framing part, as expected :). But why such a specific protocol? Why not just open a peer-to-peer XMPP stream and route everything between the two endpoints through it? You could even reuse end-to-end encryption XEPs. Because then you'd have to base64 encode all binary data, making most of the advantages of this extension mood. andy
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
On Mar 16, 2009, at 13:09, Dirk Meyer wrote: Yes, maybe restrict the usage to a stanza and not allow it inside a stanza by default. So a client MAY send any return from any XEP out of band, but only the whole result. If out of band is allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. That's not a good idea, since then you couldn't use it for binary data at all (since you never have base64-encoded data at the top level). Having it only in specific stanzas would mean that you couldn't implement a solution for everything, but only on a case-by-case basis (or you'd have to carry around a list of situations where it's allowed – ugh). andy
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
On Mar 02, 2009, at 20:23, Peter Saint-Andre wrote: I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that it would be good to add a reference type for an Ethernet address, such as: It seems that we'd need this because your ethernet address might be different from your wifi address even in the same location (e.g., where I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi address is 00:23:6c:88:d4:1d). My MacPro has two Ethernet ports built-in, bringing the total number of MAC addresses to 3. Some servers might have even more. andy
Re: [Standards] XMPP VPN?
On Jan 03, 2009, at 18:57, Stephan Maka wrote: Andreas Monitzer wrote: btw, Apple's iChat supports that kind of thing, even via XMPP (for negotiation, afterwards it switches to the Apple Remote Desktop protocol). I've used it a lot to help other people with computer problems, very useful. Is there any documentation on their protocols available? I don't think so. Apple was never one to document their protocols. andy
Re: [Standards] XMPP VPN?
On Dec 13, 2008, at 11:32, Jonathan Schleifer wrote: Sorry, I didn't mean that the idea was crazy of VNC via XMPP (whereas HTTP via XMPP sure is), but that VPN via XMPP is even less crazy :). Sure VNC via XMPP is [not] useless, and once again this is where XMPP could replace something proprietary: TeamViewer for example. btw, Apple's iChat supports that kind of thing, even via XMPP (for negotiation, afterwards it switches to the Apple Remote Desktop protocol). I've used it a lot to help other people with computer problems, very useful. andy
Re: [Standards] XMPP VPN?
On Dec 12, 2008, at 20:09, Jonathan Schleifer wrote: Well, I recently saw that Wippien has VPN support and uses XMPP for the messaging part. I thought that it maybe might be a good idea to have a XEP for VPN via XMPP. I think this could be achieved quite well with Jingle. We would just need a XEP which specifies how the packets should be transfered over the tunnel established by Jingle. What do you think? Maybe PPP over Jingle? andy
Re: [Standards] invisibility
On Oct 06, 2008, at 18:08, Jonathan Schleifer wrote: Yes, I agree, privacy lists give us all we need for invisibility. Some might see this as abusing privacy lists, but IMO, that's what they are for. They are to block presence or messages to specific users and/or groups. And all users could also be seen as a group. What I personally like about privacy lists: I can have my own invisibility mode, which means I'm invisible to all except a few persons. I can also have more than one invisiblility mode: For example one that just hides me from groups that are often annoying. Ideally, the client would have a sub-menu invisible where I can define my own invisible modes via privacy lists. There's only one thing I'm missing in privacy lists: Time-based privacy lists. So you can say I want to be invisible to group A, B, C etc. from 8pm to 8am. This would be for example useful if you don't want to get annoyed by your co-workers in the evening. The server would then automatically enable the privacy list if you selected a time for it. I'm sorry to say, but you're not the target audience for 90% of the XMPP clients. I'd get laughed out of the #adium channel if I'd propose a user interface that would be required for a privacy list generator that would be able to generate the lists you described. In addition, if you don't want to wipe the user's privacy lists that are already there, you also need a semantic analyzation of them, which is probably worth writing a paper on artificial intelligence on that topic. If I just let the user do that, I'd have to ask the user to learn programming to manage the interface. In addition to that, if two instances of my client, or another client implementing privacy lists, connect to the same account, all bets are off. Anything could happen. The privacy lists are very potent, but their complexity is just too much for mere mortals. andy
Re: [Standards] website transition
On Sep 09, 2008, at 11:48, Jehan wrote: 1/ is the design remaining of the new jabber.org's website like this? It is sufficient for me in an efficiency point of view, but i don't find it so nice in a beauty point of view. Not really appealing for people discovering Jabber (the Drupal version was nicer, at least in my point of view)... Agreed. It'd help a lot if the guest view would lose the tabs at the top and the toolbox/website sections on the left, though. They're totally unnecessary. andy
Re: [Standards] website transition
On Sep 08, 2008, at 19:55, Peter Saint-Andre wrote: If you find any website problems, please let us know! Yes, my feature request dating back to the website version even before the move to drupal still isn't implemented, even though I was repeatedly told that it's on the todo list since back then :( My request was to have an RSS or Atom feed of the public server list, so I can display that list in Adium in the registration dialog. Of course, moving to a wiki makes the whole thing even worse, since there's no easy solution to that problem now (since the completely nonsemantic wiki code is the only data source). I could do some kind of html extraction, but that would break as soon as someone does an edit that changes the website slightly. All the data I need is there, I just can't access it... andy
Re: [Standards] website transition
On Sep 08, 2008, at 21:36, Peter Saint-Andre wrote: I had totally forgotten about that feature request. Yes, that's what I hear every time I remind somebody of the jabber.org- team :) We do have a plain XML file: http://www.jabber.org/servers.xml But perhaps that's not what you need. Well, I'd need the additional info available on the detail pages, too: e.g. http://www.jabber.org/web/Jabber.org esp. the description, location and lat/long. Right now I'm hand-editing servers.xml... Uh, you should know better than that... andy
Re: [Standards] online users counter
On Jul 29, 2008, at 14:11, Sylvain Mundialco wrote: Hi. Have one question here. Is there a way to query the xmpp server to know the total users currently online. Is it define in one of the xep ? Hi, ejabberd uses Ad-Hoc commands for this, returning a form with the requested information. http://www.xmpp.org/extensions/xep-0050.html andy
Re: [Standards] Voice clips
On Jun 23, 2008, at 20:20, Dag Odenhall wrote: Or maybe it should even be a protocol for in-lining any form of data: embed type=application/ogg[binary base64]/embed embed type=image/png[binary base64]/embed Like this one? http://www.xmpp.org/extensions/xep-0231.html andy
Re: [Standards] [Simple] New draft submitted: Attention Request (POKE) for Instant Messaging
On Jun 16, 2008, at 18:37, Peter Saint-Andre wrote: I would not say that XEP-0224 has been implemented widely yet. Pidgin and Adium do implement it, but changing the namespace there shouldn't be a major problem. andy
Re: [Standards] [Simple] New draft submitted: Attention Request (POKE) for Instant Messaging
On Jun 16, 2008, at 19:09, Marcus Lundblad wrote: mån 2008-06-16 klockan 18:44 +0200 skrev Andreas Monitzer: On Jun 16, 2008, at 18:37, Peter Saint-Andre wrote: I would not say that XEP-0224 has been implemented widely yet. Pidgin and Adium do implement it, but changing the namespace there shouldn't be a major problem. Infact, the implementation in libpurple doesn't announce support correctly presently. I've made a patch that fixes that. It has not yet been reviewed though. Yes, getting changes into libpurple is not that easy. The API for implementing buzz changed in the libpurple core after I wrote that implementation, and it took ages to get ported to the new one. By the way, was XEP-0224 first suggested by the Adium team? Well, you could say that. I wrote it as part of my Google Summer of Code project for Adium last year, where I was working on adding features to libpurple's XMPP implementation. andy
Re: [Standards] MUC History clearing
On May 15, 2008, at 16:03, Joe Hildebrand wrote: On 5/15/08 5:53 AM, Tomasz Sterna [EMAIL PROTECTED] wrote: Dnia 2008-05-15, czw o godzinie 11:21 +0200, Andreas Monitzer pisze: Well, no, not just bots. In a typical chat client, you have a list of users in the channel and would like to click on them, then activate kick from some list/some button/etc and don't have to fill out some form for that. Isn't this an UI issue? That's the way I was thinking about it. I assumed that if there was a jid-multi field, it could be populated with the currently-selected participants. Kick often pulls up a dialog today, to ask for the reason. The UI could decide whether to even show the jid-multi field; if not, the resulting dialog would end up looking pretty similar to the existing one. Still, as long as there's no semantic meaning attached to the form, the client can only take a wild guess at the meaning of that field. For example, it could be an invite action, where putting in somebody already on the MUC would be totally pointless. Esp. when you hide that field, then you can only invite people that are already in the chat... This reminds me of certain web browsers that automatically fill in the user's address when they see a text field prefixed by Address:, even though it might mean something like IP-address. andy
Re: [Standards] RSS in message stanza?
On Mar 28, 2008, at 17:15, XMPP Dev wrote: Which RSS? OK. Point well taken. But I guess the answer to that question (since I'm just looking for _any_ info) is any. :-) Although, I s'pose 2.0 would be a starting point. As someone who once wrote an RSS parser, RSS cannot be considered to be an XML format, it only has remote similarities to it (some feeds more remotely and some much more remotely). Additionally, RSS does not support namespaces, and so you can't embed it directly in XMPP. However, you could escape it and include it as a text blob: rss xmlns=... lt;?xml version=1.0? lt;rss version=2.0 lt;channel lt;titleLift Off Newslt;/titlelt;linkhttp://liftoff.msfc.nasa.gov/lt;/link lt;descriptionLiftoff to Space Exploration.lt;/description lt;languageen-uslt;/language lt;pubDateTue, 10 Jun 2003 04:00:00 GMTlt;/pubDatelt;lastBuildDateTue, 10 Jun 2003 09:41:01 GMTlt;/lastBuildDatelt;docshttp://blogs.law.harvard.edu/tech/rsslt;/docs lt;generatorWeblog Editor 2.0lt;/generator lt;managingEditor[EMAIL PROTECTED] lt;/managingEditorlt;webMaster[EMAIL PROTECTED]lt;/ webMaster lt;ttl5lt;/ttl lt;item lt;titleStar Citylt;/ title lt;linkhttp://liftoff.msfc.nasa.gov/news/2003/news-starcity.asplt;/link lt;descriptionHow do Americans get ready to work with Russians aboard the International Space Station? They take a crash course in culture, language and protocol at Russia's Star City.lt;/ description lt;pubDateTue, 03 Jun 2003 09:39:21 GMTlt;/pubDate lt;guidhttp://liftoff.msfc.nasa.gov/2003/06/03.html#item573lt;/ guid lt;/item lt;item lt;titleSpace Explorationlt;/title lt;linkhttp://liftoff.msfc.nasa.gov/lt;/link lt;descriptionSky watchers in Europe, Asia, and parts of Alaska and Canada will experience a partial eclipse of the Sun on Saturday, May 31st.lt;/ descriptionlt;pubDateFri, 30 May 2003 11:06:42 GMTlt;/ pubDatelt;guidhttp://liftoff.msfc.nasa.gov/ 2003/05/30.html#item572lt;/guid lt;/item lt;item lt;titleThe Engine That Does Morelt;/title lt;linkhttp://liftoff.msfc.nasa.gov/news/2003/news-VASIMR.asplt;/link lt;descriptionBefore man travels to Mars, NASA hopes to design new engines that will let us fly through the Solar System more quickly. The proposed VASIMR engine would do that.lt;/description lt;pubDateTue, 27 May 2003 08:37:32 GMTlt;/pubDate lt;guidhttp://liftoff.msfc.nasa.gov/2003/05/27.html#item571 lt;/guid lt;/item lt;itemlt;titleAstronauts' Dirty Laundrylt;/title lt;linkhttp://liftoff.msfc.nasa.gov/news/2003/news-laundry.asplt;/link lt;descriptionCompared to earlier spacecraft, the International Space Station has many luxuries, but laundry facilities are not one of them. Instead, astronauts have other options.lt;/description lt;pubDateTue, 20 May 2003 08:56:02 GMTlt;/pubDate lt;guidhttp://liftoff.msfc.nasa.gov/2003/05/20.html#item570 lt;/guid lt;/itemlt;/channel /rss (this is the example from wikipedia) andy
Re: [Standards] Proposed XMPP Extension: Data Element
On Nov 10, 2007, at 00:38, Peter Saint-Andre wrote: URL: http://www.xmpp.org/extensions/inbox/data-element.html See, that was easy, wasn't it? ;-) I can see three issues here: 1. Your extension doesn't have any namespace and doesn't use the x- element. 2. URLs are limited to 1024 bytes IIRC, so your 10k limit can not be reached. If you go into the trouble of inventing a new element for it, why not put the base64-data between the tags? message from='[EMAIL PROTECTED]/castle' to='[EMAIL PROTECTED] ' type='groupchat' bodyYet here's a spot./body data type='image/png;base64' alt=A spot.iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP C/ xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq ch9// q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 vr4MkhoXe0rZigBJRU5ErkJggg==/data /message 3. Your data tag in the example starts with a ' but ends with a . (ok, that's nitpicking) andy
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 10, 2007, at 15:30, Sergei Golovan wrote: I just want to get a result of attention query. Hmmm well, I personally wouldn't care about it (since you can't know if the user noticed it anyways), but I'm rather indifferent on it. What's the opinion of others on this list about it? And I don't like to make many disco#info queries to determine current state of the remote client. That's what XEP-0115 is about, this is outside the scope of XEP-0224. Further, you can just send it to non-supporting clients, too. The XEP just says that you have to check for support, not that you must not send one to a non-supporting client (wouldn't do anything, though). I guess the disco#info check should be changed to a SHOULD instead of a MUST (I already changed that in my local version here). andy
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 09, 2007, at 21:55, Sergei Golovan wrote: I think that attention messages should not be sent with a body/, but should be a standalone message of type='headline', like so: message from='[EMAIL PROTECTED]/lab' to='[EMAIL PROTECTED]/home' type='headline' attention xmlns='http://www.xmpp.org/extensions/ xep-0224.html#ns'/ /message This message looks like iq/ but iq/ is better because the recipient may receive result in case of accepted attention or error in case of ignored one. The ability of getting a response even makes disco#info queries unnecessary. I chose to use message/ instead of iq/ because you don't have to specify a resource to send the message, and you don't need a reply on this one (every iq/-message is a potential memory leak, when the receiving client doesn't behave properly), because even when the client displays the attention grabbing event, you can't know if the user has seen/heard it. Is there a serious reason to go to iq/? The body/ element is not required in this spec, but I could change it to SHOULD NOT contain, would that be better? andy
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 09, 2007, at 22:46, Olivier Goffart wrote: I think the lower important level is related and should be include to this XEP. If you don't want immediate attention, why send the attention grabbing message in the first place? I could see a usecase for normal and urgent, but then again, once you do send that attention message, it's always urgent anyways. I don't think you can ask the originating users to make that distinction. I'd guess the local client could make that differentiation based on the own presence (don't play the attention sound when DND, only flash the screen, for example). andy
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 11, 2007, at 00:13, Sergei Golovan wrote: I know at least one client which will show an empty headline message (it's Tkabber, it can't imagine such strange headlines). Can someone bet that it's the only one? libpurple also had this bug, but I fixed it this summer. Maybe someone can file a bug on Tkabber? Specs shouldn't be designed around bugs of existing implementations... andy
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 11, 2007, at 01:57, Sergei Golovan wrote: On 8/11/07, Andreas Monitzer [EMAIL PROTECTED] wrote: Hmm would that be so bad? A headline window will surely draw more attention than a regular message. How this separate window would associate with a chat thread? Especially if chat and headline messages are stored in different histories. The message of the headline is not part of the discussion, and so shouldn't be stored along the rest. There is no association. IQ has a fixed clear structure. Its parsing usually performed by one routine, I don't know many XMPP implementations, but in libpurple, message/ is handled by a single function, whereas iq/-handling is spread around the whole XMPP plugin (since nearly every feature uses an iq stanza at some point). But it's not a big deal to process a message instead of IQ. What I want from any protocol detail is a feedback. XMPP would be much nicer if any stanza required an acknowledgement. For now, messages and presences are thrown without an acknowledgement (except for an ugly presence usage in XEP-0045 AFAIK). So, I'd like to use them as seldom as possible. Only if using message is unavoidable it may be used. (If I could, I'd use IQ even for a regular messaging.) This sounds more like you have a general issue with the XMPP protocol as such. This is outside the scope of my XEP, please discuss this on this list on the topic of rfc3921bis. andy
Re: [Standards] Re: inactive XEPs
On Jul 16, 2007, at 16:45, Magnus Henoch wrote: A little reminder: there is an ejabberd module for the server-side part, http://ejabberd.jabber.ru/mod_profile . It has been running on jabber.se for a couple of months, but right now there are exactly zero profiles in the database. I'm not surprised, considering that there are zero client-side implementations of it. What server-side things are required for this besides PEP? I thought the point of PEP was to avoid having to add server implementations for every small XEP? I've been thinking about using it to create a random chat application (e.g. match people who speak language X with eachother), but that will probably not happen in the foreseeable future :) That'd be quite nice actually :) Might also work perfectly for a dating service (match m+f where the city is the same). andy
Re: [Standards] how to treat invalid XMPP?
On Jul 16, 2007, at 19:31, Jakob Schroeter wrote: So far I just throw a parse error and disconnect the stream (when I implemented that, I never thought this would actually happen), but people complain about that. They're complaining to the wrong person, then. Also, that makes the receiving client look bad. However, just ignoring the offending character could possibly change the meaning of the data, so I don't think this is a good solution, either. What do you think? My opinion: Accepting this data in any way would be the worst thing possible. It would bring XMPP one step closer to HTML, as already has happened with RSS (back when I wrote an RSS reader, I spent about 80-90% of the debugging time trying to parse some XML-like binary data). This would make life hell for XMPP developers, and should be avoided at any cost. andy
Re: [Standards] inactive XEPs
On Jul 13, 2007, at 20:54, Peter Saint-Andre wrote: The following XEPs have been inactive for 6+ months and therefore are subject to automatic deferral. If you have an interest in these specs, please speak up. XEP-0154: User Profile http://www.xmpp.org/extensions/xep-0154.html This is definitely something that should be looked at when PEP is widely deployed. Most of the inactive ones are PEP-based, which itself takes a lot of time to be implemented, and so it doesn't make any sense to work on those any further until this is resolved. andy
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
On Jul 06, 2007, at 14:13, Daniel Noll wrote: It may even be desirable to enable this per-user. Whether this means giving different users different disco results or giving the same result and silently dropping the packet, I'm not sure. I think I would prefer the third option, the sender getting a not-authorized error back. Isn't not-authorized an iq result, and thus not applicable for a message stanza? andy
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
On Jul 06, 2007, at 18:31, Peter Saint-Andre wrote: How do other services implement this kind of poke feature? I assume in the UI you can right-click or whatever to choose poke stpeter and your client sends this special message off to me. Usually, it's a button in the message window I think. I think it's less likely that you'd send a message (hey pay attention!) with the poke, but naturally you could do that. If my client didn't know anything about the poke namespace (or was configured to ignore pokes) then it would simply ignore that part of the stanza. Yes, that's what I was thinking. andy
[Standards] Removing PEP nodes?
Hi, I'm currently implementing PEP into libpurple, and have some issue I can't quite find explained in the XEPs: How do I remove a personal event? For example, the user published his/her mood using XEP-0107. Now he/ she wants to remove this information, without overriding it with a new mood. My guess is that it could look like this: iq type='set' from='[EMAIL PROTECTED]/ca486eba-0f9a-11dc-8835-000bcd821bfb' id='publish1' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='http://jabber.org/protocol/mood' item/ /publish /pubsub /iq Maybe I missed it, but I couldn't find that info anywhere in XEP-0107 nor in XEP-0163. XEP-0060 considers this syntax to be incorrect, but the situation is quite different there (I can't use retract/, since I don't have an id). What is the correct way to do that? andy
