From js-xmpp-standards at webkeks.org Sat Nov 1 04:05:31 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Sat, 1 Nov 2008 10:05:31 +0100 Subject: [Standards] About posting new topics to the same thread In-Reply-To: <490B88F6.5020202@yahoo.com> References: <490B88F6.5020202@yahoo.com> Message-ID: <6252FBB2-9852-4843-8E1A-9C1D3F51BC3E@webkeks.org> Am 31.10.2008 um 23:38 schrieb Brett Zamir: > Jonathan Schleifer wrote: >> Oh, and if we're already at it, you should stop using TOFU[1], >> which is considered very impolite on mailing lists. >> >> -- >> Jonathan >> >> [1] http://en.wikipedia.org/wiki/TOFU#Top-posting > > I personally strongly dislike bottom-posting, and the Wikipedia > article you cite also indicates there are preference differences out > there, including within mailing lists. - If you are sending a reply to a message or a posting be sure you summarize the original at the top of the message, or include just enough text of the original to give a context. This will make sure readers understand when they start to read your response. Since NetNews, especially, is proliferated by distributing the postings from one host to another, it is possible to see a response to a message before seeing the original. Giving context helps everyone. But do not include the entire original! http://tools.ietf.org/html/rfc1855 So there *IS* a standard for mailing lists. The Wikipedia article also states that this is the netiquette. > But instead of getting into a fruitless argument about what we think > is the "right" way, how about we consider some way to solve the > problem? Given that we already have the benefit of a formal > hierarchical structure within XMPP via XML, how about a namespaced > child of (too late for ) to keep track > of hierarchical content within a posting, which besides enabling > posting order display to differ by user preference, would also more > easily enable scripting to collapse or navigate a section of > quotations, differentially auto-color replies from particular users > or levels, etc.? Perhaps even XHTML-IM (XEP 0071) could be > overloaded for such a purpose via
's @cite attribute > (which could use an XMPP URI or email URI to indicate authorship) > and/or the @class attribute (e.g., to distinguish citations from the > "inner thread" from those outside of its context). We're using e-mail here, not XMPP :). > For that matter, how about some mechanisms to enable forking of > threads, even within a post? (along the lines of, and potentially > supporting, wikis, discussion forums, blogs, versioning systems, > etc., since, to my mind, these all should all only be slightly > different in terms of protocol syntax so that one can easily treat > one as (or convert one to) the other, as there is a lot of albeit > inadequate convergence between them already). (Sorry I am not too > well-informed on all of the numerous specs you all have marvelously > already put out there, so my apologies to whatever extent this > covers ground already covered.) Then we'd need to switch mailing lists to XMPP. Would be a use scenario for PubSub :). -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081101/72de05d4/attachment.pgp From editor at xmpp.org Mon Nov 3 21:15:16 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Mon, 03 Nov 2008 21:15:16 -0600 Subject: [Standards] Proposed XMPP Extension: Location Query Message-ID: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Location Query Abstract: This specification defines an XMPP protocol extension for querying a compliant server for information about the geographical or physical location of an entity." URL: http://www.xmpp.org/extensions/inbox/location-query.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. From stephenpendleton at hotmail.com Tue Nov 4 12:49:06 2008 From: stephenpendleton at hotmail.com (Stephen Pendleton) Date: Tue, 4 Nov 2008 13:49:06 -0500 Subject: [Standards] Proposed XMPP Extension: Location Query In-Reply-To: References: Message-ID: Very cool. Are you really using arc-minutes as units of the GPS error? > From: editor at xmpp.org> To: standards at xmpp.org> Date: Mon, 3 Nov 2008 21:15:16 -0600> Subject: [Standards] Proposed XMPP Extension: Location Query> > The XMPP Extensions Editor has received a proposal for a new XEP.> > Title: Location Query> > Abstract: This specification defines an XMPP protocol extension for querying a compliant server for information about the geographical or physical location of an entity."> > URL: http://www.xmpp.org/extensions/inbox/location-query.html> > The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.> _________________________________________________________________ See how Windows Mobile brings your life together?at home, work, or on the go. http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.jabber.org/pipermail/standards/attachments/20081104/ef4e39c7/attachment.htm From stpeter at stpeter.im Tue Nov 4 14:05:47 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 04 Nov 2008 13:05:47 -0700 Subject: [Standards] Proposed XMPP Extension: Location Query In-Reply-To: References: Message-ID: <4910AB1B.20307@stpeter.im> Stephen Pendleton wrote: > Very cool. > Are you really using arc-minutes as units of the GPS error? You'll have to ask the Buddycloud people about that, but I think they may not be on this list (however I know they're on the mobile at xmpp.org list). /psa From simon at buddycloud.com Tue Nov 4 15:59:04 2008 From: simon at buddycloud.com (Simon Tennant) Date: Tue, 04 Nov 2008 22:59:04 +0100 Subject: [Standards] [mobile] [Fwd: Proposed XMPP Extension: Location Query] In-Reply-To: References: Message-ID: <4910C5A8.1050106@buddycloud.com> Stephen Pendleton wrote: > Very cool. > Question for the authors: Are you really using arc-minutes as units of the > GPS error or is that carryover from the GEOLOC XEP? Props should go to Helge for the spec. I guess that writing specifications for unmanned aerial vehicles is finally paying off. I presume you are referring to this post: http://mail.jabber.org/pipermail/standards/2008-October/019920.html Arc-minutes are a carry over. We wrote the spec with XEP-0080 in mind and use that as the format for publishing the derived location to the user's geoloc node too. We would prefer to use accuracy in meters. While arc minutes may make sense in a GPS sense, accuracy often has to be implied when using other location means. For example, if the server is receiving Cell-ID beacons and some of the known beacons are identified as within a city an accuracy of 100m could be implied due to a known higher tower density. Trying to apply arc-minutes to this would probably end up just being clumsy and it would be nice to use the same unit of measurement for accuracy. S. -- Simon Tennant Buddycloud uk: +44 20 7043 6756 de: +49 89 420 955 854 uk: +44 78 5335 6047 de: +49 17 8545 0880 email and xmpp: simon at buddycloud.com From stpeter at stpeter.im Tue Nov 4 16:07:51 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 04 Nov 2008 15:07:51 -0700 Subject: [Standards] [mobile] [Fwd: Proposed XMPP Extension: Location Query] In-Reply-To: <4910C5A8.1050106@buddycloud.com> References: <4910C5A8.1050106@buddycloud.com> Message-ID: <4910C7B7.1030008@stpeter.im> Simon Tennant wrote: > Stephen Pendleton wrote: >> Very cool. >> Question for the authors: Are you really using arc-minutes as units of the >> GPS error or is that carryover from the GEOLOC XEP? > > Props should go to Helge for the spec. I guess that writing > specifications for unmanned aerial vehicles is finally paying off. > > I presume you are referring to this post: > http://mail.jabber.org/pipermail/standards/2008-October/019920.html > > Arc-minutes are a carry over. We wrote the spec with XEP-0080 in mind > and use that as the format for publishing the derived location to the > user's geoloc node too. > > We would prefer to use accuracy in meters. While arc minutes may make > sense in a GPS sense, accuracy often has to be implied when using other > location means. > > For example, if the server is receiving Cell-ID beacons and some of the > known beacons are identified as within a city an accuracy of 100m could > be implied due to a known higher tower density. Trying to apply > arc-minutes to this would probably end up just being clumsy and it would > be nice to use the same unit of measurement for accuracy. So use the new element, which measures in meters: http://xmpp.org/extensions/xep-0080.html#format Peter -- Peter Saint-Andre https://stpeter.im/ From karter.3iemnc at no-mx.jabberforum.org Wed Nov 5 07:31:41 2008 From: karter.3iemnc at no-mx.jabberforum.org (karter) Date: Wed, 5 Nov 2008 14:31:41 +0100 Subject: [Standards] FS:Htc touch diamond- 250USD, Nokia luna 8600 - 370USD, eten glofiish dx900-245USD Message-ID: Company With $1.2 billion in global sales, M MOBILES LIMITED is the world's leading provider of Electrical Electronics product and we have been selling the best quality products and services for the hospitality, and industrial markets.And we help deliver your items to your doorstep, Headquarters 313 BLACKBURN ROAD, ASTLEY BRIDGE, BOLTON, LANCASHIRE, BL1 8DY Founded M MOBILES LIMITED in 2001 Reg no 04999000 Contact details Tell :: +44 702 408 3944/ +44 702 408 3549 Global Reach Africa/Middle East Asia/Pacific Europe Latin America North America Email address:: mmobilesltd09 at hotmail.co.uk mmobilesltd09 at gmail.com mmobilesltd09 at yahoo.com All mobile phone that we supply are Original, Brand new, Sim Free with box, English user manual, std accessories and charger fitted to be used in Americas, Australia, UK, US, NZ, Europe and other part of the world. If you are currently looking for a reliable wholesale drop ship mobile phone company, kindly check out our company product prize and details below Apple iPhone 3G 16Gb Unlocked @200USD Apple iPhone 3G 8GB Unlocked @180USD Apple iPhone 8GB Unlocked @150USD Apple iPhone 16GB Unlocked @170USD NOKIA N95 8GB @ 200USD NOKIA N96 16GB @ 320USD NOKIA 8800 SAPPHIRE ARTE @ 370USD NOKIA E90 @ 220USD NOKIA LUNA 8600 @ 370USD NOKIA N85 @ 300USD NOKIA 8800 CARBON ARTE @ 380USD NOKIA 7210 SUPERNOVA @ 240USD BLACKBERRY BOLD 9000 @ 300USD BLACKBERRY CURVE @ 220USD BLACKBERRY STORM @ 290USD BLACKBERRY THUNDER @ 300USD HTC TOUCH CRUISE @ 200USD HTC TOUCH DIANMOND @ 250USD HTC TOUCH PRO @ 300USD HTC SHIFT 60GB @ 250USD HTC ADVANTAGE @ 300USD HTC G1 UNLOCKED @ 350USD SAMSUNG SGH-i900 OMNIA @ 320USD SAMSUNG INNOV8 @ 300USD SAMSUNG M8800 PIXON @ 310USD ETEN glofiish X610 @250 ETEN glofiish V900 @285 ETEN glofiish X900 @250 ETEN glofiish DX900 @245 Sony Ericsson XPERIA X1 @ 265USD Sony Ericsson W950i @ 220uad Sony Ericsson W880i Walkman Phone @ 210USD Sony Ericsson W850i @ 200USD Sony Ericsson W810i Walkman Phone @ 120USD Sony Ericsson W660i @ 150USD Sony Ericsson M600i @ 220USD Order your items via our email below and get them within 2days, Email address:: mmobilesltd09 at hotmail.co.uk mmobilesltd09 at gmail.com mmobilesltd09 at yahoo.com For more information regarding purchase, kindly contact me at mmobilesltd09 at hotmail.co.uk, I look forward in placing your order with us and giving you the most competent services as we are using this medium to look for buyers of various electronics product we stock. We are committed to doing all it takes to keep you a satisfied customer! Many thanks and God bless you as you place your order with us today. Your inquiry will be greatly appreciated. Mr Anthony Marcus Sales Management M MOBILES LIMITED Tell :: +44 702 408 3944 / +44 702 408 3549 -- karter ------------------------------------------------------------------------ karter's Profile: http://www.jabberforum.org/member.php?userid=17316 View this thread: http://www.jabberforum.org/showthread.php?t=1037 From js-xmpp-standards at webkeks.org Wed Nov 5 09:47:47 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Wed, 5 Nov 2008 16:47:47 +0100 Subject: [Standards] FS:Htc touch diamond- 250USD, Nokia luna 8600 - 370USD, eten glofiish dx900-245USD In-Reply-To: References: Message-ID: <2E91B052-310F-427F-9883-69DF57DE9878@webkeks.org> Ok, so thanks to Jabber Forum, we also get spam on the MLs now, even though they only allow mails from subscribers? Now we got a problem: If I give this mail to my spamfilter, it will very soon think all messages from Jabber Forum are spam? Great! -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081105/6f4cd8e9/attachment.pgp From stpeter at stpeter.im Wed Nov 5 09:51:58 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 05 Nov 2008 08:51:58 -0700 Subject: [Standards] FS:Htc touch diamond- 250USD, Nokia luna 8600 - 370USD, eten glofiish dx900-245USD In-Reply-To: <2E91B052-310F-427F-9883-69DF57DE9878@webkeks.org> References: <2E91B052-310F-427F-9883-69DF57DE9878@webkeks.org> Message-ID: <4911C11E.8070109@stpeter.im> Jonathan Schleifer wrote: > Ok, so thanks to Jabber Forum, we also get spam on the MLs now, even > though they only allow mails from subscribers? > > Now we got a problem: If I give this mail to my spamfilter, it will very > soon think all messages from Jabber Forum are spam? Great! The process is that we report the violation to the administrator of JabberForum and he blacklists that user. Which I'm doing by cc'ing him on this message. Peter -- Peter Saint-Andre https://stpeter.im/ From js-xmpp-standards at webkeks.org Wed Nov 5 09:59:39 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Wed, 5 Nov 2008 16:59:39 +0100 Subject: [Standards] FS:Htc touch diamond- 250USD, Nokia luna 8600 - 370USD, eten glofiish dx900-245USD In-Reply-To: <4911C11E.8070109@stpeter.im> References: <2E91B052-310F-427F-9883-69DF57DE9878@webkeks.org> <4911C11E.8070109@stpeter.im> Message-ID: Am 05.11.2008 um 16:51 schrieb Peter Saint-Andre: > The process is that we report the violation to the administrator of > JabberForum and he blacklists that user. Which I'm doing by cc'ing him > on this message. That won't help. That spam mail means that the captcha - if there was any - has been broken and a lot more will come soon. Basically, it means everyone can post to the ML now as long as the captcha isn't fixed. PS: Your client seems to break UTF-8 when quoting mails? I think I remember that worked once for you :). -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081105/3397a50d/attachment.pgp From stpeter at stpeter.im Wed Nov 5 10:06:13 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 05 Nov 2008 09:06:13 -0700 Subject: [Standards] OT: messages from JabberForum In-Reply-To: References: <2E91B052-310F-427F-9883-69DF57DE9878@webkeks.org> <4911C11E.8070109@stpeter.im> Message-ID: <4911C475.9020905@stpeter.im> I've changed the subject to reflect the fact that this is off-topic administrivia. Jonathan Schleifer wrote: > Am 05.11.2008 um 16:51 schrieb Peter Saint-Andre: > >> The process is that we report the violation to the administrator of >> JabberForum and he blacklists that user. Which I'm doing by cc'ing him >> on this message. > > > That won't help. That spam mail means that the captcha - if there was > any - has been broken and a lot more will come soon. Basically, it means > everyone can post to the ML now as long as the captcha isn't fixed. Why do you assume the CAPTCHA has been broken? In fact we have received spam to the lists before from JabberForum, but perhaps only one message a month or so. The current process has worked fine. If that is no longer the case, we'll change the process. > PS: Your client seems to break UTF-8 when quoting mails? I think I > remember that worked once for you :). I send and receive as UTF-8 (and convert incoming mail to UTF-8), but I admit that email encoding seems to not always work (and I don't know why). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter at stpeter.im Wed Nov 5 10:21:00 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 05 Nov 2008 09:21:00 -0700 Subject: [Standards] administrivia: reporting spam Message-ID: <4911C7EC.2010003@stpeter.im> If you see spam posted from JabberForum to this list or to any other jabber.org/xmpp.org mailing list, please report it to to Florian Jensen via . However, Florian monitors the lists at jabber.org/xmpp.org and typically will disable the offending user and delete the message or discussion thread quite quickly. If you see spam posted via email or Gmane (not via JabberForum), please report it to me via . The same provisos apply (I monitor the lists and disable/delete users within a few hours, unless I'm sleeping or travelling at the time). Peter -- Peter Saint-Andre https://stpeter.im/ From js-xmpp-standards at webkeks.org Wed Nov 5 11:39:27 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Wed, 5 Nov 2008 18:39:27 +0100 Subject: [Standards] OT: messages from JabberForum In-Reply-To: <4911C475.9020905@stpeter.im> References: <2E91B052-310F-427F-9883-69DF57DE9878@webkeks.org> <4911C11E.8070109@stpeter.im> <4911C475.9020905@stpeter.im> Message-ID: <79E0D2BE-D6C7-4FC0-9D72-268645332E7E@webkeks.org> Am 05.11.2008 um 17:06 schrieb Peter Saint-Andre: > Why do you assume the CAPTCHA has been broken? A spam user registered at the forum - most likely, a bot, googling for vulnerable versions of the forum software. It then registers itself and spams. I guess this is what happened - so the captcha at the registration seems to be broken. > In fact we have received > spam to the lists before from JabberForum, but perhaps only one > message > a month or so. The current process has worked fine. If that is no > longer > the case, we'll change the process. This is the first time me getting spam from an XMPP list. :) > I send and receive as UTF-8 (and convert incoming mail to UTF-8), > but I > admit that email encoding seems to not always work (and I don't know > why). We should debug that off-list. Feel free to mail me some UTF-8 chars :). -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081105/b8ea654d/attachment.pgp From editor at xmpp.org Wed Nov 5 11:41:50 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Wed, 05 Nov 2008 11:41:50 -0600 Subject: [Standards] UPDATED: XEP-0226 (Message Stanza Profiles) Message-ID: Version 0.3 of XEP-0226 (Message Stanza Profiles) has been released. Abstract: This document specifies best practices for generating and handling extended content in XMPP message stanzas. Changelog: For consistency, defined Metadata Profile; specified that the registrar shall create a registry for message stanza profiles. (psa) Diff: http://is.gd/6pZr URL: http://www.xmpp.org/extensions/xep-0226.html From waqas20 at gmail.com Wed Nov 5 15:19:14 2008 From: waqas20 at gmail.com (Waqas) Date: Thu, 6 Nov 2008 02:19:14 +0500 Subject: [Standards] Errata, and some suggestions to various specs Message-ID: <7fc4fa880811051319u7e425d1ar14d85bdc1de959c7@mail.gmail.com> A file I have been adding to while recently going over the specs with an implementor's point of view: ===== Start errata.txt ===== http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#substates-out-unsubscribe (XMPP-IM) | "To + Pending In" | MUST | "Pending In" | should be | "To + Pending In" | MUST | "None + Pending In" | --- http://xmpp.org/extensions/xep-0049.html (Private XML Storage) The XEP doesn't specify what to do when a user requests non-existing private data. Servers seem to return the stanza as is, and no error. This should be explicitly specified. It would also be useful for there to be a way for the client to ask the server to list all data stored for that client. I'm for example interested in learning what my various clients might have stored over the years. Doing that when the client has not sent a child for the query element would be a simple and backwards compatible way to do it. --- http://xmpp.org/extensions/xep-0049.html#example-3 (Private XML Storage) Since the preceding text states: "the server MUST return a "Forbidden" or "Service Unavailable" error to the sender (the latter condition is in common use by existing implementations, although the former is preferable)." the example should preferably use a "Forbidden" error. --- http://xmpp.org/extensions/xep-0049.html#example-4 (Private XML Storage) Since the preceding test states "the server SHOULD return a "Bad Format" error", therefore, the example SHOULD use a "Bad Format" error. --- http://xmpp.org/extensions/xep-0228.html#intro (Requirements for Shared Editing) "have been developed usign XMPP" should be "have been developed using XMPP" --- http://xmpp.org/extensions/xep-0045.html#invite-direct (Multi-User Chat) "A method for sending a direct invitation (not mediated by the room itself) is defined in another specification." Saying "another specification" is rather vague. I have no idea which other specification is being referred to. ===== End errata.txt ===== Hopefully this was the Right Way to post these. I was wondering if I should have posted these separately, particularly the part about XEP-0049. -- Waqas Hussain From kevin at kismith.co.uk Wed Nov 5 15:40:43 2008 From: kevin at kismith.co.uk (Kevin Smith) Date: Wed, 5 Nov 2008 21:40:43 +0000 Subject: [Standards] Errata, and some suggestions to various specs In-Reply-To: <7fc4fa880811051319u7e425d1ar14d85bdc1de959c7@mail.gmail.com> References: <7fc4fa880811051319u7e425d1ar14d85bdc1de959c7@mail.gmail.com> Message-ID: On Wed, Nov 5, 2008 at 9:19 PM, Waqas wrote: > Hopefully this was the Right Way to post these. I was wondering if I > should have posted these separately, particularly the part about > XEP-0049. I think posting them at all was most welcome - Peter may have views on the most efficient way, but feedback is good from people actually reading the specs :) /K From stpeter at stpeter.im Wed Nov 5 16:00:35 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 05 Nov 2008 15:00:35 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] Message-ID: <49121783.5050002@stpeter.im> FYI. -------- Original Message -------- Date: Wed, 05 Nov 2008 14:58:44 -0700 From: Peter Saint-Andre To: XMPP Council Subject: [Council] meeting minutes, 2008-11-05 Results of the XMPP Council meeting held 2008-11-05... Agenda: http://xmpp.org/council/agendas/2008-11-05.html Log: http://logs.jabber.org/council at conference.jabber.org/2008-11-05.html Scribe: Peter Saint-Andre 0. Roll call Present: Dave Cridland, Ralph Meijer, Jack Moffitt, Peter Saint-Andre, Kevin Smith. Quorum achieved. 1. Agenda bashing None. 2. XEP-0174: Serverless Messaging Proposed action: Approve version 1.3rc2? Changelog: Corrected TXT record format in conformance with draft-cheshire-dnsext-dns-sd; clarified a number of issues related to DNS-SD and Multicast DNS; as an optimization, recommended sending of disco#info data in stream features; removed reference to Encrypted Sessions specification from the security considerations. Discussion: Dave raised some questions about the TXT record data format. Peter to ping the DNS-SD authors, Dave and Ralph to do some testing of real-world deployments. 3. XEP-0084: User Avatar Proposed action: Approve version 1.1rc1? Changelog: For consistency with other PEP payload formats, changed stop semantics to use an empty element rather than a child element. All Council members voted +1 in the meeting, Peter to publish updated version. 4. Other business 4a. XEP-0012 and XEP-0085 Calls for experience ended 2008-10-31. Peter to send brief "report" messages to the standards@ list regarding the calls for experience. 4b. XEP-0220 and XEP-0224 Reminder that Last Calls end 2008-11-07. Peter to ping several people for feedback on XEP-0220 (Server Dialback), and to post to the standards@ list regarding feedback he received offlist. 4c. XSF Member involvement Somewhat lengthy discussion regarding ways to involve XSF members (and others) in the standardization process, for example by soliciting expert reviews or establishing review teams. To be discussed further at the next meeting. 5. Next meeting 2008-11-12 @ 21:00 UTC. /psa From editor at xmpp.org Wed Nov 5 16:05:27 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Wed, 05 Nov 2008 16:05:27 -0600 Subject: [Standards] UPDATED: XEP-0084 (User Avatar) Message-ID: Version 1.1 of XEP-0084 (User Avatar) has been released. Abstract: This document defines an XMPP protocol extension for exchanging user avatars, which are small images or icons associated with human users. The protocol specifies payload formats for both avatar metadata and the image data itself. The payload formats are typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163. Changelog: For consistency with other PEP payload formats, changed stop semantics to use an empty element rather than a child element. (psa) Diff: http://is.gd/6rg9 URL: http://www.xmpp.org/extensions/xep-0084.html From waqas20 at gmail.com Wed Nov 5 21:42:34 2008 From: waqas20 at gmail.com (Waqas Hussain) Date: Thu, 6 Nov 2008 08:42:34 +0500 Subject: [Standards] Entity errors (errata) Message-ID: <7fc4fa880811051942m5089a038ta078fcaf007724d8@mail.gmail.com> I saw an entity error in draft-saintandre-rfc3921bis-08. I then ran an entity checking script on the internet-drafts and extensions (the XML files in subversion repository), and here is what I found (format: file line_number offending_string): Entity errors resulting in malformed XML: internet-drafts/draft-saintandre-rfc3920bis-09.xml 6035 <l; internet-drafts/draft-saintandre-rfc3921bis-08.xml 1289 ≫ internet-drafts/draft-saintandre-xmpp-feature-set-00.xml 287 > or < Entity/etc errors within examples (inside CDATA sections): internet-drafts/draft-saintandre-rfc3921bis-08.xml 1626 ím! internet-drafts/draft-saintandre-rfc3921bis-08.xml 1652 ím! extensions/xep-0235.xml 176 &travelbot%40findmenow.tld%2Fbot%26feeds.worldgps.tld&\ (the CDATA section for the last one has most instances of '&' encoded as '%26', but these 2 are not) extensions/xep-0204.xml 465 &jep0030; (that's within a comment, but the whole comment should be replaced with &xep0030;) I'm curious about why the XSL processor used to convert the XML to HTML doesn't break on the malformed XML. -- Waqas Hussain From justin-keyword-jabber.093179 at affinix.com Thu Nov 6 20:39:12 2008 From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges) Date: Thu, 6 Nov 2008 18:39:12 -0800 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <49121783.5050002@stpeter.im> References: <49121783.5050002@stpeter.im> Message-ID: <200811061839.12639.justin-keyword-jabber.093179@affinix.com> On Wednesday 05 November 2008 14:00:35 Peter Saint-Andre wrote: > Discussion: Dave raised some questions about the TXT record data format. > Peter to ping the DNS-SD authors, Dave and Ralph to do some testing of > real-world deployments. Kev fails for not contacting me about this. The dig output is pretty and doesn't include the length byte which is indeed in the record data. The question is really about XEP-174's usage of that "text-based DNS record description notation" (for lack of a better name) in the context of representing multiple strings, and not about the actual TXT raw byte format of which there is no dispute. I'm not sure if there's an authoritative source for that text-based DNS record description notation (other than RFC 1035, which is quite sketchy), but information about SPF reveals the use of multiple strings in one line. E.g.: example.com. 4500 IN TXT "string1" "string2" "string3" Indeed, sending dig at a TXT record containing multiple strings prints the result exactly this way. You can dig iChat like this: dig @ip_address_of_ichat -p 5353 -t txt user at host._presence._tcp.local So, I think the right answer is to put all strings on one line. From what I can tell, the DNS-SD spec dodges this topic by not using the notation at all, which is not a bad approach either. :) It's not like anyone implementing XEP-174 will be parsing this format. -Justin From stpeter at stpeter.im Thu Nov 6 22:38:01 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 06 Nov 2008 21:38:01 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <200811061839.12639.justin-keyword-jabber.093179@affinix.com> References: <49121783.5050002@stpeter.im> <200811061839.12639.justin-keyword-jabber.093179@affinix.com> Message-ID: <4913C629.1000403@stpeter.im> Justin Karneges wrote: > On Wednesday 05 November 2008 14:00:35 Peter Saint-Andre wrote: >> Discussion: Dave raised some questions about the TXT record data format. >> Peter to ping the DNS-SD authors, Dave and Ralph to do some testing of >> real-world deployments. > > Kev fails for not contacting me about this. The dig output is pretty and > doesn't include the length byte which is indeed in the record data. The > question is really about XEP-174's usage of that "text-based DNS record > description notation" (for lack of a better name) in the context of > representing multiple strings, and not about the actual TXT raw byte format > of which there is no dispute. > > I'm not sure if there's an authoritative source for that text-based DNS record > description notation (other than RFC 1035, which is quite sketchy), but > information about SPF reveals the use of multiple strings in one line. E.g.: > > example.com. 4500 IN TXT "string1" "string2" "string3" > > Indeed, sending dig at a TXT record containing multiple strings prints the > result exactly this way. You can dig iChat like this: > > dig @ip_address_of_ichat -p 5353 -t txt user at host._presence._tcp.local > > So, I think the right answer is to put all strings on one line. > > From what I can tell, the DNS-SD spec dodges this topic by not using the > notation at all, which is not a bad approach either. :) It's not like anyone > implementing XEP-174 will be parsing this format. Yes, I noticed that output in dig, too. Then I tried to watch it using tcpdump ('tcpdump -x -X -s 5000 -l -vvv host roundabout.local' in my case): 16:28:12.408064 IP6 (hlim 255, next-header: UDP (17), length: 331) roundabout.local.mdns > ff02::fb.mdns: [udp sum ok] 0*- [0q] 4/0/2 stpeter at roundabout._presence._tcp.local. (Cache flush) SRV roundabout.local.:53589 0 0, stpeter at roundabout._presence._tcp.local. (Cache flush) TXT "txtvers=1" "port.p2pj=53589" "status=avail" "1st=Peter" "email=stpeter at stpeter.im" "jid=stpeter at stpeter.im" "last=Saint-Andre" "vc=SDCURA!XN" "ext=5I", _services._dns-sd._udp.local. PTR _presence._tcp.local., _presence._tcp.local. PTR stpeter at roundabout._presence._tcp.local. ar: roundabout.local. (Cache flush) AAAA roundabout.local, roundabout.local. (Cache flush) A my.domain.com (323) 0x0000: 6000 0000 014b 11ff fe80 0000 0000 0000 `....K.......... 0x0010: 020d 93ff fe2c 5c18 ff02 0000 0000 0000 .....,\......... 0x0020: 0000 0000 0000 00fb 14e9 14e9 014b eba5 .............K.. 0x0030: 0000 8400 0000 0004 0000 0002 1273 7470 .............stp 0x0040: 6574 6572 4072 6f75 6e64 6162 6f75 7409 eter at roundabout. 0x0050: 5f70 7265 7365 6e63 6504 5f74 6370 056c _presence._tcp.l 0x0060: 6f63 616c 0000 2180 0100 0000 7800 1300 ocal..!.....x... 0x0070: 0000 00d1 550a 726f 756e 6461 626f 7574 ....U.roundabout 0x0080: c02e c00c 0010 8001 0000 1194 0086 0974 ...............t 0x0090: 7874 7665 7273 3d31 0f70 6f72 742e 7032 xtvers=1.port.p2 0x00a0: 706a 3d35 3335 3839 0c73 7461 7475 733d pj=53589.status= 0x00b0: 6176 6169 6c09 3173 743d 5065 7465 7218 avail.1st=Peter. 0x00c0: 656d 6169 6c3d 7374 7065 7465 7240 7374 email=stpeter at st 0x00d0: 7065 7465 722e 696d 166a 6964 3d73 7470 peter.im.jid=stp 0x00e0: 6574 6572 4073 7470 6574 6572 2e69 6d10 eter at stpeter.im. 0x00f0: 6c61 7374 3d53 6169 6e74 2d41 6e64 7265 last=Saint-Andre 0x0100: 0c76 633d 5344 4355 5241 2158 4e06 6578 .vc=SDCURA!XN.ex 0x0110: 743d 3549 095f 7365 7276 6963 6573 075f t=5I._services._ 0x0120: 646e 732d 7364 045f 7564 70c0 2e00 0c00 dns-sd._udp..... 0x0130: 0100 0011 9400 02c0 1fc0 1f00 0c00 0100 ................ 0x0140: 0011 9400 02c0 0cc0 4500 1c80 0100 0000 ........E....... 0x0150: 7800 10fe 8000 0000 0000 0002 0d93 fffe x............... 0x0160: 2c5c 18c0 4500 0180 0100 0000 7800 040a ,\..E.......x... 0x0170: 0201 e1 I'm not sure what to conclude from that... /psa From stpeter at stpeter.im Thu Nov 6 22:52:32 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 06 Nov 2008 21:52:32 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <4913C629.1000403@stpeter.im> References: <49121783.5050002@stpeter.im> <200811061839.12639.justin-keyword-jabber.093179@affinix.com> <4913C629.1000403@stpeter.im> Message-ID: <4913C990.3090807@stpeter.im> Peter Saint-Andre wrote: > Justin Karneges wrote: >> On Wednesday 05 November 2008 14:00:35 Peter Saint-Andre wrote: >>> Discussion: Dave raised some questions about the TXT record data format. >>> Peter to ping the DNS-SD authors, Dave and Ralph to do some testing of >>> real-world deployments. >> Kev fails for not contacting me about this. The dig output is pretty and >> doesn't include the length byte which is indeed in the record data. The >> question is really about XEP-174's usage of that "text-based DNS record >> description notation" (for lack of a better name) in the context of >> representing multiple strings, and not about the actual TXT raw byte format >> of which there is no dispute. >> >> I'm not sure if there's an authoritative source for that text-based DNS record >> description notation (other than RFC 1035, which is quite sketchy), but >> information about SPF reveals the use of multiple strings in one line. E.g.: >> >> example.com. 4500 IN TXT "string1" "string2" "string3" >> >> Indeed, sending dig at a TXT record containing multiple strings prints the >> result exactly this way. You can dig iChat like this: >> >> dig @ip_address_of_ichat -p 5353 -t txt user at host._presence._tcp.local >> >> So, I think the right answer is to put all strings on one line. >> >> From what I can tell, the DNS-SD spec dodges this topic by not using the >> notation at all, which is not a bad approach either. :) It's not like anyone >> implementing XEP-174 will be parsing this format. > > Yes, I noticed that output in dig, too. Then I tried to watch it using > tcpdump ('tcpdump -x -X -s 5000 -l -vvv host roundabout.local' in my case): > > 16:28:12.408064 IP6 (hlim 255, next-header: UDP (17), length: 331) > roundabout.local.mdns > ff02::fb.mdns: [udp sum ok] 0*- [0q] 4/0/2 > stpeter at roundabout._presence._tcp.local. (Cache flush) SRV > roundabout.local.:53589 0 0, stpeter at roundabout._presence._tcp.local. > (Cache flush) TXT "txtvers=1" "port.p2pj=53589" "status=avail" > "1st=Peter" "email=stpeter at stpeter.im" "jid=stpeter at stpeter.im" > "last=Saint-Andre" "vc=SDCURA!XN" "ext=5I", > _services._dns-sd._udp.local. PTR _presence._tcp.local., > _presence._tcp.local. PTR stpeter at roundabout._presence._tcp.local. ar: > roundabout.local. (Cache flush) AAAA roundabout.local, roundabout.local. > (Cache flush) A my.domain.com (323) > > 0x0000: 6000 0000 014b 11ff fe80 0000 0000 0000 `....K.......... > 0x0010: 020d 93ff fe2c 5c18 ff02 0000 0000 0000 .....,\......... > 0x0020: 0000 0000 0000 00fb 14e9 14e9 014b eba5 .............K.. > 0x0030: 0000 8400 0000 0004 0000 0002 1273 7470 .............stp > 0x0040: 6574 6572 4072 6f75 6e64 6162 6f75 7409 eter at roundabout. > 0x0050: 5f70 7265 7365 6e63 6504 5f74 6370 056c _presence._tcp.l > 0x0060: 6f63 616c 0000 2180 0100 0000 7800 1300 ocal..!.....x... > 0x0070: 0000 00d1 550a 726f 756e 6461 626f 7574 ....U.roundabout > 0x0080: c02e c00c 0010 8001 0000 1194 0086 0974 ...............t > 0x0090: 7874 7665 7273 3d31 0f70 6f72 742e 7032 xtvers=1.port.p2 > 0x00a0: 706a 3d35 3335 3839 0c73 7461 7475 733d pj=53589.status= > 0x00b0: 6176 6169 6c09 3173 743d 5065 7465 7218 avail.1st=Peter. > 0x00c0: 656d 6169 6c3d 7374 7065 7465 7240 7374 email=stpeter at st > 0x00d0: 7065 7465 722e 696d 166a 6964 3d73 7470 peter.im.jid=stp > 0x00e0: 6574 6572 4073 7470 6574 6572 2e69 6d10 eter at stpeter.im. > 0x00f0: 6c61 7374 3d53 6169 6e74 2d41 6e64 7265 last=Saint-Andre > 0x0100: 0c76 633d 5344 4355 5241 2158 4e06 6578 .vc=SDCURA!XN.ex > 0x0110: 743d 3549 095f 7365 7276 6963 6573 075f t=5I._services._ > 0x0120: 646e 732d 7364 045f 7564 70c0 2e00 0c00 dns-sd._udp..... > 0x0130: 0100 0011 9400 02c0 1fc0 1f00 0c00 0100 ................ > 0x0140: 0011 9400 02c0 0cc0 4500 1c80 0100 0000 ........E....... > 0x0150: 7800 10fe 8000 0000 0000 0002 0d93 fffe x............... > 0x0160: 2c5c 18c0 4500 0180 0100 0000 7800 040a ,\..E.......x... > 0x0170: 0201 e1 > > I'm not sure what to conclude from that... Never mind. It does seem that the single byte length indicators are included on the wire. So for instance the key-value pair txtvers=1 is preceded by hex 09 (length 9), the pair status=avail is preceded by hex 0c (length 12), the pair email=stpeter at stpeter.im is preceded by hex 18 (length 24), and so on. /psa From justin-keyword-jabber.093179 at affinix.com Fri Nov 7 00:00:40 2008 From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges) Date: Thu, 6 Nov 2008 22:00:40 -0800 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <4913C990.3090807@stpeter.im> References: <49121783.5050002@stpeter.im> <4913C629.1000403@stpeter.im> <4913C990.3090807@stpeter.im> Message-ID: <200811062200.40830.justin-keyword-jabber.093179@affinix.com> On Thursday 06 November 2008 20:52:32 Peter Saint-Andre wrote: > It does seem that the single byte length indicators are included on the > wire. Yep. The confusion is really just around that text-based notation. It's easy to get tricked into thinking that the rightmost field represents the raw bytes of the record, but it isn't anything of the sort. For example, an A record's value is written as an IPv4 address in string format, but it is encoded on the wire as a 4-byte integer. SRV has four fields, three of which are numbers (packed as 2-byte integers) and one that's a hostname (also not encoded in straight string format, but rather the in DNS label format). TXT is a series of strings, which, not surprisingly, also ends up encoded in some special way. -Justin From brettz9 at yahoo.com Fri Nov 7 00:32:45 2008 From: brettz9 at yahoo.com (Brett Zamir) Date: Fri, 07 Nov 2008 14:32:45 +0800 Subject: [Standards] Pubsub collection nodes Message-ID: <4913E10D.4030809@yahoo.com> In Examples 11-13, and 15, 16 (and 14 if you meant to have the original XML there too) of http://xmpp.org/extensions/xep-0248.html , there is no , whereas the other examples with a child in have it. If it is not to be there, when is it and when is it not needed? thanks, Brett From helge at buddycloud.com Fri Nov 7 04:54:57 2008 From: helge at buddycloud.com (Helge Timenes) Date: Fri, 7 Nov 2008 11:54:57 +0100 Subject: [Standards] [mobile] [Fwd: Proposed XMPP Extension: Location Query] Message-ID: <55157bd0298da96d644794bcd847c1ee@127.0.0.1> Peter Saint-Andre wrote: >Simon Tennant wrote: >> Stephen Pendleton wrote: >>> Very cool. >>> Question for the authors: Are you really using arc-minutes as units of the >>> GPS error or is that carryover from the GEOLOC XEP? >> >> Props should go to Helge for the spec. I guess that writing >> specifications for unmanned aerial vehicles is finally paying off. >> >> I presume you are referring to this post: >> http://mail.jabber.org/pipermail/standards/2008-October/019920.html >> >> Arc-minutes are a carry over. We wrote the spec with XEP-0080 in mind >> and use that as the format for publishing the derived location to the >> user's geoloc node too. >> >> We would prefer to use accuracy in meters. While arc minutes may make >> sense in a GPS sense, accuracy often has to be implied when using other >> location means. >> >> For example, if the server is receiving Cell-ID beacons and some of the >> known beacons are identified as within a city an accuracy of 100m could >> be implied due to a known higher tower density. Trying to apply >> arc-minutes to this would probably end up just being clumsy and it would >> be nice to use the same unit of measurement for accuracy. > >So use the new element, which measures in meters: > >http://xmpp.org/extensions/xep-0080.html#format Sorry for the slow response to this, got bogged down with some home improvement work (no worries, still have all my fingers :-) I will update to use the element, and the world will be a better place. Helge From stpeter at stpeter.im Fri Nov 7 10:34:07 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 07 Nov 2008 09:34:07 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <200811062200.40830.justin-keyword-jabber.093179@affinix.com> References: <49121783.5050002@stpeter.im> <4913C629.1000403@stpeter.im> <4913C990.3090807@stpeter.im> <200811062200.40830.justin-keyword-jabber.093179@affinix.com> Message-ID: <49146DFF.1050400@stpeter.im> Justin Karneges wrote: > On Thursday 06 November 2008 20:52:32 Peter Saint-Andre wrote: >> It does seem that the single byte length indicators are included on the >> wire. > > Yep. The confusion is really just around that text-based notation. It's easy > to get tricked into thinking that the rightmost field represents the raw > bytes of the record, but it isn't anything of the sort. > > For example, an A record's value is written as an IPv4 address in string > format, but it is encoded on the wire as a 4-byte integer. SRV has four > fields, three of which are numbers (packed as 2-byte integers) and one that's > a hostname (also not encoded in straight string format, but rather the in DNS > label format). TXT is a series of strings, which, not surprisingly, also > ends up encoded in some special way. Right, so the question is not "what format is sent over the wire?" (as we can see that's the fancy encoding to save space and indicate the length of each key-value pair) but "what is the format that an entity publishes to the mdns address?" (and that might be a text-based notation with each key-value pair contained within quotes). In any case, I think that what's currently in XEP-0174 is wrong because you don't publish one TXT record for each key-value pair, instead you publish a single TXT record that contains all of the key-value pairs. So that means you publish something like this (it would be all one "line" in DNS but I can't show that in email): juliet at pronto._presence._tcp.local. IN TXT "txtvers=1" "1st=Juliet" "email=juliet at capulet.lit" "hash=sha-1" "jid=juliet at capulet.lit" "last=Capulet" "msg=Hanging out downtown" "nick=JuliC" "node=http://www.adiumx.com" "phsh=a3839614e1a382bcfebbcf20464f519e81770813" "port.p2pj=5562" "status=avail" "vc=CA!" "ver=QgayPKawpkPSDYmwT/WM94uAlu0=" Yes, no, maybe? Peter -- Peter Saint-Andre https://stpeter.im/ From justin-keyword-jabber.093179 at affinix.com Fri Nov 7 11:13:29 2008 From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges) Date: Fri, 7 Nov 2008 09:13:29 -0800 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <49146DFF.1050400@stpeter.im> References: <49121783.5050002@stpeter.im> <200811062200.40830.justin-keyword-jabber.093179@affinix.com> <49146DFF.1050400@stpeter.im> Message-ID: <200811070913.30007.justin-keyword-jabber.093179@affinix.com> On Friday 07 November 2008 08:34:07 Peter Saint-Andre wrote: > Right, so the question is not "what format is sent over the wire?" (as > we can see that's the fancy encoding to save space and indicate the > length of each key-value pair) but "what is the format that an entity > publishes to the mdns address?" (and that might be a text-based notation > with each key-value pair contained within quotes). In any case, I think > that what's currently in XEP-0174 is wrong because you don't publish one > TXT record for each key-value pair, instead you publish a single TXT > record that contains all of the key-value pairs. Correct. A single TXT record contains all the strings. > So that means you publish something like this (it would be all one "line" > in DNS but I can't show that in email): > > juliet at pronto._presence._tcp.local. IN TXT "txtvers=1" "1st=Juliet" > "email=juliet at capulet.lit" "hash=sha-1" "jid=juliet at capulet.lit" > "last=Capulet" "msg=Hanging out downtown" "nick=JuliC" > "node=http://www.adiumx.com" > "phsh=a3839614e1a382bcfebbcf20464f519e81770813" "port.p2pj=5562" > "status=avail" "vc=CA!" "ver=QgayPKawpkPSDYmwT/WM94uAlu0=" > > Yes, no, maybe? Yes. -Justin From stpeter at stpeter.im Fri Nov 7 12:05:06 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 07 Nov 2008 11:05:06 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <200811070913.30007.justin-keyword-jabber.093179@affinix.com> References: <49121783.5050002@stpeter.im> <200811062200.40830.justin-keyword-jabber.093179@affinix.com> <49146DFF.1050400@stpeter.im> <200811070913.30007.justin-keyword-jabber.093179@affinix.com> Message-ID: <49148352.3090008@stpeter.im> Justin Karneges wrote: > On Friday 07 November 2008 08:34:07 Peter Saint-Andre wrote: >> Right, so the question is not "what format is sent over the wire?" (as >> we can see that's the fancy encoding to save space and indicate the >> length of each key-value pair) but "what is the format that an entity >> publishes to the mdns address?" (and that might be a text-based notation >> with each key-value pair contained within quotes). In any case, I think >> that what's currently in XEP-0174 is wrong because you don't publish one >> TXT record for each key-value pair, instead you publish a single TXT >> record that contains all of the key-value pairs. > > Correct. A single TXT record contains all the strings. > >> So that means you publish something like this (it would be all one "line" >> in DNS but I can't show that in email): >> >> juliet at pronto._presence._tcp.local. IN TXT "txtvers=1" "1st=Juliet" >> "email=juliet at capulet.lit" "hash=sha-1" "jid=juliet at capulet.lit" >> "last=Capulet" "msg=Hanging out downtown" "nick=JuliC" >> "node=http://www.adiumx.com" >> "phsh=a3839614e1a382bcfebbcf20464f519e81770813" "port.p2pj=5562" >> "status=avail" "vc=CA!" "ver=QgayPKawpkPSDYmwT/WM94uAlu0=" >> >> Yes, no, maybe? > > Yes. Right. I will confirm this understanding with the DNS-SD experts and then modify the XEP accordingly. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter at stpeter.im Fri Nov 7 17:46:37 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 07 Nov 2008 16:46:37 -0700 Subject: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks) In-Reply-To: References: Message-ID: <4914D35D.2010507@stpeter.im> This Last Call has ended, with no feedback received. XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0205 (Best Practices to Discourage Denial of Service Attacks). > > Abstract: This document recommends a number of practices that can > help discourage denial of service attacks on XMPP-based networks. > > URL: http://www.xmpp.org/extensions/xep-0205.html > > This Last Call begins today and shall end at the close of business on > 2008-11-07. > > Please consider the following questions during this Last Call and > send your feedback to the standards at xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? 2. Does the specification > solve the problem stated in the introduction and requirements? 3. Do > you plan to implement this specification in your code? If not, why > not? 4. Do you have any security concerns related to this > specification? 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! From stpeter at stpeter.im Fri Nov 7 17:46:58 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 07 Nov 2008 16:46:58 -0700 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: References: Message-ID: <4914D372.50506@stpeter.im> This Last Call has ended, with no feedback received. XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0224 (Attention). > > Abstract: This document defines an XMPP protocol extension for > getting the attention of another user. > > URL: http://www.xmpp.org/extensions/xep-0224.html > > This Last Call begins today and shall end at the close of business on > 2008-11-07. > > Please consider the following questions during this Last Call and > send your feedback to the standards at xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? 2. Does the specification > solve the problem stated in the introduction and requirements? 3. Do > you plan to implement this specification in your code? If not, why > not? 4. Do you have any security concerns related to this > specification? 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! From stpeter at stpeter.im Fri Nov 7 17:47:48 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 07 Nov 2008 16:47:48 -0700 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: References: Message-ID: <4914D3A4.3030405@stpeter.im> This Last Call has ended. I received some feedback off-list, which I will consolidate and post to the list next week. XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0220 (Server Dialback). > > Abstract: This specification defines the Server Dialback protocol, > which is used between XMPP servers to provide identity verification. > Server Dialback uses the Domain Name System (DNS) as the basis for > verifying identity; the basic approach is that when a receiving > server receives a server-to-server connection request from an > originating server, it does not accept the request until it has > verified a key with an authoritative server for the domain asserted > by the originating server. Although Server Dialback does not provide > strong authentication or trusted federation and although it is > subject to DNS poisoning attacks, it has effectively prevented most > instances of address spoofing on the XMPP network since its > development in the year 2000. > > URL: http://www.xmpp.org/extensions/xep-0220.html > > This Last Call begins today and shall end at the close of business on > 2008-11-07. > > Please consider the following questions during this Last Call and > send your feedback to the standards at xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? 2. Does the specification > solve the problem stated in the introduction and requirements? 3. Do > you plan to implement this specification in your code? If not, why > not? 4. Do you have any security concerns related to this > specification? 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! From alexey.melnikov at isode.com Sat Nov 8 09:41:37 2008 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Sat, 08 Nov 2008 15:41:37 +0000 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <4914D372.50506@stpeter.im> References: <4914D372.50506@stpeter.im> Message-ID: <4915B331.60000@isode.com> Peter Saint-Andre wrote: >This Last Call has ended, with no feedback received. > > The document seems to be in reasonable shape, in particular it talks about cases when this extension should and should not be used. One comment about the Security Considerations section: > It is RECOMMENDED that only message stanzas containing attention > extensions from peers on the user's roster are accepted. Finer grained > control might be implemented. > IMHO, this is not a proper security consideration, as it doesn't explain the reason behind using "RECOMMENDED". From js-xmpp-standards at webkeks.org Sun Nov 9 04:05:58 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Sun, 9 Nov 2008 11:05:58 +0100 Subject: [Standards] Section 2.3 of XEP-0107 Message-ID: <097CDEF2-1521-4311-960C-0D0277DDAD8B@webkeks.org> Hi! In Gajim, this diff was recently committed: http://trac.gajim.org/changeset/10593 That lead to a discussion in the Gajim team whether that is right. Section 2.3 of XEP-0107 says: ?A user MAY provide a mood extension in a specific message in order to lend a defined emotional tone to the text.? To me, this sounds like you can attach a mood to a single message so that the receiving client can present that to the user together with the message somehow, not replacing the global mood set - which, honestly, sounds pretty useless to me. But on the other side, the Gajim diff uses this to attach the mood to every message sent when PEP is not supported, showing it as the global mood when received and replacing a mood received via PEP, if any was received. To me, this sounds wrong. All this brings me to the question: Is Section 2.3 useful or should it be removed? I personally don't think it should be used as a workaround if the server doesn't support PEP, as that's unwanted traffic (attached to every message, even sending when the receiving entitiy doesn't support moods etc.). If it wasn't meant as a workaround if the server doesn't support PEP, I wonder if it should be removed so it won't be abused for that purpose, as its use if used like I understood is questionable. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081109/930bae97/attachment.pgp From editor at xmpp.org Mon Nov 10 15:28:48 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Mon, 10 Nov 2008 15:28:48 -0600 Subject: [Standards] Proposed XMPP Extension: Message Mine-ing Message-ID: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Message Mine-ing Abstract: In servers that deliver messages sent to the bare JID to all resources, the resource that claims a converstaion notifies all of the user's other resources of that claim. URL: http://www.xmpp.org/extensions/inbox/mine.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. From rl71084 at gmail.com Mon Nov 10 21:10:09 2008 From: rl71084 at gmail.com (ricky ricky) Date: Mon, 10 Nov 2008 19:10:09 -0800 Subject: [Standards] XMPP Schemas errors Message-ID: Hi, I am writing a message listener that would listen (on a socket) for message comming out of an Openfire server #1 on one host to Openfire server #2 on another host. Openfire server #1 is configured to send the chat message to the message listener and the message listener would read the message (thru a socket) and then forward the message to openfire server # 2. I am using JAXB binding compiler (xbj) to generate a set of Java classes from the XMPP XML Schemas and unmarshalling incomming xml message to the corsponding Java class. I am having problem generating the Java classes from the XMPP schemas (downloaded from xmpp.org) because some of the shemas contain errors. A few of the shemas that I looked at that contains errors are "component-accept.xsd", "x-data.xsd", "component-connect.xsd", "eature-neg.xsd", etc.. Anyone know where I can find error free XMPP schemas? Appreciate for any help. -ricky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.jabber.org/pipermail/standards/attachments/20081110/e607f216/attachment.htm From remko at el-tramo.be Tue Nov 11 03:14:20 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Tue, 11 Nov 2008 10:14:20 +0100 Subject: [Standards] XMPP Schemas errors In-Reply-To: References: Message-ID: <133fd4c60811110114ne5c5fb6ud81c178dedc0c0bd@mail.gmail.com> Hi, > Anyone know where I can find error free XMPP schemas? This has is something that has come up before. The XMPP schemas are descriptive, not normative. There is quite some interest in having normative schemas for validating XMPP and for generating classes, but nobody has stepped up to do it yet AFAIK. The question is whether XSD is good enough for this, or whether we should use Relax NG or something of the like. cheers, Remko From remko at el-tramo.be Tue Nov 11 05:47:35 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Tue, 11 Nov 2008 12:47:35 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <4914D372.50506@stpeter.im> References: <4914D372.50506@stpeter.im> Message-ID: <133fd4c60811110347q17b91fdey3b8718d2fc558c9b@mail.gmail.com> > This Last Call has ended, with no feedback received. I would have changed the wording of 'If an entity supports receiving the attention extension, it MUST advertise that fact ...' into 'If an entity wishes to receive attention extensions, it MUST advertise support for the extension through disco' Supporting it doesn't mean you advertise it, which only becomes clear lower in the xep. cheers, Remko From stpeter at stpeter.im Tue Nov 11 10:10:33 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 11 Nov 2008 09:10:33 -0700 Subject: [Standards] XMPP Schemas errors In-Reply-To: References: Message-ID: <4919AE79.9040305@stpeter.im> ricky ricky wrote: > I am having problem generating the Java classes from the XMPP schemas > (downloaded from xmpp.org ) because some of the shemas > contain errors. A few of the shemas that I looked at that contains > errors are "component-accept.xsd", "x-data.xsd", > "component-connect.xsd", "eature-neg.xsd", etc.. Anyone know where I > can find error free XMPP schemas? The XMPP schemas will be free of errors when people report all the errors so that we can fix them. Feel free to send errata directly to me, or to this list. /psa From stpeter at stpeter.im Tue Nov 11 11:27:40 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 11 Nov 2008 10:27:40 -0700 Subject: [Standards] XMPP Schemas errors In-Reply-To: <4919AE79.9040305@stpeter.im> References: <4919AE79.9040305@stpeter.im> Message-ID: <4919C08C.4000606@stpeter.im> Peter Saint-Andre wrote: > ricky ricky wrote: > >> I am having problem generating the Java classes from the XMPP schemas >> (downloaded from xmpp.org ) because some of the shemas >> contain errors. A few of the shemas that I looked at that contains >> errors are "component-accept.xsd", "x-data.xsd", >> "component-connect.xsd", "eature-neg.xsd", etc.. Anyone know where I >> can find error free XMPP schemas? > > The XMPP schemas will be free of errors when people report all the > errors so that we can fix them. Feel free to send errata directly to me, > or to this list. Aha, I also found this: http://www.w3.org/2001/03/webdata/xsv I will add schema checking to our publication processes. Peter -- Peter Saint-Andre https://stpeter.im/ From Jehan.3irgvb at no-mx.jabberforum.org Wed Nov 12 05:55:42 2008 From: Jehan.3irgvb at no-mx.jabberforum.org (Jehan) Date: Wed, 12 Nov 2008 12:55:42 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) References: Message-ID: Hi, if it's not too late about this XEP (sorry if it is)... Remko Tron?on Wrote: > > Supporting it doesn't mean you advertise it, which only becomes clear > lower in the xep. > > > > > > > > I agree. > > In fact would it be possible to even have a finer grained > > advertisement? That would join the "security considerations", but > > instead of implementing this at client level, it could be at server > > level?.. For instance, you may configure that you want to advertise this > > feature only to people from a certain group, or even to some specific > > people only. Hence the server would advertise this feature only to these > > people and they would not forward a "attention" from the others, even if > > their clients send one anyway (removing the "attention" element, but > > still sending the "message" element... maybe also adding some > > information that an attention has been removed?). > > This way, if I am working for instance, I may set the attention to my > > work-mates (because they can have urgent matters regarding my current > > activity) but refuse all other "attention". > > > > > > XMPP Extensions Editor;4530 Wrote: > > > > > > 1. Is this specification needed to fill gaps in the XMPP protocol stack > > > or to clarify an existing protocol? > > > 2. Does the specification solve the problem stated in the introduction > > > and requirements? > > > 3. Do you plan to implement this specification in your code? If not, > > > why not? > > > 4. Do you have any security concerns related to this specification? > > > 5. Is the specification accurate and clearly written? > > > > > > Your feedback is appreciated!> > > > > > > > 1. I am not fond of such feature, at least the way I saw it used by > > some people (I saw such a thing was existing in MSN and some people > > I met who were using it were just complaining about having to block > > some people, etc.), and also because it is very intrusive. But well > > used (like the working guy case), so with fine grained > > configuration, it may be nice... > > 2. Yes. > > 3. I have currently no usable code where such high level feature > > could be used. But if I had a functional client, knowing that many > > users love this kind of feature, I would probably consider it in my > > todo list... but only with fine grained control (so if not at server > > level, at least at my client's level). > > 4. Maybe even from people authorized to send this kind of > > attention, there should be some limit? Wouldn't it be an issue if > > some of my contact were sending me a hundred of "attention" and if > > my screen would keep shaking/vibrating/etc.? > > 5. Easy to read and understand. So accurate and clear, yes. -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=966 From melo at simplicidade.org Wed Nov 12 05:56:57 2008 From: melo at simplicidade.org (Pedro Melo) Date: Wed, 12 Nov 2008 11:56:57 +0000 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <4914D3A4.3030405@stpeter.im> References: <4914D3A4.3030405@stpeter.im> Message-ID: <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> Hi, I found the following items that need correction: 1. Section 2, Protocol: in the first bullet set, the fourth bullet is wrong, it should be "The Stream ID of the stream from the Receiving Server to the Originating Server is ..." - the servers are reversed; 2. Section 2.3.4.2: there is an empty Note Well block in the fourth paragraph. 3. Example 31, 35 and 41: the error should be , as the text before the example states. The following items are questions I have about the spec: 1. Section 2.4.2.2: Error cases for Authoritative Server Processes Verification Request Two error cases are shown, but I think a third is also required: the value of the 'from' address provided by the Receiving Server is not authorized to connect to you. If some miss-configured outgoing S2S service at Originating Server initiates a connection to a domain that he was not allowed to, then the Authorization Server has this opportunity to prevent the connection from completing. 2. Section 2.6.2.1, Invalid connection from Auth Server to Recv Server The spec notes that the Recv Server MUST close the connection to the Auth Server if it receives a of type='invalid'. If the verification is being performed in a piggyback connection (as permitted in Section 1.5, last note), this is not very helpful because it could close an already active and useful connection. I would suggest that a doesn't alter the connection at al. This way the Recv Server can reuse that connection for other purposes, including other verifications. Also notice that the behavior (whether to close or not the connection after receiving the ) is left unspecified in the following Section 2.6.2.2, Valid Connection. A small note common to both 2.6.2.1 and 2.6.2.2 staging that the connection between Recv and Authz can be left open for reuse probably clarifies the whole issue. 3. Section 3, Reuse of Connections (piggybacking) 1. Cosmetic: maybe we should start using the term multiplexing; 2. The second paragraph limits the piggyback connections to sub- domains of the initial negotiated domain. I don't see any security reason for this. You can allow any domain to be multiplexed on an already existing connection, provided that the dialback verification process is successful. This would allow services with large number of domains to reuse S2S connections much easily. 3. Support for multiplex connections Going forward, it would be cleaner if the Recv Server announces support for multiplexed connections in the initial stream features. Something like: R2O: This clearly announces support for the feature and would precent try- and-miss attempts on future servers. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: melo at simplicidade.org Use XMPP! From remko at el-tramo.be Wed Nov 12 06:08:48 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Wed, 12 Nov 2008 13:08:48 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: References: Message-ID: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> > level?.. For instance, you may configure that you want to advertise this > feature only to people from a certain group Just don't include the feature when replying on a disco request from that group of people. Now you'll have to find a client that is willing to provide such a fine grained control interface to a user ... cheers, Remko PS: Quoting in the jabberforum interface seems to go crazy. From sgolovan at nes.ru Wed Nov 12 06:13:02 2008 From: sgolovan at nes.ru (Sergei Golovan) Date: Wed, 12 Nov 2008 15:13:02 +0300 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> References: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> Message-ID: On Wed, Nov 12, 2008 at 3:08 PM, Remko Tron?on wrote: >> level?.. For instance, you may configure that you want to advertise this >> feature only to people from a certain group > > Just don't include the feature when replying on a disco request from > that group of people. Now you'll have to find a client that is willing > to provide such a fine grained control interface to a user ... I would also add that showing different feature sets to different people in your roster breaks entity capabilities (XEP-0115) mechanism. -- Sergei Golovan From remko at el-tramo.be Wed Nov 12 06:15:13 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Wed, 12 Nov 2008 13:15:13 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: References: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> Message-ID: <133fd4c60811120415y11777cb6l1eed46218f1bceef@mail.gmail.com> > I would also add that showing different feature sets to different > people in your roster breaks entity capabilities (XEP-0115) mechanism. Why? Isn't XEP-0115 based on a hash from your feature string? And even the old version works: every feature that is optionally enabled was put in an 'ext'; for attention you would have created an 'attention' extension (which you would have needed to do anyway, since a user can turn this off). cheers, Remko From Jehan.3irhqz at no-mx.jabberforum.org Wed Nov 12 06:14:22 2008 From: Jehan.3irhqz at no-mx.jabberforum.org (Jehan) Date: Wed, 12 Nov 2008 13:14:22 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) References: Message-ID: Hi again, Jehan;4925 Wrote: > Hi, > 4. Maybe even from people authorized to send this kind of attention, > there should be some limit? Wouldn't it be an issue if some of my > contact were sending me a hundred of "attention" and if my screen would > keep shaking/vibrating/etc.? > Just to be clearer on this point. I saw it was considered in the "implementation notes" section (just to prevent remarks :p), but I am pointing it as being a security concern rather that just an implementation choice. The same way it can be a problem to get attention from unknown people (it could be some kind of annoying attack, maybe not really harmful, but still annoying); even from people you "know", or have had at least some contact, it can be annoying too if they overdo "attention" queries (and you don't always know perfectly people in your roster anyway). Hence if they are able to send you hundreds of attention who shock your display in a few lapse of time, I would consider this a security concern... And one last point I forgot in my previous message. When it is said: > > However, since some users might not want this feature to disturb them, > a client SHOULD allow the user to disable support. > For my own, a better advice is to have it disabled by default (then without advertise it at this point) and give the possibility to enable this support, not the opposite as proposed here. Many people may install a XMPP client without thinking about it and get disturbed when this happens the first time, especially if they don't know such feature (I heard some stories of people thinking their computer had an issue for days, until someone told them it was MSN!). This kind of feature is not really "major", hence should be only explicitely enabled (like an extra feature when you know what you are doing). Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=966 From melo at simplicidade.org Wed Nov 12 06:20:11 2008 From: melo at simplicidade.org (Pedro Melo) Date: Wed, 12 Nov 2008 12:20:11 +0000 Subject: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks) In-Reply-To: <4914D35D.2010507@stpeter.im> References: <4914D35D.2010507@stpeter.im> Message-ID: <1AE889AA-4DB2-4024-9CA2-505731CFE96A@simplicidade.org> Hello, Some comments regarding version 0.2 (2007-07-10): 1. Section 4.4, Simultaneous Resources The error type in Example 1 is 'modify'. I think it should be cancel because the request will never succeed no matter what you change in that session. 2. Section 4.5, Stanza Size The first response, sending back a stanza of type='error' requires the server to keep parsing the invalid stanza to know when it ends. With a never ending stanza, this will cause DoS for servers. I think the only response to Stanza Size is the second one: as soon as you detect an ongoing big stanza, give the stream error and close the stream and the underlying connection. 3. Section 4.6, Multiple Recipients Although I prefer to keep this section in case I'm missing something, I think the problem is already covered by 4.7 and 4.8 combined. 4. Section 4.9, Service Restrictions One amplifier service not mentioned is the session manager itself. The server should limit the number of presence changes. In particular the server should filter several presences with the exact same payload. The section only mentions access control features, and not DoS protection schemes. Regarding MUCs, we should mention per participant limits on presence changes and messages as concrete examples of limits to provide. Regarding PubSub, number of published items per time period should also be limited. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: melo at simplicidade.org Use XMPP! From nicolas.verite at gmail.com Wed Nov 12 06:26:03 2008 From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=) Date: Wed, 12 Nov 2008 13:26:03 +0100 Subject: [Standards] XMPP Reports Message-ID: <6e2f977f0811120426g2a5bb654rb7ebddc5769caf4b@mail.gmail.com> Hi, I've created this page: http://wiki.xmpp.org/web/XMPP_Report_2 Since the Jabber Journal is dead and the XMPP Report #1 is taking the relay and has been published on the "Extended Conversation" blog at http://blog.xmpp.org/ on september, I would like to contribute to the next releases, as maybe some other people. So the wiki is a place where to contribute. N?co -- Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com Jabber ID : xmpp:nyco at jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ From sgolovan at nes.ru Wed Nov 12 06:29:01 2008 From: sgolovan at nes.ru (Sergei Golovan) Date: Wed, 12 Nov 2008 15:29:01 +0300 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <133fd4c60811120415y11777cb6l1eed46218f1bceef@mail.gmail.com> References: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> <133fd4c60811120415y11777cb6l1eed46218f1bceef@mail.gmail.com> Message-ID: On Wed, Nov 12, 2008 at 3:15 PM, Remko Tron?on wrote: >> I would also add that showing different feature sets to different >> people in your roster breaks entity capabilities (XEP-0115) mechanism. > > Why? Isn't XEP-0115 based on a hash from your feature string? And even In XEP-0115 you include a hashed features list into your presence packet. This presence packet is the same for all you roster items (in fact, it's your server who broadcasts this packet). So, you can't include different feature sets in entity capabilities packet for different roster items. Though I recall that XEP-0115 requires that the disco query should include a specific node, so it's possible that the answer could differ from the usual disco query (without node attribute). It looks weird that two disco queries which are ment to be identical will diifer, but at least it doesn't break things. Sorry for the noise. -- Sergei Golovan From remko at el-tramo.be Wed Nov 12 06:37:45 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Wed, 12 Nov 2008 13:37:45 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: References: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> <133fd4c60811120415y11777cb6l1eed46218f1bceef@mail.gmail.com> Message-ID: <133fd4c60811120437l1df829fs6b6d56f3b688cfb8@mail.gmail.com> > In XEP-0115 you include a hashed features list into your presence packet. This > presence packet is the same for all you roster items (in fact, it's > your server who broadcasts this packet). Right, I was talking about using directed presence to these contacts. I didn't say it was an easy solution, but that would be the 'protocol' solution, albeit a horrible one. It's much easier to do this type of filtering in the client itself (it's just an stanza), so I don't see any reason for going into any more details. Just mentioning that the client should allow a user to disable it is enough; at what granularity or any other detail (such as maximum attention send rate and those crazy things) is left to the client, and should be left out of protocol specs like this. cheers, Remko From dave at cridland.net Wed Nov 12 08:12:51 2008 From: dave at cridland.net (Dave Cridland) Date: Wed, 12 Nov 2008 14:12:51 +0000 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> References: <4914D3A4.3030405@stpeter.im> <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> Message-ID: <30276.1226499171.333705@peirce.dave.cridland.net> Thanks, this is really useful. On Wed Nov 12 11:56:57 2008, Pedro Melo wrote: > 3. Section 3, Reuse of Connections (piggybacking) > > > 1. Cosmetic: maybe we should start using the term multiplexing; > > I think changing it now would be more confusing than not changing it. > 2. The second paragraph limits the piggyback connections to sub- > domains of the initial negotiated domain. > > I don't see any security reason for this. You can allow any domain > to be multiplexed on an already existing connection, provided that > the dialback verification process is successful. This would allow > services with large number of domains to reuse S2S connections > much easily. > > Interesting - I don't read that as limiting reuse to that case, I read it as saying that's merely a typical reason. Indeed, Google used to do this kind of piggybacking, and as I recall, it couldn't cope with piggybacking being refused. > 3. Support for multiplex connections > > Going forward, it would be cleaner if the Recv Server announces > support for multiplexed connections in the initial stream features. > > Something like: > > R2O: > > > > > > > > > > This clearly announces support for the feature and would precent > try- and-miss attempts on future servers. > > Well, going forward, I'm hoping we'll remove the need for dialback at all. I'd like to hope it remains purely as a stub protocol for connection reuse, and that db:verify simply disappears in a puff of certificate equality checking. (Which it could do, I think). Two questions: 1) Do any server implementations actually do piggybacking anymore? 2) Do any server implementations reject piggybacking attempts, as per Example 45? Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From mwild1 at gmail.com Wed Nov 12 08:40:26 2008 From: mwild1 at gmail.com (Matthew Wild) Date: Wed, 12 Nov 2008 14:40:26 +0000 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <4914D3A4.3030405@stpeter.im> References: <4914D3A4.3030405@stpeter.im> Message-ID: <4db9cacb0811120640j4e160e22m5fe23fa4c33ac645@mail.gmail.com> On Fri, Nov 7, 2008 at 11:47 PM, Peter Saint-Andre wrote: > This Last Call has ended. I received some feedback off-list, which I > will consolidate and post to the list next week. > I recently finished implementing dialback. The XEP seems ok, minus the points that Pedro highlighted (I missed many of those myself). There is also a use of remote-server-timeout in the notes under examples 12 & 18. I have not added support for piggybacking. I don't know what other servers support and actively use it, so I don't yet know what happens when another server attempts it. I'm afraid I have not even begun to test my implementation for compliance, it just "works" at the moment, hence I haven't really studied the error cases yet. Matthew. From dave at cridland.net Wed Nov 12 08:42:20 2008 From: dave at cridland.net (Dave Cridland) Date: Wed, 12 Nov 2008 14:42:20 +0000 Subject: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks) In-Reply-To: <1AE889AA-4DB2-4024-9CA2-505731CFE96A@simplicidade.org> References: <4914D35D.2010507@stpeter.im> <1AE889AA-4DB2-4024-9CA2-505731CFE96A@simplicidade.org> Message-ID: <30276.1226500940.715149@peirce.dave.cridland.net> On Wed Nov 12 12:20:11 2008, Pedro Melo wrote: > Hello, > > Some comments regarding version 0.2 (2007-07-10): > > > 1. Section 4.4, Simultaneous Resources > > The error type in Example 1 is 'modify'. I think it should be > cancel because the request will never succeed no matter what you > change in that session. > > This depends... If the client could reuse an existing resource and disconnect the original session, still, then it's a "modify", since the client could simply change the resource. > 2. Section 4.5, Stanza Size > > The first response, sending back a stanza of type='error' requires > the server to keep parsing the invalid stanza to know when it > ends. With a never ending stanza, this will cause DoS for servers. > > I think the only response to Stanza Size is the second one: as soon > as you detect an ongoing big stanza, give the stream error and > close the stream and the underlying connection. > > Ah... I suspect that not all servers are capable, and in addition, some might have a lower level for stanzas they're willing to process locally but not forward, etc. But indeed, if the stanza is simply "way too big", then the intent of that text seems to be to shutdown the connection. Tell me, did you (as a non-native speaker) know the word "egregiously"? I ask because, as a native speaker, I didn't. I think I might know how to pronounce it. :-) > 3. Section 4.6, Multiple Recipients > > Although I prefer to keep this section in case I'm missing > something, I think the problem is already covered by 4.7 and 4.8 > combined. > > I think if the administrator uses the facilities in 4.8 and 4.7, then they won't need this one, but this one on its own may still be useful. > 4. Section 4.9, Service Restrictions > > One amplifier service not mentioned is the session manager itself. > The server should limit the number of presence changes. > > In particular the server should filter several presences with the > exact same payload. > > The section only mentions access control features, and not DoS > protection schemes. > > Regarding MUCs, we should mention per participant limits on > presence changes and messages as concrete examples of limits to > provide. > > Regarding PubSub, number of published items per time period should > also be limited. That's interesting - could we do presence damping? (ie, the more you change your presence, the more we delay relaying it, and drop "overlapped" presence changes entirely). I also noted (when reading through the XEP alongside your review) that in section 5, it suggests that stream compression might relax limits - it's possibly worth noting that it's possible to use DEFLATE as a traffic amplification attack, so I'm not convinced this is good advice. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave at cridland.net Wed Nov 12 08:46:33 2008 From: dave at cridland.net (Dave Cridland) Date: Wed, 12 Nov 2008 14:46:33 +0000 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <133fd4c60811120437l1df829fs6b6d56f3b688cfb8@mail.gmail.com> References: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> <133fd4c60811120415y11777cb6l1eed46218f1bceef@mail.gmail.com> <133fd4c60811120437l1df829fs6b6d56f3b688cfb8@mail.gmail.com> Message-ID: <30276.1226501193.551641@peirce.dave.cridland.net> On Wed Nov 12 12:37:45 2008, Remko Tron?on wrote: > > In XEP-0115 you include a hashed features list into your presence > packet. This > > presence packet is the same for all you roster items (in fact, > it's > > your server who broadcasts this packet). > > Right, I was talking about using directed presence to these > contacts. > I didn't say it was an easy solution, but that would be the > 'protocol' > solution, albeit a horrible one. > > It's much easier to do this type of filtering in the client itself > (it's just an stanza), so I don't see any reason for > going into any more details. Just mentioning that the client should > allow a user to disable it is enough; at what granularity or any > other > detail (such as maximum attention send rate and those crazy things) > is > left to the client, and should be left out of protocol specs like > this. If I send you , and your client doesn't honour it from me, should your client tell me? Or should it tell me if it did? Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From mwild1 at gmail.com Wed Nov 12 10:43:10 2008 From: mwild1 at gmail.com (Matthew Wild) Date: Wed, 12 Nov 2008 16:43:10 +0000 Subject: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks) In-Reply-To: References: Message-ID: <4db9cacb0811120843y35110be3sb0d609dcd9ed1c82@mail.gmail.com> On Wed, Oct 22, 2008 at 9:51 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0205 (Best Practices to Discourage Denial of Service Attacks). > > Abstract: This document recommends a number of practices that can help discourage denial of service attacks on XMPP-based networks. > > URL: http://www.xmpp.org/extensions/xep-0205.html > > This Last Call begins today and shall end at the close of business on 2008-11-07. > > Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? > 2. Does the specification solve the problem stated in the introduction and requirements? > 3. Do you plan to implement this specification in your code? If not, why not? > 4. Do you have any security concerns related to this specification? > 5. Is the specification accurate and clearly written? > Is not: 4.3 Unauthenticated Connections In accordance with RFC 3920, a server MUST NOT process XML stanzas from clients that have not provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see RFC 4422 [9]) or verified via server dialback. misleading? I mean, you need to process incoming stanzas in order to authenticate, etc. I know this is obvious, but perhaps the text should mention presence/iq/message explicitly instead. ...or maybe I'm just being fussy :) I also agree with Pedro that type='modify' seems wrong in example 1. The RFC states modify means "retry after changing the data sent ". Changing the data sent will not fix this error. However I do not think it should be 'cancel' either (RFC: "do not retry (the error cannot be remedied)") - rather I think it should be 'wait' (one of the other resources may log out, for example). Also note that RFC3920bis specifies a completely different error in this case: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#bind-servergen-error-resourceconstraint Matthew. From Jehan.3irupn at no-mx.jabberforum.org Wed Nov 12 10:54:29 2008 From: Jehan.3irupn at no-mx.jabberforum.org (Jehan) Date: Wed, 12 Nov 2008 17:54:29 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) References: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com><133fd4c60811120415y11777cb6l1eed46218f1bceef@mail.gmail.com> <133fd4c60811120437l1df829fs6b6d56f3b688cfb8@mail.gmail.com> Message-ID: Remko Tron??on;4934 Wrote: > > It's much easier to do this type of filtering in the client itself > (it's just an stanza), so I don't see any reason for > going into any more details. Just mentioning that the client should > allow a user to disable it is enough; at what granularity or any other > detail (such as maximum attention send rate and those crazy things) is > left to the client, and should be left out of protocol specs like > this. > The difference when this job is left to the client is that people "think" you receive their "attention" signal. If you advertise the support to everyone, but let your client discard them, except for some people, your contacts who have sent one (which has been discarded) would think you have received it, and either don't want to answer, or that the software is broken, or else. Being able to advertise it on a server side would allow the contact's client to "know" if you are accepting it specifically for them. So the contact's client may "gray" this functionnality for you for instance. In such case, if the contact sends one "attention" anyway, then your client can still discard it, but then it is the contact's client which is to be fixed. If you advertise the support to anyone but in reality discard nearly all of them, then everyone's client is working fine according to the XEP, but still there is something broken somewhere for the users... So this is not good for the user experience. Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=966 From justin-keyword-jabber.093179 at affinix.com Wed Nov 12 10:57:11 2008 From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges) Date: Wed, 12 Nov 2008 08:57:11 -0800 Subject: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks) In-Reply-To: <4db9cacb0811120843y35110be3sb0d609dcd9ed1c82@mail.gmail.com> References: <4db9cacb0811120843y35110be3sb0d609dcd9ed1c82@mail.gmail.com> Message-ID: <200811120857.11866.justin-keyword-jabber.093179@affinix.com> On Wednesday 12 November 2008 08:43:10 Matthew Wild wrote: > misleading? I mean, you need to process incoming stanzas in order to > authenticate, etc. I know this is obvious, but perhaps the text should > mention presence/iq/message explicitly instead. It is sometimes confusing, but a 'stanza' refers to a depth=1 element of type presence, iq, or message. Anything else is just an element. -Justin From stpeter at stpeter.im Wed Nov 12 10:53:52 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 12 Nov 2008 09:53:52 -0700 Subject: [Standards] Call for Experience: XEP-0012 In-Reply-To: <200810151147.05001.justin-keyword-jabber.093179@affinix.com> References: <48F3B2C4.7090906@stpeter.im> <030F4C30-7246-4279-BFB3-EAA51F076302@webkeks.org> <48F635E4.9050507@stpeter.im> <200810151147.05001.justin-keyword-jabber.093179@affinix.com> Message-ID: <491B0A20.3070002@stpeter.im> Justin Karneges wrote: > On Wednesday 15 October 2008 11:26:44 Peter Saint-Andre wrote: >> Jonathan Schleifer wrote: >>> Am 15.10.2008 um 20:09 schrieb Justin Karneges: >>>> way, but one thing is true in all cases: the value is never the idle >>>> time. >>> It is only the idle time when you send to the full JID. The bare JID >>> always returns last logged in. >> Right. So sending idle in client-generated presence is consistent with >> that (and no need to ping). > > Silly me. I didn't know full JID querying was used. Psi doesn't seem to > support it.. > > The proposal looks good to me then. Here is the text I have formulated to address this use case (by adding a new section to XEP-0012)... *** 5. Inclusion in Presence An online client MAY include last activity information when sending presence updates. The prototypical use case is including the idle time when automatically setting the user's value to "away" or "xa" (extended away). For example, consider a user who has configured her client to automatically change her presence to "away" after 10 minutes of inactivity. The client could include an iq:last flag to specify how long the user has been idle. Example 10. Last Indication in Auto-Away away If one of the user's contacts receives that presence notification with delayed delivery (see Delayed Delivery [3]) on login in response to a presence probe as described in XMPP IM [4], the contact will then know how long the user has been idle (i.e., the number of seconds since the delayed delivery timestamp, plus the iq:last seconds). Thus the contact does not need to send an iq:last query. Example 11. Last Indication in Auto-Away With Delayed Delivery away If no last indication is included in a presence notification, the recipient MUST assume that the idle time is zero. *** Yes, no, maybe? Peter From melo at simplicidade.org Wed Nov 12 12:34:04 2008 From: melo at simplicidade.org (Pedro Melo) Date: Wed, 12 Nov 2008 18:34:04 +0000 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <30276.1226499171.333705@peirce.dave.cridland.net> References: <4914D3A4.3030405@stpeter.im> <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> <30276.1226499171.333705@peirce.dave.cridland.net> Message-ID: <1FADE4F1-1737-4F5D-B129-838739FE42AE@simplicidade.org> On Nov 12, 2008, at 2:12 PM, Dave Cridland wrote: > Thanks, this is really useful. > > On Wed Nov 12 11:56:57 2008, Pedro Melo wrote: >> 3. Section 3, Reuse of Connections (piggybacking) >> 1. Cosmetic: maybe we should start using the term multiplexing; > I think changing it now would be more confusing than not changing it. Ok, it was mere cosmetic issue. >> 2. The second paragraph limits the piggyback connections to sub- >> domains of the initial negotiated domain. >> I don't see any security reason for this. You can allow any domain >> to be multiplexed on an already existing connection, provided that >> the dialback verification process is successful. This would allow >> services with large number of domains to reuse S2S connections >> much easily. > Interesting - I don't read that as limiting reuse to that case, I > read it as saying that's merely a typical reason. Indeed, Google > used to do this kind of piggybacking, and as I recall, it couldn't > cope with piggybacking being refused. ok, I read it as a limitation. I'll re-read. >> 3. Support for multiplex connections >> Going forward, it would be cleaner if the Recv Server announces >> support for multiplexed connections in the initial stream features. >> Something like: >> R2O: >> >> >> >> >> >> >> >> >> This clearly announces support for the feature and would precent >> try- and-miss attempts on future servers. > Well, going forward, I'm hoping we'll remove the need for dialback > at all. I'd like to hope it remains purely as a stub protocol for > connection reuse, and that db:verify simply disappears in a puff of > certificate equality checking. (Which it could do, I think). > > Two questions: > > 1) Do any server implementations actually do piggybacking anymore? > > 2) Do any server implementations reject piggybacking attempts, as > per Example 45? Going forward, if we get servers hosting thousands of domains, multiplex/piggyback is a must have feature, IMHO. I think the number of S2S would soon get out of hand if you don't use multiplex. But actually this is another topic, so I'll refrain from talking about it in this thread :) Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: melo at simplicidade.org Use XMPP! From melo at simplicidade.org Wed Nov 12 12:40:15 2008 From: melo at simplicidade.org (Pedro Melo) Date: Wed, 12 Nov 2008 18:40:15 +0000 Subject: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks) In-Reply-To: <30276.1226500940.715149@peirce.dave.cridland.net> References: <4914D35D.2010507@stpeter.im> <1AE889AA-4DB2-4024-9CA2-505731CFE96A@simplicidade.org> <30276.1226500940.715149@peirce.dave.cridland.net> Message-ID: On Nov 12, 2008, at 2:42 PM, Dave Cridland wrote: > On Wed Nov 12 12:20:11 2008, Pedro Melo wrote: >> Hello, >> Some comments regarding version 0.2 (2007-07-10): >> 1. Section 4.4, Simultaneous Resources >> The error type in Example 1 is 'modify'. I think it should be >> cancel because the request will never succeed no matter what you >> change in that session. > This depends... If the client could reuse an existing resource and > disconnect the original session, still, then it's a "modify", since > the client could simply change the resource. Ok. >> 2. Section 4.5, Stanza Size >> The first response, sending back a stanza of type='error' requires >> the server to keep parsing the invalid stanza to know when it >> ends. With a never ending stanza, this will cause DoS for servers. >> I think the only response to Stanza Size is the second one: as soon >> as you detect an ongoing big stanza, give the stream error and >> close the stream and the underlying connection. > Ah... I suspect that not all servers are capable, and in addition, > some might have a lower level for stanzas they're willing to process > locally but not forward, etc. But indeed, if the stanza is simply > "way too big", then the intent of that text seems to be to shutdown > the connection. > > Tell me, did you (as a non-native speaker) know the word > "egregiously"? I ask because, as a native speaker, I didn't. I think > I might know how to pronounce it. :-) yes, I do know the meaning of word. The portuguese version is similar phonetically. But I wouldn't be able to spell it if you asked me. As for pronouncing it, forget about it. :) >> 3. Section 4.6, Multiple Recipients >> Although I prefer to keep this section in case I'm missing >> something, I think the problem is already covered by 4.7 and 4.8 >> combined. > I think if the administrator uses the facilities in 4.8 and 4.7, > then they won't need this one, but this one on its own may still be > useful. Ok. >> 4. Section 4.9, Service Restrictions >> One amplifier service not mentioned is the session manager itself. >> The server should limit the number of presence changes. >> In particular the server should filter several presences with the >> exact same payload. >> The section only mentions access control features, and not DoS >> protection schemes. >> Regarding MUCs, we should mention per participant limits on >> presence changes and messages as concrete examples of limits to >> provide. >> Regarding PubSub, number of published items per time period should >> also be limited. > > That's interesting - could we do presence damping? (ie, the more you > change your presence, the more we delay relaying it, and drop > "overlapped" presence changes entirely). ejabberd does that for MUCs. I like the concept and it helped SAPO at the time, where a F8 key in a well-known Delphi-based windows client would toggle the presence at the maximum speed between avaialble/away :) I honestly can't remember the name of the client right now. > I also noted (when reading through the XEP alongside your review) > that in section 5, it suggests that stream compression might relax > limits - it's possibly worth noting that it's possible to use > DEFLATE as a traffic amplification attack, so I'm not convinced this > is good advice. I meant to comment on that and missed my marker. I think the limits of bandwidth should be applied after decompression. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: melo at simplicidade.org Use XMPP! From dave at cridland.net Wed Nov 12 15:05:01 2008 From: dave at cridland.net (Dave Cridland) Date: Wed, 12 Nov 2008 21:05:01 +0000 Subject: [Standards] XEPs in Pretty Colours. Message-ID: <30276.1226523901.569488@peirce.dave.cridland.net> I appreciate that this is almost inexcusably trivial, but bear with me. On the Council list, Peter Saint-Andre happens to mention the potential confusion of having both Standards Track XEPs and Informational XEPs (and there's others) all in the same series. This has hit the IETF, too - everyone refers to an RFC as a "Standard", even though many RFCs aren't standards at all - in fact, strictly speaking, very few indeed are - see RFC 1796 for a discussion. (And that RFC is not a standard, either). So to make it more obvious, I suggested colour coding the different XEPs. The remainder of this email is what I sent to the Council list - I'd be interested in people's opinions, although I'm not desperately interested in *which* colours, precisely. Something I've noticed is that the XSF's logo can now be retromemed into symbolizing the various streams of documents we produce. :-) ... Perhaps we could consider styling them differently - I'm put in mind of the UK Government (and probably elsewhere, too) practise of "white papers", "green papers", etc, and wondering whether we literally follow that practise - so Informational documents would "go white" when they went Active, and documents in the "working" phase of the lifecycle - Experimental and Proposed - would be Green. It's probably worth making Proposed blue, such that it's a "blueprint" of the proposal. For the various "failure" states, I'd simply pick grey. For Standards Track documents, I quite like the idea of Final documents "going gold", and that just leaves Draft, which for no good reason I'll pick Pink. This yields: Retracted, Deferred, Rejected, Deprecated, Obsolete -> #7F7F7F Active -> #FFFFFF Experimental -> #CFEFCF Proposed -> #AFCFFF Draft -> #FFEFEF Final -> #FFFFCF These colours can live in the side margins of the document, so there's a very clear visual indicator of the status of the document. And this can be accomplished reasonably easily with a minor XSL and CSS tweak, which I've attached in patch form. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade -------------- next part -------------- A non-text attachment was scrubbed... Name: xmpp-spec-colours.diff Type: text/x-diff Size: 1729 bytes Desc: not available Url : http://mail.jabber.org/pipermail/standards/attachments/20081112/69ccbe40/attachment.diff From remko at el-tramo.be Wed Nov 12 15:40:11 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Wed, 12 Nov 2008 22:40:11 +0100 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <30276.1226523901.569488@peirce.dave.cridland.net> References: <30276.1226523901.569488@peirce.dave.cridland.net> Message-ID: <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> > I appreciate that this is almost inexcusably trivial, but bear with me. I say, let's put these hip state-of the art 4-color (or more!) displays finally to work! Slightly related, I once wrote up a script that would generate a graph of all XEP dependencies, and warn you about XEPs in draft state depending on XEPs in experimental state (and other relations that aren't allowed). The main flaw was that some XEPs refer to XEPs in sentences like "This XEP replaces XEP xxx", in which case the dependency *is* allowed. This could be solved by adding exceptions, or adding extra sections to XEPs, ..., but I didn't really bother. Maybe a tool like that could also be an addition to our XEP consistency checking? cheers, Remko From nicolas.verite at gmail.com Wed Nov 12 15:45:43 2008 From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=) Date: Wed, 12 Nov 2008 22:45:43 +0100 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> References: <30276.1226523901.569488@peirce.dave.cridland.net> <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> Message-ID: <6e2f977f0811121345x4ad18026x921da81dd9a03f64@mail.gmail.com> On Wed, Nov 12, 2008 at 10:40 PM, Remko Tron?on wrote: >> I appreciate that this is almost inexcusably trivial, but bear with me. > > I say, let's put these hip state-of the art 4-color (or more!) > displays finally to work! Color-coding is not enough: it is not accessible for the blinds or visually impaired. We need more printed text (meta)data. N?co -- Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com Jabber ID : xmpp:nyco at jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ From remko at el-tramo.be Wed Nov 12 15:50:13 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Wed, 12 Nov 2008 22:50:13 +0100 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <6e2f977f0811121345x4ad18026x921da81dd9a03f64@mail.gmail.com> References: <30276.1226523901.569488@peirce.dave.cridland.net> <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> <6e2f977f0811121345x4ad18026x921da81dd9a03f64@mail.gmail.com> Message-ID: <133fd4c60811121350u73059bd2j90b6c65e84da307c@mail.gmail.com> > Color-coding is not enough: it is not accessible for the blinds or > visually impaired. We need more printed text (meta)data. That information should already be there: http://xmpp.org/extensions/ cheers, Remko From dave at cridland.net Wed Nov 12 16:07:35 2008 From: dave at cridland.net (Dave Cridland) Date: Wed, 12 Nov 2008 22:07:35 +0000 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <6e2f977f0811121345x4ad18026x921da81dd9a03f64@mail.gmail.com> References: <30276.1226523901.569488@peirce.dave.cridland.net> <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> <6e2f977f0811121345x4ad18026x921da81dd9a03f64@mail.gmail.com> Message-ID: <30276.1226527655.031486@peirce.dave.cridland.net> On Wed Nov 12 21:45:43 2008, Nicolas V?rit? wrote: > On Wed, Nov 12, 2008 at 10:40 PM, Remko Tron?on > wrote: > >> I appreciate that this is almost inexcusably trivial, but bear > with me. > > > > I say, let's put these hip state-of the art 4-color (or more!) > > displays finally to work! > > Color-coding is not enough: it is not accessible for the blinds or > visually impaired. We need more printed text (meta)data. Indeed - there's boilerplate text automatically added, the problem is this is typically skipped over by (visual) readers. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From Jehan.3ismtf at no-mx.jabberforum.org Wed Nov 12 21:01:16 2008 From: Jehan.3ismtf at no-mx.jabberforum.org (Jehan) Date: Thu, 13 Nov 2008 04:01:16 +0100 Subject: [Standards] Event for the 10th birthday of XMPP Message-ID: Hi, as it has been mentionned in some place (among others, here: http://www.jabber.org/web/Secure_Communications_Week ), the 4th of january 2009 will be the 10th birthday of XMPP. I thought it could be a good occasion to organize an event to advertise this protocol. Some wide event, both technical but also generalist would be a good thing, in my opinion. After discussion with some people about this, we conclude that it could be even worldwide (not obligatory exactly at the same time), in different places all over several countries. For my own, for France, I (with the help of anyone wishing to) would be ready to organize one in Paris, not only because it is the capitale of France, but also because I live there. Of course for this to be very interesting and a success, I think that having the help from people from the community but also from the XSF is mandatory. Indeed I think this is worth it only if it is an important event... So first of all, before going further, what do people here think of this idea? Jehan P.S.: I was not sure where to post this. This mailing list is maybe not the most appropriate place, but there is no "general discussion" ml. Moreover it is probably better for this discussion to begin public (even though we may also discuss this in the member ml). -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1073 From mwild1 at gmail.com Wed Nov 12 22:01:48 2008 From: mwild1 at gmail.com (Matthew Wild) Date: Thu, 13 Nov 2008 04:01:48 +0000 Subject: [Standards] Event for the 10th birthday of XMPP In-Reply-To: References: Message-ID: <4db9cacb0811122001i1fb6b2d5kffa4efbb7e29be05@mail.gmail.com> On Thu, Nov 13, 2008 at 3:01 AM, Jehan wrote: > > Hi, > > as it has been mentionned in some place (among others, here: > http://www.jabber.org/web/Secure_Communications_Week ), the 4th of > january 2009 will be the 10th birthday of XMPP. I thought it could be a > good occasion to organize an event to advertise this protocol. Some wide > event, both technical but also generalist would be a good thing, in my > opinion. After discussion with some people about this, we conclude that > it could be even worldwide (not obligatory exactly at the same time), in > different places all over several countries. > See also: http://metajack.im/2008/11/05/interest-in-xmpp-open-day/ and no, I don't know the best place either, but maybe jdev would be better :) Matthew. From stpeter at stpeter.im Wed Nov 12 15:21:27 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 12 Nov 2008 14:21:27 -0700 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <30276.1226501193.551641@peirce.dave.cridland.net> References: <133fd4c60811120408p6bed3391v59dcd6044f72429e@mail.gmail.com> <133fd4c60811120415y11777cb6l1eed46218f1bceef@mail.gmail.com> <133fd4c60811120437l1df829fs6b6d56f3b688cfb8@mail.gmail.com> <30276.1226501193.551641@peirce.dave.cridland.net> Message-ID: <491B48D7.7020808@stpeter.im> Dave Cridland wrote: > On Wed Nov 12 12:37:45 2008, Remko Tron?on wrote: >> > In XEP-0115 you include a hashed features list into your presence >> packet. This >> > presence packet is the same for all you roster items (in fact, it's >> > your server who broadcasts this packet). >> >> Right, I was talking about using directed presence to these contacts. >> I didn't say it was an easy solution, but that would be the 'protocol' >> solution, albeit a horrible one. >> >> It's much easier to do this type of filtering in the client itself >> (it's just an stanza), so I don't see any reason for >> going into any more details. Just mentioning that the client should >> allow a user to disable it is enough; at what granularity or any other >> detail (such as maximum attention send rate and those crazy things) is >> left to the client, and should be left out of protocol specs like >> this. > > If I send you , and your client doesn't honour it from me, > should your client tell me? No. IMHO if you send me a message containing only the data and my client doesn't support the extension or is configured to ignore it, then it SHOULD NOT send you any error notification. > Or should it tell me if it did? No. It's fire and forget. If I ignore you, then it's too bad for you. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter at stpeter.im Wed Nov 12 15:27:30 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 12 Nov 2008 14:27:30 -0700 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <4915B331.60000@isode.com> References: <4914D372.50506@stpeter.im> <4915B331.60000@isode.com> Message-ID: <491B4A42.1090900@stpeter.im> Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> This Last Call has ended, with no feedback received. >> >> > The document seems to be in reasonable shape, in particular it talks > about cases when this extension should and should not be used. > One comment about the Security Considerations section: > >> It is RECOMMENDED that only message stanzas containing attention >> extensions from peers on the user's roster are accepted. Finer grained >> control might be implemented. >> > IMHO, this is not a proper security consideration, as it doesn't explain > the reason behind using "RECOMMENDED". How is this text? "It is RECOMMENDED that a client accept message stanzas containing the attention extension only contacts that are in the user's roster or with whome the user's client is currently sharing directed presence, mainly to prevent the user from being annoyed by attention requests from random entities on the network. A client could implement finer-grained control if desired (e.g., allow attention requests only from entities in a particular roster group)." Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter at stpeter.im Wed Nov 12 15:28:08 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 12 Nov 2008 14:28:08 -0700 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <133fd4c60811110347q17b91fdey3b8718d2fc558c9b@mail.gmail.com> References: <4914D372.50506@stpeter.im> <133fd4c60811110347q17b91fdey3b8718d2fc558c9b@mail.gmail.com> Message-ID: <491B4A68.9070809@stpeter.im> Remko Tron?on wrote: >> This Last Call has ended, with no feedback received. > > I would have changed the wording of > > 'If an entity supports receiving the attention extension, it MUST > advertise that fact ...' > > into > > 'If an entity wishes to receive attention extensions, it MUST > advertise support for the extension through disco' > > Supporting it doesn't mean you advertise it, which only becomes clear > lower in the xep. Right. I've made that change. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter at stpeter.im Wed Nov 12 15:32:28 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 12 Nov 2008 14:32:28 -0700 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: References: Message-ID: <491B4B6C.9070601@stpeter.im> Jehan wrote: > Hi again, > > Jehan;4925 Wrote: >> Hi, >> 4. Maybe even from people authorized to send this kind of attention, >> there should be some limit? Wouldn't it be an issue if some of my >> contact were sending me a hundred of "attention" and if my screen would >> keep shaking/vibrating/etc.? >> > > Just to be clearer on this point. I saw it was considered in the > "implementation notes" section (just to prevent remarks :p), but I am > pointing it as being a security concern rather that just an > implementation choice. > The same way it can be a problem to get attention from unknown people > (it could be some kind of annoying attack, maybe not really harmful, but > still annoying); even from people you "know", or have had at least some > contact, it can be annoying too if they overdo "attention" queries (and > you don't always know perfectly people in your roster anyway). Hence if > they are able to send you hundreds of attention who shock your display > in a few lapse of time, I would consider this a security concern... See my previous message with a revised security consideration. > And one last point I forgot in my previous message. When it is said: >> However, since some users might not want this feature to disturb them, >> a client SHOULD allow the user to disable support. >> > > For my own, a better advice is to have it disabled by default (then > without advertise it at this point) and give the possibility to enable > this support, not the opposite as proposed here. Many people may install > a XMPP client without thinking about it and get disturbed when this > happens the first time, especially if they don't know such feature (I > heard some stories of people thinking their computer had an issue for > days, until someone told them it was MSN!). This kind of feature is not > really "major", hence should be only explicitely enabled (like an extra > feature when you know what you are doing). That seems reasonable. How is this text? "Because some users might not want this feature to disturb them, a client MUST either (1) allow the user to disable support or (2) disable the feature by default and process attention requests only if the user has explicitly enabled support." /psa From stpeter at stpeter.im Wed Nov 12 15:40:35 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 12 Nov 2008 14:40:35 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <49148352.3090008@stpeter.im> References: <49121783.5050002@stpeter.im> <200811062200.40830.justin-keyword-jabber.093179@affinix.com> <49146DFF.1050400@stpeter.im> <200811070913.30007.justin-keyword-jabber.093179@affinix.com> <49148352.3090008@stpeter.im> Message-ID: <491B4D53.80402@stpeter.im> Peter Saint-Andre wrote: > Justin Karneges wrote: >> On Friday 07 November 2008 08:34:07 Peter Saint-Andre wrote: >>> Right, so the question is not "what format is sent over the wire?" (as >>> we can see that's the fancy encoding to save space and indicate the >>> length of each key-value pair) but "what is the format that an entity >>> publishes to the mdns address?" (and that might be a text-based notation >>> with each key-value pair contained within quotes). In any case, I think >>> that what's currently in XEP-0174 is wrong because you don't publish one >>> TXT record for each key-value pair, instead you publish a single TXT >>> record that contains all of the key-value pairs. >> Correct. A single TXT record contains all the strings. >> >>> So that means you publish something like this (it would be all one "line" >>> in DNS but I can't show that in email): >>> >>> juliet at pronto._presence._tcp.local. IN TXT "txtvers=1" "1st=Juliet" >>> "email=juliet at capulet.lit" "hash=sha-1" "jid=juliet at capulet.lit" >>> "last=Capulet" "msg=Hanging out downtown" "nick=JuliC" >>> "node=http://www.adiumx.com" >>> "phsh=a3839614e1a382bcfebbcf20464f519e81770813" "port.p2pj=5562" >>> "status=avail" "vc=CA!" "ver=QgayPKawpkPSDYmwT/WM94uAlu0=" >>> >>> Yes, no, maybe? >> Yes. > > Right. I will confirm this understanding with the DNS-SD experts and > then modify the XEP accordingly. I've talked about this with some of the DNS-SD folks, and yes the binary format is sent over the wire, whereas the texty format with multiple key-value pairs in a single TXT record value is the kind of thing that you would specify in, say, a BIND zone file. Peter -- Peter Saint-Andre https://stpeter.im/ From remko at el-tramo.be Thu Nov 13 01:37:07 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Thu, 13 Nov 2008 08:37:07 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: <491B4A42.1090900@stpeter.im> References: <4914D372.50506@stpeter.im> <4915B331.60000@isode.com> <491B4A42.1090900@stpeter.im> Message-ID: <133fd4c60811122337qdc8da4fi45b204d837b2cce@mail.gmail.com> > "It is RECOMMENDED that a client accept message stanzas containing the > attention extension only contacts that are in the user's roster or with > whome the user's client is currently sharing directed presence, mainly > to prevent the user from being annoyed by attention requests from random > entities on the network. A client could implement finer-grained control > if desired (e.g., allow attention requests only from entities in a > particular roster group)." Fine by me. > "Because some users might not want this feature to disturb them, a > client MUST either (1) allow the user to disable support or (2) disable > the feature by default and process attention requests only if the user > has explicitly enabled support." I don't really see the difference between 1 or 2. I think the poster meant 1 and 2. Anyway, I think we're slitting hairs with this spec. Let's hope there's equally much feedback on the more complicated specs in the future. cheers, Remko From Jehan.3it5zb at no-mx.jabberforum.org Thu Nov 13 03:55:54 2008 From: Jehan.3it5zb at no-mx.jabberforum.org (Jehan) Date: Thu, 13 Nov 2008 10:55:54 +0100 Subject: [Standards] Event for the 10th birthday of XMPP References: <4db9cacb0811122001i1fb6b2d5kffa4efbb7e29be05@mail.gmail.com> Message-ID: Hi, other people had similar ideas too, that's not so astonishing and probably gives a hint that it must be a good idea! ;-) Anyway what I see in this blog you gave the url is that Jack Moffitt proposes an online-only event. For my own, I wanted a physical event, even though I also thought there could be an online part of it. Like a central muc opened for this specific day, where people could participate, and there could have been a big screen above the conference places. With webcams (Jingle?!), they could follow what happens to the different events. Hence people all over the world could follow all the events, ask questions and discuss (even when they cannot move to one of the place it is organized)... That's about XMPP after all! That was still just an "idea", not thought throughout... And for the place to discuss this, let's keep this as the main place for now... Moreover I think such an event should not be developper-only. Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1073 From fippo at goodadvice.pages.de Thu Nov 13 05:27:35 2008 From: fippo at goodadvice.pages.de (Philipp Hancke) Date: Thu, 13 Nov 2008 12:27:35 +0100 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <30276.1226499171.333705@peirce.dave.cridland.net> References: <4914D3A4.3030405@stpeter.im> <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> <30276.1226499171.333705@peirce.dave.cridland.net> Message-ID: <491C0F27.7030307@goodadvice.pages.de> Dave Cridland wrote: > Well, going forward, I'm hoping we'll remove the need for dialback at > all. I'd like to hope it remains purely as a stub protocol for > connection reuse, and that db:verify simply disappears in a puff of > certificate equality checking. (Which it could do, I think). Get a large list of servers and check how often this would work in practice. I wonder if the old ratio of 1/10 from 2007 is still valid. If you want to remove dialback, maybe we should check if it can be replaced by a dns lookup. Historically I that dialback is a result of jabberd not binding to the proper ip address: http://mail.jabber.org/pipermail/xmppwg/2002-October/000155.html > Two questions: > > 1) Do any server implementations actually do piggybacking anymore? I have a recent log of gmail.com piggybacking googlemail.com. Philipp From Kurt.Zeilenga at Isode.com Thu Nov 13 13:50:05 2008 From: Kurt.Zeilenga at Isode.com (Kurt Zeilenga) Date: Thu, 13 Nov 2008 11:50:05 -0800 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <6e2f977f0811121345x4ad18026x921da81dd9a03f64@mail.gmail.com> References: <30276.1226523901.569488@peirce.dave.cridland.net> <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> <6e2f977f0811121345x4ad18026x921da81dd9a03f64@mail.gmail.com> Message-ID: <90A68B1A-51AC-43C4-AE7E-21E4749F6D94@Isode.com> On Nov 12, 2008, at 1:45 PM, Nicolas V?rit? wrote: > On Wed, Nov 12, 2008 at 10:40 PM, Remko Tron?on > wrote: >>> I appreciate that this is almost inexcusably trivial, but bear >>> with me. >> >> I say, let's put these hip state-of the art 4-color (or more!) >> displays finally to work! > > Color-coding is not enough: it is not accessible for the blinds or > visually impaired. We need more printed text (meta)data. One could imbed sound bites. Yes, I'm joking. I only wish Dave was. -- Kurt From editor at xmpp.org Thu Nov 13 14:33:39 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Thu, 13 Nov 2008 14:33:39 -0600 Subject: [Standards] DRAFT: XEP-0224 (Attention) Message-ID: Version 1.0 of XEP-0224 (Attention) has been released. Abstract: This document defines an XMPP protocol extension for getting the attention of another user. Changelog: Per a vote of the XMPP Council, advanced specification to Draft. (psa) Diff: http://is.gd/7nOr URL: http://www.xmpp.org/extensions/xep-0224.html From editor at xmpp.org Thu Nov 13 14:42:53 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Thu, 13 Nov 2008 14:42:53 -0600 Subject: [Standards] NEW: XEP-0253 (PubSub Chaining) Message-ID: Version 0.1 of XEP-0253 (PubSub Chaining) has been released. Abstract: This specification defines a method for chaining pubsub nodes together, resulting in lightweight repeaters for pubsub notifications. Changelog: Initial published version. (psa) Diff: initial version URL: http://www.xmpp.org/extensions/xep-0253.html From editor at xmpp.org Thu Nov 13 14:42:58 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Thu, 13 Nov 2008 14:42:58 -0600 Subject: [Standards] NEW: XEP-0254 (PubSub Queueing) Message-ID: Version 0.1 of XEP-0254 (PubSub Queueing) has been released. Abstract: This specification defines an extension to XMPP publish-subscribe for queueing information at a node. Changelog: Initial published version. (psa) Diff: initial version URL: http://www.xmpp.org/extensions/xep-0254.html From editor at xmpp.org Thu Nov 13 14:43:04 2008 From: editor at xmpp.org (XMPP Extensions Editor) Date: Thu, 13 Nov 2008 14:43:04 -0600 Subject: [Standards] NEW: XEP-0255 (Location Query) Message-ID: Version 0.1 of XEP-0255 (Location Query) has been released. Abstract: This specification defines an XMPP protocol extension for querying a compliant server for information about the geographical or physical location of an entity." Changelog: Initial published version. (psa) Diff: initial version URL: http://www.xmpp.org/extensions/xep-0255.html From stpeter at stpeter.im Thu Nov 13 17:14:19 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 13 Nov 2008 16:14:19 -0700 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> References: <30276.1226523901.569488@peirce.dave.cridland.net> <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> Message-ID: <491CB4CB.6080905@stpeter.im> Remko Tron?on wrote: >> I appreciate that this is almost inexcusably trivial, but bear with me. > > I say, let's put these hip state-of the art 4-color (or more!) > displays finally to work! > > Slightly related, I once wrote up a script that would generate a graph > of all XEP dependencies, and warn you about XEPs in draft state > depending on XEPs in experimental state (and other relations that > aren't allowed). The main flaw was that some XEPs refer to XEPs in > sentences like "This XEP replaces XEP xxx", in which case the > dependency *is* allowed. This could be solved by adding exceptions, or > adding extra sections to XEPs, ..., but I didn't really > bother. Maybe a tool like that could also be an addition to our XEP > consistency checking? Don't we have a element for this purpose? Peter -- Peter Saint-Andre https://stpeter.im/ From Jehan.3iubez at no-mx.jabberforum.org Thu Nov 13 18:50:22 2008 From: Jehan.3iubez at no-mx.jabberforum.org (Jehan) Date: Fri, 14 Nov 2008 01:50:22 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) References: <491B4B6C.9070601@stpeter.im> Message-ID: I saw that the change have already been published but still I give my answers. :-) Peter Saint-Andre;4967 Wrote: > > See my previous message with a revised security consideration. > The revised security consideration was part of my change proposition, so that's good. But another part was that this sentence in the implementation notes: > > Rate-limiting might be desirable in some implementations. > could become a security consideration as well. I personnaly think that a rate limitation is not *desirable*, but *recommended* to avoid abuse of this feature which could disturb your computer usage... Anyway as Remko said, the remaining details on this XEP are not major, so this is ok if it does not change now... But just one language point: > > contacts that are in the user's roster or with *whome* the user's > client is currently sharing directed presence > English is not my natural language, so maybe this is a syntax I don't know. So if it is an error from me, forgive me. But here, isn't it supposed to be a "whom", and not a "whome"? > "Because some users might not want this feature to disturb them, a > client MUST either (1) allow the user to disable support or (2) > disable > the feature by default and process attention requests only if the user > has explicitly enabled support." Fair enough. :-) Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=966 From remko at el-tramo.be Fri Nov 14 00:56:29 2008 From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=) Date: Fri, 14 Nov 2008 07:56:29 +0100 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <491CB4CB.6080905@stpeter.im> References: <30276.1226523901.569488@peirce.dave.cridland.net> <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> <491CB4CB.6080905@stpeter.im> Message-ID: <133fd4c60811132256y60a58380i7cb4e2d4d792670b@mail.gmail.com> > Don't we have a element for this purpose? I was wondering if I saw that before, or whether that was just a dream. Maybe it all works out if I look (and fix) those. I'll revisit the script one of these days. cheers, Remko From jig at monitzer.com Fri Nov 14 02:14:02 2008 From: jig at monitzer.com (Andreas Monitzer) Date: Fri, 14 Nov 2008 09:14:02 +0100 Subject: [Standards] LAST CALL: XEP-0224 (Attention) In-Reply-To: References: <491B4B6C.9070601@stpeter.im> Message-ID: <7CA23BAA-BC03-4CFE-A538-1070CEA147F6@monitzer.com> On Nov 14, 2008, at 01:50, Jehan wrote: >> contacts that are in the user's roster or with *whome* the user's >> client is currently sharing directed presence > > English is not my natural language, so maybe this is a syntax I don't > know. So if it is an error from me, forgive me. But here, isn't it > supposed to be a "whom", and not a "whome"? It isn't mine either, but I think I simply made a typo there, since I don't know that word :) Good catch. andy From Jehan.3iv3xn at no-mx.jabberforum.org Fri Nov 14 05:06:30 2008 From: Jehan.3iv3xn at no-mx.jabberforum.org (Jehan) Date: Fri, 14 Nov 2008 12:06:30 +0100 Subject: [Standards] LAST CALL: XEP-0205 (Best Practices to DiscourageDenial of Service Attacks) References: <4914D35D.2010507@stpeter.im><1AE889AA-4DB2-4024-9CA2-505731CFE96A@simplicidade.org><30276.1226500940.715149@peirce.dave.cridland.net> Message-ID: Hi, I don't have much feedback on XEP-0205. It seems good to me. But just a linguistic correction. On section "3. Potential Solutions", point 8: > > Limiting the number *of of* XML stanzas [...] > The "of" is doubled... Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=964 From stpeter at stpeter.im Fri Nov 14 09:24:35 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 14 Nov 2008 08:24:35 -0700 Subject: [Standards] XEPs in Pretty Colours. In-Reply-To: <133fd4c60811132256y60a58380i7cb4e2d4d792670b@mail.gmail.com> References: <30276.1226523901.569488@peirce.dave.cridland.net> <133fd4c60811121340r2484f5c5ja71629edd67198a0@mail.gmail.com> <491CB4CB.6080905@stpeter.im> <133fd4c60811132256y60a58380i7cb4e2d4d792670b@mail.gmail.com> Message-ID: <491D9833.2080700@stpeter.im> Remko Tron?on wrote: >> Don't we have a element for this purpose? > > I was wondering if I saw that before, or whether that was just a > dream. Maybe it all works out if I look (and fix) those. I'll revisit > the script one of these days. Currently we don't use the information in any automated way, but we could do so. We also have a element in specs that have been superseded. See for example XEP-0022 and XEP-0085 for the usage. So in XEP-0022 you'll find: XEP-0085 XEP-0184 And in XEP-0085: XEP-0022 (in part) If we want to use this metadata, we'll probably need to clean up the references so that they are not just text strings. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter at stpeter.im Fri Nov 14 12:08:06 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 14 Nov 2008 11:08:06 -0700 Subject: [Standards] [Fwd: Re: [jdev] BOM] Message-ID: <491DBE86.9060105@stpeter.im> FYI. I propose adding the following text to the character encoding section (12.6) of rfc3920bis: *** Note: Because it is mandatory for an XMPP implementation to support all and only the UTF-8 encoding and because UTF-8 always has the same byte order, an implementation MUST NOT send a byte order mark ("BOM") at the beginning of the data stream. *** -------- Original Message -------- Date: Thu, 13 Nov 2008 16:35:19 -0700 From: Peter Saint-Andre To: Jabber/XMPP software development list Subject: Re: [jdev] BOM Waqas Hussain wrote: > On Fri, Nov 7, 2008 at 11:06 AM, Jonathan Dickinson > wrote: >>> -----Original Message----- >>> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of Peter Saint-Andre >>> Sent: 07 November 2008 01:51 AM >>> To: Jabber/XMPP software development list >>> Subject: Re: [jdev] BOM >>> >>> Jonathan Dickinson wrote: >>>> Much obliged. As a case of interopability, maybe something like: >>>> entities MUST NOT send byte order marks, however, they MUST tolerate >>>> them. >>> I'm not sure exactly what "tolerate" means. >> Receiving entities shouldn't fall over when they get a BOM at the start of the stream: like the clients that I used to test my server did. >> >> -- Jonathan > > Considering that no servers send out BOMs, and pretty much no clients > do either, I don't really see much point in requiring all XMPP > software to handle BOMs. Having done a bit more research, my position is now this: given that XMPP is UTF-8 and that UTF-8 always has the same byte order, why would we ever need to include or support a byte order mark in XMPP? Peter From stpeter at stpeter.im Fri Nov 14 14:48:27 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 14 Nov 2008 13:48:27 -0700 Subject: [Standards] [Fwd: Re: [jdev] BOM] In-Reply-To: <491DBE86.9060105@stpeter.im> References: <491DBE86.9060105@stpeter.im> Message-ID: <491DE41B.5000305@stpeter.im> After a chat with Justin Karneges, I've changed it to read: *** Note: Because it is mandatory for an XMPP implementation to support all and only the UTF-8 encoding and because UTF-8 always has the same byte order, an implementation MUST NOT send a byte order mark ("BOM") at the beginning of the data stream. If an entity receives the Unicode character U+FEFF anywhere in an XML stream (including as the first character of the stream), it MUST interpret that character as a zero width no-break space, not as a byte order mark. *** Peter Saint-Andre wrote: > FYI. I propose adding the following text to the character encoding > section (12.6) of rfc3920bis: > > *** > > Note: Because it is mandatory for an XMPP implementation to support all > and only the UTF-8 encoding and because UTF-8 always has the same byte > order, an implementation MUST NOT send a byte order mark ("BOM") at the > beginning of the data stream. > > *** > > -------- Original Message -------- > Date: Thu, 13 Nov 2008 16:35:19 -0700 > From: Peter Saint-Andre > To: Jabber/XMPP software development list > Subject: Re: [jdev] BOM > > Waqas Hussain wrote: >> On Fri, Nov 7, 2008 at 11:06 AM, Jonathan Dickinson >> wrote: >>>> -----Original Message----- >>>> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of Peter Saint-Andre >>>> Sent: 07 November 2008 01:51 AM >>>> To: Jabber/XMPP software development list >>>> Subject: Re: [jdev] BOM >>>> >>>> Jonathan Dickinson wrote: >>>>> Much obliged. As a case of interopability, maybe something like: >>>>> entities MUST NOT send byte order marks, however, they MUST tolerate >>>>> them. >>>> I'm not sure exactly what "tolerate" means. >>> Receiving entities shouldn't fall over when they get a BOM at the start of the stream: like the clients that I used to test my server did. >>> >>> -- Jonathan >> Considering that no servers send out BOMs, and pretty much no clients >> do either, I don't really see much point in requiring all XMPP >> software to handle BOMs. > > Having done a bit more research, my position is now this: given that > XMPP is UTF-8 and that UTF-8 always has the same byte order, why would > we ever need to include or support a byte order mark in XMPP? > > Peter > > From stpeter at stpeter.im Fri Nov 14 17:35:41 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 14 Nov 2008 16:35:41 -0700 Subject: [Standards] XEP-0012: Summary of Call for Experience Message-ID: <491E0B4D.7040608@stpeter.im> The Call for Experience regarding the Draft spec XEP-0012 (Last Activity) ended 2008-10-31. This email summarizes the findings, with a focus on the three considerations mentioned in Section 8.1 of XEP-0001. (1) There are many implementations of this specification, including (a) jabberd 1.x and Openfire among XMPP servers and (b) Psi among XMPP clients. All of these implementations are open-source. (2) We received feedback regarding the possibility of using the last activity extension in presence stanzas. As a result, we have added a section to the specification about this usage. (3) The specification will be double-checked for accuracy before the XMPP Council votes on advancing it from Draft to Final. Peter -- Peter Saint-Andre https://stpeter.im/ From hildjj at gmail.com Sat Nov 15 22:27:15 2008 From: hildjj at gmail.com (Joe Hildebrand) Date: Sat, 15 Nov 2008 21:27:15 -0700 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <491C0F27.7030307@goodadvice.pages.de> References: <4914D3A4.3030405@stpeter.im> <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> <30276.1226499171.333705@peirce.dave.cridland.net> <491C0F27.7030307@goodadvice.pages.de> Message-ID: <59E7714B-3DE0-40DC-88F4-5F3D9EE3DD77@gmail.com> On Nov 13, 2008, at 4:27 AM, Philipp Hancke wrote: > If you want to remove dialback, maybe we should check if it can be > replaced by a dns lookup. Historically I that dialback is a result of > jabberd not binding to the proper ip address: > http://mail.jabber.org/pipermail/xmppwg/2002-October/000155.html There's a deployment reason for dialback. If you want your inbound and outbound connections on separate boxes, it's handy to not just rely on the IP address of the outbound server matching the one returned from DNS. From fippo at goodadvice.pages.de Mon Nov 17 03:10:16 2008 From: fippo at goodadvice.pages.de (Philipp Hancke) Date: Mon, 17 Nov 2008 10:10:16 +0100 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <4914D3A4.3030405@stpeter.im> References: <4914D3A4.3030405@stpeter.im> Message-ID: <492134F8.3040802@goodadvice.pages.de> Peter Saint-Andre wrote: > This Last Call has ended. I received some feedback off-list, which I > will consolidate and post to the list next week. Not neccessary. I finally had the time to fully read this version :-( 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes. 2. Does the specification solve the problem stated in the introduction and requirements? Probably. However, it should explain, why dialback is preferable over a simple DNS lookup. I can think of at least two reasons. 3. Do you plan to implement this specification in your code? No. My current implementation has worked well enough for five years. 4. Do you have any security concerns related to this specification? No. 5. Is the specification accurate and clearly written? No. See below for details. I have read various versions of this. RFC 3920, 3920bis, all versions of 220. The description has changed quite a lot in each version... Details: > (The XMPP Standards Foundation (XSF) [4] has worked to make > certificates easier to obtain by running the XMPP Intermediate > Certification Authority [5].) This 'advertisement' is completly misplaced. Anyone reading this spec wants to find out about dialback, not about the ICA. > because the certificate presented by the peer service during TLS > negotiation is self-signed and local service policies stipulate that > it is preferable to weakly identify the peer service via Server > Dialback rather than depend on the self-signed certificate for > identity verification. I think I criticized this sentence multiple times now, with no effect. Now I would like an explanation: what service policy _uses_ self- signed certificates for identity verification? Section 2 is very boring. I read RFC 3920, I know how to resolve addresses, how to open a connection etc. Why is this repeated? Most error cases described herein belong to 3920bis. > there is no IP address associated with this domain since it is merely > asserted by the Originating Server There is an ip address associated with this connection. Usually it is the 192.0.2.23, but for sake of the argument it is better to use a different address. > The Receiving Server SHOULD include the dialback feature I still do not see a reason for this. If the sending side is not using sasl, it will assume that is has to authenticate - using dialback. If SASL is used, dialback is unnecessary, at least according to the XEP. 2.2.1: I agree with what Matthias said in <45794891.8080305 at tthias.eu> . Jer came up with a smart method to check the dialback keys, but it is not the only way of doing it. Example 17+18: can not happen unless you piggyback. Otherwise, that error would have occured earlier (example 11). 2.5.2: what happens to the connection between receiving and authoritative server? As said before, this may be closed by the receiving server, however this is left unspecified here. The authoritative server MUST NOT close this connection. 2.5.3.1 > The Receiving Server then SHOULD also terminate the XML stream and the > underlying TCP connection between the Receiving Server and the > Authoritative Server. MAY also terminate. Closing this connection makes no sense usually. 3. > Support for piggybacking is OPTIONAL. This is consensus? I certainly disagree, even though I used to highly dislike piggybacking. The passive part of piggybacking is not difficult to implement. > db:result type='error' Not necessary if the spec demands support for (passive) piggybacking. The specification fails to describe 2-connection dialback and 3-connection dialback. The former is reusing the R2A connection as the new O2R, the latter opens a TCP connection just for the verification of the dialback key. Usually, this will also use SSL for that, which then results in even more roundtrips and perceived latency. From fippo at goodadvice.pages.de Mon Nov 17 03:24:17 2008 From: fippo at goodadvice.pages.de (Philipp Hancke) Date: Mon, 17 Nov 2008 10:24:17 +0100 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <59E7714B-3DE0-40DC-88F4-5F3D9EE3DD77@gmail.com> References: <4914D3A4.3030405@stpeter.im> <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> <30276.1226499171.333705@peirce.dave.cridland.net> <491C0F27.7030307@goodadvice.pages.de> <59E7714B-3DE0-40DC-88F4-5F3D9EE3DD77@gmail.com> Message-ID: <49213841.30908@goodadvice.pages.de> Joe Hildebrand schrieb: > > On Nov 13, 2008, at 4:27 AM, Philipp Hancke wrote: >> If you want to remove dialback, maybe we should check if it can be >> replaced by a dns lookup. Historically I that dialback is a result of >> jabberd not binding to the proper ip address: >> http://mail.jabber.org/pipermail/xmppwg/2002-October/000155.html > > There's a deployment reason for dialback. If you want your inbound and > outbound connections on separate boxes, it's handy to not just rely on > the IP address of the outbound server matching the one returned from DNS. I have not seen any strictly separated inbound and outbound boxes for quite some time. Even gmail does not use this feature (they connect from 209.85.163.125, aka xmpp-server4.l.google.com (which is contained in the set of names returned when looking up _xmpp-server._tcp.gmail.com). There is another reason why dialback is better than a simple dns lookup. It protects against evil shell users on the originating server that are able to open connections using its address. From Jehan.3j0l0o at no-mx.jabberforum.org Mon Nov 17 04:03:51 2008 From: Jehan.3j0l0o at no-mx.jabberforum.org (Jehan) Date: Mon, 17 Nov 2008 11:03:51 +0100 Subject: [Standards] Event for the 10th birthday of XMPP References: <4db9cacb0811122001i1fb6b2d5kffa4efbb7e29be05@mail.gmail.com> Message-ID: Hi, noone is interested by this idea on this list? Or is it that we should really discuss this elsewhere? Maybe I will try to forward this to jdev as proposed by Matthew. Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1073 From nicolas.verite at gmail.com Mon Nov 17 05:52:16 2008 From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=) Date: Mon, 17 Nov 2008 12:52:16 +0100 Subject: [Standards] Event for the 10th birthday of XMPP In-Reply-To: References: <4db9cacb0811122001i1fb6b2d5kffa4efbb7e29be05@mail.gmail.com> Message-ID: <6e2f977f0811170352y32fc9158m7ca1062271e19974@mail.gmail.com> Of course I'm interested in it (as I told you). I offer you my help. Worldwide events could take the same shape as Mozilla, Ubuntu and Mandriva do. IMHO, a central place (like the XSF) should be the place where we collaborate, and decline locally, as the organizers wish/can. We can rely on User Groups of course, like Linux/Unix and free/opensource software User Groups, and also maybe companies working around XMPP. N?co On Mon, Nov 17, 2008 at 11:03 AM, Jehan wrote: > > Hi, > > noone is interested by this idea on this list? Or is it that we should > really discuss this elsewhere? Maybe I will try to forward this to jdev > as proposed by Matthew. > > Jehan > > > -- > Jehan > ------------------------------------------------------------------------ > Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 > View this thread: http://www.jabberforum.org/showthread.php?t=1073 > > -- Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com Jabber ID : xmpp:nyco at jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adh?rez ? l'April : http://april.org/ From Jehan.3j0skb at no-mx.jabberforum.org Mon Nov 17 06:46:20 2008 From: Jehan.3j0skb at no-mx.jabberforum.org (Jehan) Date: Mon, 17 Nov 2008 13:46:20 +0100 Subject: [Standards] Event for the 10th birthday of XMPP References: <4db9cacb0811122001i1fb6b2d5kffa4efbb7e29be05@mail.gmail.com> <6e2f977f0811170352y32fc9158m7ca1062271e19974@mail.gmail.com> Message-ID: Hi, Nicolas V?rit?;5029 Wrote: > Of course I'm interested in it (as I told you). I offer you my help. > I knew you were... But I was expecting also other reactions that the ones I already knew! :p > > Worldwide events could take the same shape as Mozilla, Ubuntu and > Mandriva do. > Yes. For my own, I especially know the Mozilla ones, because I have been to a few of them as spectator. And that's really well done and organized. > > IMHO, a central place (like the XSF) should be the place where we > collaborate, and decline locally, as the organizers wish/can. We can > rely on User Groups of course, like Linux/Unix and free/opensource > software User Groups, and also maybe companies working around XMPP. > > N?co > How I see it (subject to change with discussion with anyone, just the first ideas I had): - Voluntaries (as Nyco and I) would propose their help, would organize, etc. - As I am giving my time and my help, I don't mind using money. But honestly I am young, with a simple job, hence not very rich. I cannot handle by my own financially this. This is one of the point I think the XSF can help. For instance by having some interesting people come to the events when they are not leaving close for speaking in conferences, etc. - Also it would be great if we could have goodies in all such events. Very simple stuffs like t-shirts are perfect. That's exactly the kind of stuffs that Mozilla is doing in their events and that's nice for the people coming and wearing fiercely a t-shirt of the event they have come to (there could be some event-personnalized text "10th birthday of XMPP" and a localized "motto", something like "Speak Free!", or whatever else comes to the mind of clever people out there...). I think this kind of stuff should be done with XSF help too... - We should get help from locale LUG, definitely. - As I told, we must have interesting people coming for a speech. This can be very innovative people in the community, representatives from the XSF (Peter, don't you want to visit Paris?! :p), representatives from some company involved in XMPP development (there can be small companies, more or less locale, or even big worldwide companies. I think having someone from Google can be nice; talking about what they are doing, what they plan to do, etc.). - Inviting some medias... technical (or not) newspaper (or even TV?! Especially if we have nice representatives from companies, it could attract them), explaining that XMPP is the standards for IM, not a social network, etc. - Showing demos, like a video chat through Jingle with other events around the world (if some of them are the same days and the jet lag enable this), and even by making an "Birthday event official chatroom" on a XMPP server, where all people could connect and discuss. If they can see the conferences with live webcams, they could ask questions through the chat, which could be shown on a big screen in the place. Or other similar funny ideas. :-) - For the time, it could be a week-end in january... THE PARIS EVENT As I told, I propose to organize such event in Paris. I will get information for having the authorizations, all typical organization stuffs, etc. I think all materials can be get from benevolents, LUGs, etc. Nyco proposed a bar in Paris where there are many similar technical events (called "La Cantine", among other things, the last mozilla events in Paris, a "plugin developper workshop" has been held there). But for information, I can also propose a nice place, which is a huge house in Paris, bigger than La Cantine, with a big room for conference (indeed usually a danse studio, so lot of place). And it has internet connection, of course. So here are my basic ideas. I think the main point for beginning to organize such event is XSF involvement in it. This works well with all other foundations (as Nyco mentionned: Mozilla, Mandriva, Ubuntu, the FSF, etc.). Jehan P.S.: as FSF set the Jingle implementation in their high priorities, maybe we can also get help from them? -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1073 From hildjj at gmail.com Mon Nov 17 16:36:20 2008 From: hildjj at gmail.com (Joe Hildebrand) Date: Mon, 17 Nov 2008 16:36:20 -0600 Subject: [Standards] LAST CALL: XEP-0220 (Server Dialback) In-Reply-To: <49213841.30908@goodadvice.pages.de> References: <4914D3A4.3030405@stpeter.im> <4B24784B-B42F-4D71-A40D-54FF391DFC19@simplicidade.org> <30276.1226499171.333705@peirce.dave.cridland.net> <491C0F27.7030307@goodadvice.pages.de> <59E7714B-3DE0-40DC-88F4-5F3D9EE3DD77@gmail.com> <49213841.30908@goodadvice.pages.de> Message-ID: On Nov 17, 2008, at 3:24 AM, Philipp Hancke wrote: > I have not seen any strictly separated inbound and outbound boxes for > quite some time. Even gmail does not use this feature (they connect > from > 209.85.163.125, aka xmpp-server4.l.google.com (which is contained in > the > set of names returned when looking up _xmpp-server._tcp.gmail.com). > > There is another reason why dialback is better than a simple dns > lookup. > It protects against evil shell users on the originating server that > are > able to open connections using its address. Since there exists a good reason that we agree on, we don't have to agree on the first one. :) From stpeter at stpeter.im Mon Nov 17 18:33:42 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon, 17 Nov 2008 17:33:42 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <491B4D53.80402@stpeter.im> References: <49121783.5050002@stpeter.im> <200811062200.40830.justin-keyword-jabber.093179@affinix.com> <49146DFF.1050400@stpeter.im> <200811070913.30007.justin-keyword-jabber.093179@affinix.com> <49148352.3090008@stpeter.im> <491B4D53.80402@stpeter.im> Message-ID: <49220D66.6010207@stpeter.im> Peter Saint-Andre wrote: > Peter Saint-Andre wrote: >> Justin Karneges wrote: >>> On Friday 07 November 2008 08:34:07 Peter Saint-Andre wrote: >>>> Right, so the question is not "what format is sent over the wire?" (as >>>> we can see that's the fancy encoding to save space and indicate the >>>> length of each key-value pair) but "what is the format that an entity >>>> publishes to the mdns address?" (and that might be a text-based notation >>>> with each key-value pair contained within quotes). In any case, I think >>>> that what's currently in XEP-0174 is wrong because you don't publish one >>>> TXT record for each key-value pair, instead you publish a single TXT >>>> record that contains all of the key-value pairs. >>> Correct. A single TXT record contains all the strings. >>> >>>> So that means you publish something like this (it would be all one "line" >>>> in DNS but I can't show that in email): >>>> >>>> juliet at pronto._presence._tcp.local. IN TXT "txtvers=1" "1st=Juliet" >>>> "email=juliet at capulet.lit" "hash=sha-1" "jid=juliet at capulet.lit" >>>> "last=Capulet" "msg=Hanging out downtown" "nick=JuliC" >>>> "node=http://www.adiumx.com" >>>> "phsh=a3839614e1a382bcfebbcf20464f519e81770813" "port.p2pj=5562" >>>> "status=avail" "vc=CA!" "ver=QgayPKawpkPSDYmwT/WM94uAlu0=" >>>> >>>> Yes, no, maybe? >>> Yes. >> Right. I will confirm this understanding with the DNS-SD experts and >> then modify the XEP accordingly. > > I've talked about this with some of the DNS-SD folks, and yes the binary > format is sent over the wire, whereas the texty format with multiple > key-value pairs in a single TXT record value is the kind of thing that > you would specify in, say, a BIND zone file. Therefore I propose the following text: *** 3.1 TXT Record DNS-SD enables service definitions to include a TXT record that specifies parameters to be used in the context of the relevant service type. The name of the TXT record is the same as that of the SRV record (i.e., "user at machine._presence._tcp.local."). When the TXT record is sent over the wire, its value is a binary object that contains one or more strings, where (1) each string is a parameter that usually takes the form of a key-value pair and (2) the parameters are separated by a single-length byte ("0x##") that specifies the length of the parameter itself. For detailed information about the format of the TXT record value, refer to the DNS-SD specification. Note: The format used for publishing the TXT record value to the mDNS daemon depends on the mDNS daemon in use, and might not follow the binary format described here (e.g., it might consist of a series of quoted strings, one for each parameter). The following truncated example illustrates the wire format. -------------------------------------------------------------------------- | 0x09 | txtvers=1 | 0x0A | 1st=Juliet | 0x18 | email=juliet at capulet.lit | -------------------------------------------------------------------------- *** /psa From justin-keyword-jabber.093179 at affinix.com Mon Nov 17 23:50:34 2008 From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges) Date: Mon, 17 Nov 2008 21:50:34 -0800 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <49220D66.6010207@stpeter.im> References: <49121783.5050002@stpeter.im> <491B4D53.80402@stpeter.im> <49220D66.6010207@stpeter.im> Message-ID: <200811172150.34565.justin-keyword-jabber.093179@affinix.com> On Monday 17 November 2008 16:33:42 Peter Saint-Andre wrote: > Note: The format used for publishing the TXT record value to the mDNS > daemon depends on the mDNS daemon in use, and might not follow the > binary format described here (e.g., it might consist of a series of > quoted strings, one for each parameter). Humm, there is something goofy about this text. At the high level, a TXT record holds a list of strings; it's a container for a string list. It should be enough for XEP-174 to simply say, "the TXT record must contain the following strings..." and be done with it. It shouldn't need to detail out the actual binary representation of the TXT record. To put it in perspective, XEP-174 also states what should go into an SRV record (host, port, priority, weight), but it doesn't discuss the binary format of SRV. If anyone cares about how TXT or SRV records get formatted, they can read other specs to find out. I think what makes the text confusing is the part about interfacing with an mDNS daemon. Certainly "it might consist of a series of quoted strings" is too hopeful, as nothing uses that text-based notation except BIND zone files. It is true that different mDNS programming interfaces may each have different ways to specify the TXT content, but the same goes for specifying the SRV content. I assure you that, to an mDNS programming interface, SRV is never specified with zone file notation nor binary format. Instead, it's stuff like "char *hostname" and "int port". I guess what I'm trying to say is that you shouldn't explain the binary representation of any of the record types. Instead, stick to high level explanations, which readers can then apply in concept to their relevant programming interfaces. That text-based zone file notation you're already using should suffice as a high level explanation. Nobody's actually going to use that zone file notation in their programming, but they should be able to read it and figure out what you mean. -Justin From dave at cridland.net Tue Nov 18 10:53:28 2008 From: dave at cridland.net (Dave Cridland) Date: Tue, 18 Nov 2008 16:53:28 +0000 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <200811172150.34565.justin-keyword-jabber.093179@affinix.com> References: <49121783.5050002@stpeter.im> <491B4D53.80402@stpeter.im> <49220D66.6010207@stpeter.im> <200811172150.34565.justin-keyword-jabber.093179@affinix.com> Message-ID: <5827.1227027208.824527@peirce.dave.cridland.net> On Tue Nov 18 05:50:34 2008, Justin Karneges wrote: > On Monday 17 November 2008 16:33:42 Peter Saint-Andre wrote: > > Note: The format used for publishing the TXT record value to the > mDNS > > daemon depends on the mDNS daemon in use, and might not follow the > > binary format described here (e.g., it might consist of a series > of > > quoted strings, one for each parameter). > > Humm, there is something goofy about this text. > > At the high level, a TXT record holds a list of strings; it's a > container for > a string list. It should be enough for XEP-174 to simply say, "the > TXT > record must contain the following strings..." and be done with it. > It > shouldn't need to detail out the actual binary representation of > the TXT > record. > > Agreed. > To put it in perspective, XEP-174 also states what should go into > an SRV > record (host, port, priority, weight), but it doesn't discuss the > binary > format of SRV. If anyone cares about how TXT or SRV records get > formatted, > they can read other specs to find out. > > And also agreed. This is one of the failings of the DNS-SD spec itself, too, which is currently in Last Call in the IETF. It's actually entirely due to the DNS-SD specification that the entire mess arose in the first place, and I've argued (in the IETF) that the specification ought to be pulled as a result. Actually, I've argued that it ought to be pulled and reworked into a Standards Track document, too, because of its importance to specifications like XEP-0174, and the P2PSIP equivalents. > I guess what I'm trying to say is that you shouldn't explain the > binary > representation of any of the record types. Instead, stick to high > level > explanations, which readers can then apply in concept to their > relevant > programming interfaces. That text-based zone file notation you're > already > using should suffice as a high level explanation. Nobody's > actually going to > use that zone file notation in their programming, but they should > be able to > read it and figure out what you mean. +3.1415927 People can use the dig tool to extract zone-file-like formatting from mDNS and/or uDNS DNS-SD records, and see what the data is actually saying for debugging etc, which makes zone file format very convenient. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter at stpeter.im Tue Nov 18 23:09:35 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 18 Nov 2008 22:09:35 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <200811172150.34565.justin-keyword-jabber.093179@affinix.com> References: <49121783.5050002@stpeter.im> <491B4D53.80402@stpeter.im> <49220D66.6010207@stpeter.im> <200811172150.34565.justin-keyword-jabber.093179@affinix.com> Message-ID: <49239F8F.1020105@stpeter.im> Justin Karneges wrote: > On Monday 17 November 2008 16:33:42 Peter Saint-Andre wrote: >> Note: The format used for publishing the TXT record value to the mDNS >> daemon depends on the mDNS daemon in use, and might not follow the >> binary format described here (e.g., it might consist of a series of >> quoted strings, one for each parameter). > > Humm, there is something goofy about this text. > > At the high level, a TXT record holds a list of strings; it's a container for > a string list. It should be enough for XEP-174 to simply say, "the TXT > record must contain the following strings..." and be done with it. It > shouldn't need to detail out the actual binary representation of the TXT > record. Yes, that makes sense. I was misled by the DNS-SD spec into thinking that this mattered for XEP-0174. /psa From stpeter at stpeter.im Tue Nov 18 23:10:59 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 18 Nov 2008 22:10:59 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <5827.1227027208.824527@peirce.dave.cridland.net> References: <49121783.5050002@stpeter.im> <491B4D53.80402@stpeter.im> <49220D66.6010207@stpeter.im> <200811172150.34565.justin-keyword-jabber.093179@affinix.com> <5827.1227027208.824527@peirce.dave.cridland.net> Message-ID: <49239FE3.4070200@stpeter.im> Dave Cridland wrote: > +3.1415927 Why approximate? Just say +? and be done with it. :P /psa From stpeter at stpeter.im Tue Nov 18 23:22:30 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 18 Nov 2008 22:22:30 -0700 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <49239F8F.1020105@stpeter.im> References: <49121783.5050002@stpeter.im> <491B4D53.80402@stpeter.im> <49220D66.6010207@stpeter.im> <200811172150.34565.justin-keyword-jabber.093179@affinix.com> <49239F8F.1020105@stpeter.im> Message-ID: <4923A296.8030907@stpeter.im> Peter Saint-Andre wrote: > Justin Karneges wrote: >> On Monday 17 November 2008 16:33:42 Peter Saint-Andre wrote: >>> Note: The format used for publishing the TXT record value to the mDNS >>> daemon depends on the mDNS daemon in use, and might not follow the >>> binary format described here (e.g., it might consist of a series of >>> quoted strings, one for each parameter). >> Humm, there is something goofy about this text. >> >> At the high level, a TXT record holds a list of strings; it's a container for >> a string list. It should be enough for XEP-174 to simply say, "the TXT >> record must contain the following strings..." and be done with it. It >> shouldn't need to detail out the actual binary representation of the TXT >> record. > > Yes, that makes sense. I was misled by the DNS-SD spec into thinking > that this mattered for XEP-0174. List consensus incorporated here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0174.xml /psa From dave at cridland.net Wed Nov 19 03:07:09 2008 From: dave at cridland.net (Dave Cridland) Date: Wed, 19 Nov 2008 09:07:09 +0000 Subject: [Standards] [Fwd: [Council] meeting minutes, 2008-11-05] In-Reply-To: <49239FE3.4070200@stpeter.im> References: <49121783.5050002@stpeter.im> <491B4D53.80402@stpeter.im> <49220D66.6010207@stpeter.im> <200811172150.34565.justin-keyword-jabber.093179@affinix.com> <5827.1227027208.824527@peirce.dave.cridland.net> <49239FE3.4070200@stpeter.im> Message-ID: <5827.1227085629.605360@peirce.dave.cridland.net> On Wed Nov 19 05:10:59 2008, Peter Saint-Andre wrote: > Dave Cridland wrote: > > > +3.1415927 > > Why approximate? Just say +? and be done with it. :P I should have said +2.7182818285 instead, it'd have been easier to type. Dave -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From Jehan.3j6imn at no-mx.jabberforum.org Thu Nov 20 08:57:06 2008 From: Jehan.3j6imn at no-mx.jabberforum.org (Jehan) Date: Thu, 20 Nov 2008 15:57:06 +0100 Subject: [Standards] XEP-0060: Example 89. Publisher publishes an item with an ItemID Message-ID: Hi, I think to have found a small miss in the XEP-0060 (pubsub). The Example 89 is called "Publisher publishes an item with an ItemID"... But it has no item id! The example is: > to='pubsub.shakespeare.lit' id='publish1'> > > > > > Soliloquy > To be, or not to be: that is the question: Whether 'tis > nobler in the mind to suffer The slings and arrows of outrageous > fortune, Or to take arms against a sea of troubles, And by opposing end > them? > href='http://denmark.lit/2003/12/13/atom03'/> > tag:denmark.lit,2003:entry-32397 > 2003-12-13T18:30:02Z > 2003-12-13T18:30:02Z > > > > > According to the text just before: > The element provided by the publisher MAY possess an 'id' > attribute, specifying a unique ItemID for the item. If an ItemID is not > provided in the publish request, the pubsub service MUST generate one > and MUST ensure that it is unique for that node. I guess it should be: > to='pubsub.shakespeare.lit' id='publish1'> > > > > > Soliloquy > To be, or not to be: that is the question: Whether 'tis > nobler in the mind to suffer The slings and arrows of outrageous > fortune, Or to take arms against a sea of troubles, And by opposing end > them? > href='http://denmark.lit/2003/12/13/atom03'/> > tag:denmark.lit,2003:entry-32397 > 2003-12-13T18:30:02Z > 2003-12-13T18:30:02Z > > > > > Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1106 From Jehan.3j6kan at no-mx.jabberforum.org Thu Nov 20 09:33:30 2008 From: Jehan.3j6kan at no-mx.jabberforum.org (Jehan) Date: Thu, 20 Nov 2008 16:33:30 +0100 Subject: [Standards] XEP-0060: Example 89. Publisher publishes an item with an ItemID References: Message-ID: Hi again, I have two other remarks I have just noticed. 1/ When one queries a "item discovery", an item has a "name" attribute which is the itemID (see 'section 5.5' (http://xmpp.org/extensions/xep-0060.html#entity-discoveritems)): > The 'name' attribute of each Service Discovery item MUST contain its > ItemID and the item MUST NOT possess a 'node' attribute. But in this section '6.4 Retrieve Items from a Node' (http://xmpp.org/extensions/xep-0060.html#subscriber-retrieve), or during publication (cf. my previous email), the itemID is an attribute 'id'. So I think this is not very consistent. Why is the attribute "name" used sometimes, and "id" other times for the same thing? 2/ Note also that it says that (section 5.5 again): > This ItemID MAY then be used to retrieve the item using the protocol > defined in the Retrieve Items from a Node section of this document. But in the "retrieve items" section, there is no mean proposed to request items based on IDs! The only section which propose to detail a request is section "6.4.7 Requesting Some Items", but it gives only examples to request the most recent items (with "max_items" attribute"). I guess you may use the jabber search XEP ('xep-0055' (http://xmpp.org/extensions/xep-0055.html)), or maybe use the 'result set management' (http://xmpp.org/extensions/xep-0059.html), but then the text is not good and must be changed in section 5.5. Moreover I don't think this adresses exactly the same needs. One should be able to request only one or two specific items (when we know the itemID) without having to request everything then search in it with the result set management... Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1106 From stpeter at stpeter.im Thu Nov 20 11:51:18 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 20 Nov 2008 10:51:18 -0700 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> Message-ID: <4925A396.7080808@stpeter.im> Pedro Melo wrote: > > On Oct 15, 2008, at 7:14 PM, Peter Saint-Andre wrote: > >> Peter Saint-Andre wrote: >>> Remko Tron?on wrote: >>> >>>> But I agree that caps should be preferred over the old method. >>> >>> +1 >> >> BTW, I think the old method was there for the transition from message >> events (XEP-0022) to chat state notifications. So perhaps it's time to >> rip that out and just talk about caps/disco. > > +1. I've been thinking about this more. Yes, service discovery and entity capabilities provide the right tools for the job here. The concern was caused by the use of XEP-0022 (Message Events) in older clients. Support for message events was not determined by service discovery because that protocol predated XEP-0030 by several years. Therefore your client could get in this strange state of wanting to use chat state notifications but ending up using message events. I see two paths forward: 1. Use disco/caps only (no implicit discovery) for chat state notifications and just wait for XEP-0022 clients to eventually disappear from the network. 2. Clean up the implicit discovery algorithm so that it reads something like this: *** In the absence of explicit discovery or negotiation, the User MAY implicitly request and discover the use of chat state notifications in a one-to-one chat session by adhering to the following business rules: 1. If the User desires chat state notifications, the message(s) that it sends to the Contact before receiving a reply MUST contain a chat state notification extension, which SHOULD be . 2. If the Contact replies but does not include a chat state notification extension, the User MUST NOT send subsequent chat state notifications to the Contact. 3. If the Contact replies and includes an notification (or sends a standalone notification to the User), the User and Contact SHOULD send subsequent notifications for supported chat states (as specified in the next subsection) by including an notification in each content message and sending standalone notifications for the chat states they support (at a minimum, the state). *** Notice that this gets rid of the idea of the "initial content message" and instead says that you send chat state notifications in all of the messages you send to the contact before receiving a reply. If the contact advertises support for XEP-0085 via disco/caps but never sends a chat state notification, the user would stop sending notifications. This saves some traffic, but I don't know how likely this scenario is. Thoughts? /psa From stpeter at stpeter.im Thu Nov 20 12:06:41 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 20 Nov 2008 11:06:41 -0700 Subject: [Standards] XEP-0085: Summary of Call for Experience Message-ID: <4925A731.5030801@stpeter.im> The Call for Experience regarding the Draft spec XEP-0085 (Chat State Notifications) ended 2008-10-31. This email summarizes the findings, with a focus on the three considerations mentioned in Section 8.1 of XEP-0001. 1. Implementations. There are numerous implementations of this specification, including the Gajim, Psi, Spark, and Transverse clients (which are open-source). 2. Feedback. We received feedback regarding the implicit discovery algorithm, specifically whether to (1) modify it by specifying that the User shall send in all messages unless it receives a reply with no chat state notification or (2) remove it entirely in favor of explicit discovery via service discovery (XEP-0030) or entity capabilities (XEP-0115). Discussion of this issue is ongoing. 3. Accuracy. The specification has been double-checked for accuracy by the XEP Editor, but further reviews would be helpful. Peter -- Peter Saint-Andre https://stpeter.im/ From js-xmpp-standards at webkeks.org Thu Nov 20 12:09:47 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Thu, 20 Nov 2008 19:09:47 +0100 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: <4925A396.7080808@stpeter.im> References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> Message-ID: Am 20.11.2008 um 18:51 schrieb Peter Saint-Andre: > 1. Use disco/caps only (no implicit discovery) for chat state > notifications and just wait for XEP-0022 clients to eventually > disappear > from the network. I vote for that one :) -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081120/0f11082b/attachment.pgp From stpeter at stpeter.im Thu Nov 20 12:53:40 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 20 Nov 2008 11:53:40 -0700 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> Message-ID: <4925B234.5090407@stpeter.im> Jonathan Schleifer wrote: > Am 20.11.2008 um 18:51 schrieb Peter Saint-Andre: > >> 1. Use disco/caps only (no implicit discovery) for chat state >> notifications and just wait for XEP-0022 clients to eventually disappear >> from the network. > > I vote for that one :) A few questions for the list: 1. What if you don't share presence with the other party and therefore can't receive caps data? I assume you'd need to send a service discovery request or share directed presence. 2. If you don't know (via disco/caps) that the other party supports XEP-0085, does the spec need to say that you (a) "MUST NOT" or (b) "SHOULD NOT" send chat state notifications? /psa From js-xmpp-standards at webkeks.org Thu Nov 20 12:58:01 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Thu, 20 Nov 2008 19:58:01 +0100 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: <4925B234.5090407@stpeter.im> References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> <4925B234.5090407@stpeter.im> Message-ID: <6B8676EA-C10B-4CF0-BEE5-61DFC0D764CE@webkeks.org> Am 20.11.2008 um 19:53 schrieb Peter Saint-Andre: > 1. What if you don't share presence with the other party and therefore > can't receive caps data? I assume you'd need to send a service > discovery > request or share directed presence. That is some thing we need to rework anyway, I think. IMO, when we don't share presence, we should send a directed presence directly after the first message - this should be a seperate XEP or even part of XMPP Messaging or Core. When we close the chat window (or manually using some button in the client), we could send an unavailable presence again - and also when we disconnect, of course. Same for invisibility. It is incredible annoying when someone who's invisible messages you and lots of stuff doesn't work therefore (like sending a file). > 2. If you don't know (via disco/caps) that the other party supports > XEP-0085, does the spec need to say that you (a) "MUST NOT" or (b) > "SHOULD NOT" send chat state notifications? A "MUST NOT" would mean all old clients break it, so I think a "SHOULD NOT" is better. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081120/ded4d9b9/attachment.pgp From stpeter at stpeter.im Thu Nov 20 13:14:49 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 20 Nov 2008 12:14:49 -0700 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: <6B8676EA-C10B-4CF0-BEE5-61DFC0D764CE@webkeks.org> References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> <4925B234.5090407@stpeter.im> <6B8676EA-C10B-4CF0-BEE5-61DFC0D764CE@webkeks.org> Message-ID: <4925B729.4060404@stpeter.im> Jonathan Schleifer wrote: > Am 20.11.2008 um 19:53 schrieb Peter Saint-Andre: > >> 1. What if you don't share presence with the other party and therefore >> can't receive caps data? I assume you'd need to send a service discovery >> request or share directed presence. > > That is some thing we need to rework anyway, I think. IMO, when we don't > share presence, we should send a directed presence directly after the > first message - this should be a seperate XEP or even part of XMPP > Messaging or Core. Oh for sure, it doesn't belong in XEP-0085, because it applies to all chat sessions in general. In rfc3921bis you will find the following text as a recommended best practice for chat sessions: If a user exchanges message stanzas with another entity but does not share presence with the entity based on a presence subscription, it is RECOMMENDED for the user's client to send directed presence to the other entity. > When we close the chat window (or manually using some button in the > client), we could send an unavailable presence again - and also when we > disconnect, of course. Same for invisibility. It is incredible annoying > when someone who's invisible messages you and lots of stuff doesn't work > therefore (like sending a file). I don't agree with sending unavailable when you close the chat window. You might close it right before your contact sends you another reply and then what is their client supposed to do? That seems unnecessary. When you go offline your server will send unavailable, and that seems good enough to me. >> 2. If you don't know (via disco/caps) that the other party supports >> XEP-0085, does the spec need to say that you (a) "MUST NOT" or (b) >> "SHOULD NOT" send chat state notifications? > > A "MUST NOT" would mean all old clients break it, so I think a "SHOULD > NOT" is better. I'm fine with SHOULD NOT. Peter -- Peter Saint-Andre https://stpeter.im/ From js-xmpp-standards at webkeks.org Thu Nov 20 13:22:32 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Thu, 20 Nov 2008 20:22:32 +0100 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: <4925B729.4060404@stpeter.im> References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> <4925B234.5090407@stpeter.im> <6B8676EA-C10B-4CF0-BEE5-61DFC0D764CE@webkeks.org> <4925B729.4060404@stpeter.im> Message-ID: Am 20.11.2008 um 20:14 schrieb Peter Saint-Andre: > In rfc3921bis you will find the following text as a recommended best > practice for chat sessions: > > If a user exchanges message stanzas with another entity > but does not share presence with the entity based on a > presence subscription, it is RECOMMENDED for the user's > client to send directed presence to the other entity. Could we change RECOMMENDED to SHOULD? > I don't agree with sending unavailable when you close the chat window. > You might close it right before your contact sends you another reply > and > then what is their client supposed to do? That seems unnecessary. When > you go offline your server will send unavailable, and that seems good > enough to me. Well, but maybe have an easy way in the GUI to hide your presence from that users again, so you don't need to relog to hide again :). -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081120/b247bc3b/attachment.pgp From stpeter at stpeter.im Thu Nov 20 13:30:06 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 20 Nov 2008 12:30:06 -0700 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> <4925B234.5090407@stpeter.im> <6B8676EA-C10B-4CF0-BEE5-61DFC0D764CE@webkeks.org> <4925B729.4060404@stpeter.im> Message-ID: <4925BABE.8000506@stpeter.im> Jonathan Schleifer wrote: > Am 20.11.2008 um 20:14 schrieb Peter Saint-Andre: > >> In rfc3921bis you will find the following text as a recommended best >> practice for chat sessions: >> >> If a user exchanges message stanzas with another entity >> but does not share presence with the entity based on a >> presence subscription, it is RECOMMENDED for the user's >> client to send directed presence to the other entity. > > Could we change RECOMMENDED to SHOULD? RECOMMENDED means the same thing as SHOULD. :) So the following are equivalent: "It is RECOMMENDED for a client to do X" "A client SHOULD do X" >> I don't agree with sending unavailable when you close the chat window. >> You might close it right before your contact sends you another reply and >> then what is their client supposed to do? That seems unnecessary. When >> you go offline your server will send unavailable, and that seems good >> enough to me. > > Well, but maybe have an easy way in the GUI to hide your presence from > that users again, so you don't need to relog to hide again :). Don't share presence in the first place. :P Peter -- Peter Saint-Andre https://stpeter.im/ From js-xmpp-standards at webkeks.org Thu Nov 20 13:36:55 2008 From: js-xmpp-standards at webkeks.org (Jonathan Schleifer) Date: Thu, 20 Nov 2008 20:36:55 +0100 Subject: [Standards] Call for Experience: XEP-0085 (Chat State Notifications) In-Reply-To: <4925BABE.8000506@stpeter.im> References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> <4925B234.5090407@stpeter.im> <6B8676EA-C10B-4CF0-BEE5-61DFC0D764CE@webkeks.org> <4925B729.4060404@stpeter.im> <4925BABE.8000506@stpeter.im> Message-ID: <3F91D9D9-E094-4F17-B4DF-488B9EE69128@webkeks.org> Am 20.11.2008 um 20:30 schrieb Peter Saint-Andre: > RECOMMENDED means the same thing as SHOULD. :) > > So the following are equivalent: > > "It is RECOMMENDED for a client to do X" > > "A client SHOULD do X" To me, it sounds more necessary to implement a SHOULD than a RECOMMENDED :) > Don't share presence in the first place. :P Well, we just talked about sharing it automatically, so there should be a way to revoke it. :) -- Jonathan -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part Url : http://mail.jabber.org/pipermail/standards/attachments/20081120/04dd05f0/attachment-0001.pgp From stpeter at stpeter.im Thu Nov 20 13:52:56 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 20 Nov 2008 12:52:56 -0700 Subject: [Standards] definition of a chat session (was: Re: Call for Experience: XEP-0085 (Chat State Notifications)) In-Reply-To: <3F91D9D9-E094-4F17-B4DF-488B9EE69128@webkeks.org> References: <48F3B36B.9020106@stpeter.im> <23F218E4-0600-4BD4-B821-7CEE67301A0B@webkeks.org> <133fd4c60810150045r482e883dv1a5a35008208af32@mail.gmail.com> <48F63267.6070307@stpeter.im> <48F632FA.40001@stpeter.im> <61B2CBB4-CA1C-4211-BECD-0A94767AA564@simplicidade.org> <4925A396.7080808@stpeter.im> <4925B234.5090407@stpeter.im> <6B8676EA-C10B-4CF0-BEE5-61DFC0D764CE@webkeks.org> <4925B729.4060404@stpeter.im> <4925BABE.8000506@stpeter.im> <3F91D9D9-E094-4F17-B4DF-488B9EE69128@webkeks.org> Message-ID: <4925C018.3070606@stpeter.im> Jonathan Schleifer wrote: > Well, we just talked about sharing it automatically, so there should be > a way to revoke it. :) Right. This gets into the definition of a chat session, so I'm changing the subject. IMHO "chat session" is still a bit vague, and when I have time I'll work to clean that up in rfc3921bis. However for now I would suggest the following modified text: *** When two parties engage in a chat session but do not share presence with each other based on a presence subscription, they SHOULD send directed presence to each other so that either party can easily discover if the other party changes its availability or goes offline during the course of the chat session. However, a client MUST provide a way for a user to disable such presence sharing globally or to enable it only with particular entities. Furthermore, a party SHOULD send directed unavailable to the other party when it has reason to believe that the chat session is over (e.g., if, after some reasonable amount of time, no subsequent messages have been exchanged between the parties). *** From brettz9 at yahoo.com Thu Nov 20 16:07:34 2008 From: brettz9 at yahoo.com (Brett Zamir) Date: Thu, 20 Nov 2008 15:07:34 -0700 Subject: [Standards] [Fwd: Pubsub collection nodes] Message-ID: <4925DFA6.4000201@yahoo.com> I never got an answer on this one... Anybody? thanks, Brett -------------- next part -------------- An embedded message was scrubbed... From: Brett Zamir Subject: [Standards] Pubsub collection nodes Date: Fri, 07 Nov 2008 14:32:45 +0800 Size: 3195 Url: http://mail.jabber.org/pipermail/standards/attachments/20081120/ed6f2847/attachment.eml From brettz9 at yahoo.com Thu Nov 20 16:14:11 2008 From: brettz9 at yahoo.com (Brett Zamir) Date: Thu, 20 Nov 2008 15:14:11 -0700 Subject: [Standards]