[Standards] Proposed XMPP Extension: Whiteboard
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whiteboard Abstract: A protocol describing how to whiteboard over XMPP. URL: http://www.xmpp.org/extensions/inbox/whiteboard2.html The XMPP Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official XEP.
[Standards] DEFERRED: XEP-0152 (Reachability Addresses)
XEP-0152 (Reachability Addresses) has been Deferred because of inactivity. Abstract: This document defines an XMPP protocol extension for communicating reachability information related to non-XMPP devices. URL: http://www.xmpp.org/extensions/xep-0152.html If and when a new revision of this XEP is published, its status will be changed back to Experimental.
[Standards] DEFERRED: XEP-0151 (Virtual Presence)
XEP-0151 (Virtual Presence) has been Deferred because of inactivity. Abstract: This document proposes extensions to the Jabber groupchat protocol for virtual presence on Web pages. URL: http://www.xmpp.org/extensions/xep-0151.html If and when a new revision of this XEP is published, its status will be changed back to Experimental.
[Standards] DEFERRED: XEP-0150 (Use of Entity Tags in XMPP Extensions)
XEP-0150 (Use of Entity Tags in XMPP Extensions) has been Deferred because of inactivity. Abstract: This document defines best practices for the use of Entity Tags in XMPP extensions. URL: http://www.xmpp.org/extensions/xep-0150.html If and when a new revision of this XEP is published, its status will be changed back to Experimental.
Re: [Standards] inactive XEPs
OK, here is how the XMPP Extensions Editor plans to deal with these... > XEP-0150: Use of Entity Tags in XMPP Extensions > http://www.xmpp.org/extensions/xep-0150.html Defer. > XEP-0151: Virtual Presence > http://www.xmpp.org/extensions/xep-0151.html Defer. > XEP-0152: Reachability Addresses > http://www.xmpp.org/extensions/xep-0152.html Defer. > XEP-0154: User Profile > http://www.xmpp.org/extensions/xep-0154.html > > XEP-0194: User Chatting > http://www.xmpp.org/extensions/xep-0194.html > > XEP-0195: User Browsing > http://www.xmpp.org/extensions/xep-0195.html > > XEP-0196: User Gaming > http://www.xmpp.org/extensions/xep-0196.html > > XEP-0197: User Viewing > http://www.xmpp.org/extensions/xep-0197.html Update after next revision of XEP-0060 is published. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] inactive XEPs
Ian Paterson wrote: > Peter Saint-Andre wrote: >> The following XEPs have been inactive for 6+ months and therefore are >> subject to automatic deferral. If you have an interest in these specs, >> please speak up. >> >> XEP-0154: User Profile >> http://www.xmpp.org/extensions/xep-0154.html >> > > Now that PEP/PDP are being finalized, I hope we can move this to Draft > and start to depricate vcard-temp. Why? It's been "temp" only since 1999. ;-) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] User *ing formats and Atom. Was: inactive XEPs
Ralph Meijer wrote: > On Fri, 2007-07-13 at 13:37 -0600, Peter Saint-Andre wrote: >> Andreas Monitzer wrote: >>> [..] >>> Most of the inactive ones are PEP-based, which itself takes a lot of >>> time to be implemented, and so it doesn't make any sense to work on >>> those any further until this is resolved. >> Well, true -- all those "User *ing" specs. Last year sometime Jean-Louis >> Seguineau suggested that we might want to work with people outside the >> Jabber realm on Atom extensions for those (rather than making our own >> little formats for everything). I'm open to that but haven't yet figured >> out who to engage in that kind of conversation. > > I don't see anything particularly wrong with defining our own little > formats for these pieces of information. I don't either. They can always be translated to some nice Atom extension formats if someone ever defines those. Plus it seems that Jean-Louis isn't here anymore to complain if we move forward with non-Atom formats. ;-) > While I absolutely love the > Atom format, I don't know what we would gain from defining the > additional elements on top of Atom instead of directly on PEP. If there > are other formats in the same realm, we should probably provide sensible > mappings, though. Remember why we chose our own location spec over the > RFC... /me nods > That said, we /should/ finalize our efforts in the Atom over pubsub for > various other uses. Such as blog items and other typically feed like > transport (flickr, delicious, etc). Agreed. Once we have the next round of updates to XEP-0060 finished, I will move forward on draft-saintandre-atompub-notify-05 at the IETF. /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0080 (User Location)
Version 1.4 of XEP-0080 (User Location) has been released. Abstract: This document defines an XMPP protocol extension for communicating information about the current geographical location of an entity. Changelog: Renamed to User Location; corrected pubsub examples; recommended pubsub/PEP as transport for location information about human users; added uri element. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0080.xml?%40diffMode=u&%40diffWrap=s&r1=697&r2=1071&u=3&ignore=&k= URL: http://www.xmpp.org/extensions/xep-0080.html
Re: [Standards] how to treat invalid XMPP?
On Mon, Jul 16, 2007 at 07:31:01PM +0200, Jakob Schroeter wrote: > Hi, > > Apparantly there is a number of software packages that generates invalid > XMPP. > I've seen at least unescaped ' and " in attribute values and character data, > respectively. > > http://www.xmpp.org/rfcs/rfc3920.html#xml states that an XMPP implementation > must not generate such unescaped characters, and when it "receives such > restricted XML data, it MUST ignore the data". You have to distinguish 'bad XML' and 'restricted XML' here. Unescaped or bad XML should lead to a disconnect. If you receive parts of the 'restricted XML', that means XML that is: * comments (as defined in Section 2.5 of [XML] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.)) * processing instructions (Section 2.6 therein) * internal or external DTD subsets (Section 2.8 therein) * internal or external entity references (Section 4.2 therein) with the exception of predefined entities (Section 4.6 therein) * character data or attribute values containing unescaped characters that map to the predefined entities (Section 4.6 therein); such characters MUST be escaped > So far I just throw a parse error and disconnect the stream (when I > implemented that, I never thought this would actually happen), but people > complain about that. Also, that makes the receiving client look bad. If you see a component or server that sends bad XML you should file a bugreport against them. Or inform the administrator to upgrade. Of course it looks bad to the user if the client bails out with "Got bad XML, disconnecting you from your precious contacts and ruining your IM flirt with that nice girl." But there is no other choice, or your client even displays corrupted data to the user, which would be even worse. Robin
Re: [Standards] how to treat invalid XMPP?
On Jul 16, 2007, at 19:31, Jakob Schroeter wrote: So far I just throw a parse error and disconnect the stream (when I implemented that, I never thought this would actually happen), but people complain about that. They're complaining to the wrong person, then. Also, that makes the receiving client look bad. However, just ignoring the offending character could possibly change the meaning of the data, so I don't think this is a good solution, either. What do you think? My opinion: Accepting this data in any way would be the worst thing possible. It would bring XMPP one step closer to HTML, as already has happened with RSS (back when I wrote an RSS reader, I spent about 80-90% of the debugging time trying to parse some XML-like binary data). This would make life hell for XMPP developers, and should be avoided at any cost. andy
Re: [Standards] how to treat invalid XMPP?
Jakob Schroeter wrote: > Hi, > > Apparantly there is a number of software packages that generates invalid > XMPP. > I've seen at least unescaped ' and " in attribute values and character data, > respectively. > > http://www.xmpp.org/rfcs/rfc3920.html#xml states that an XMPP implementation > must not generate such unescaped characters, and when it "receives such > restricted XML data, it MUST ignore the data". Per earlier list discussion, that has changed in rfc3920bis: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-03.html#xml-restrictions The working text is as follows: ** 12.1. Restrictions XMPP is a simplified and specialized protocol for streaming XML elements in order to exchange structured information in close to real time. Because XMPP does not require the parsing of arbitrary and complete XML documents, there is no requirement that XMPP needs to support the full feature set of [XML] (Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.). In particular, the following features of XML are prohibited in XMPP: * comments (as defined in Section 2.5 of [XML] (Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.)) * processing instructions (Section 2.6 therein) * internal or external DTD subsets (Section 2.8 therein) * internal or external entity references (Section 4.2 therein) with the exception of predefined entities (Section 4.6 therein) * character data or attribute values containing unescaped characters that map to the predefined entities (Section 4.6 therein); such characters MUST be escaped An XMPP implementation MUST behave as follow with regard to these features: 1. An XMPP implementation MUST NOT inject characters matching such features into an XML stream. 2. If an XMPP implementation receives characters matching such features over an XML stream, it MUST return a stream error, which SHOULD be but MAY be . ** Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] how to treat invalid XMPP?
Hi, Apparantly there is a number of software packages that generates invalid XMPP. I've seen at least unescaped ' and " in attribute values and character data, respectively. http://www.xmpp.org/rfcs/rfc3920.html#xml states that an XMPP implementation must not generate such unescaped characters, and when it "receives such restricted XML data, it MUST ignore the data". So far I just throw a parse error and disconnect the stream (when I implemented that, I never thought this would actually happen), but people complain about that. Also, that makes the receiving client look bad. However, just ignoring the offending character could possibly change the meaning of the data, so I don't think this is a good solution, either. What do you think? Jakob pgpXTWyBe8pMm.pgp Description: PGP signature
Re: [Standards] Re: inactive XEPs
On Jul 16, 2007, at 16:45, Magnus Henoch wrote: A little reminder: there is an ejabberd module for the server-side part, http://ejabberd.jabber.ru/mod_profile . It has been running on jabber.se for a couple of months, but right now there are exactly zero profiles in the database. I'm not surprised, considering that there are zero client-side implementations of it. What server-side things are required for this besides PEP? I thought the point of PEP was to avoid having to add server implementations for every small XEP? I've been thinking about using it to create a "random chat" application (e.g. match people who speak language X with eachother), but that will probably not happen in the foreseeable future :) That'd be quite nice actually :) Might also work perfectly for a dating service (match m+f where the city is the same). andy
[Standards] Re: inactive XEPs
Peter Saint-Andre <[EMAIL PROTECTED]> writes: > XEP-0154: User Profile > http://www.xmpp.org/extensions/xep-0154.html A little reminder: there is an ejabberd module for the server-side part, http://ejabberd.jabber.ru/mod_profile . It has been running on jabber.se for a couple of months, but right now there are exactly zero profiles in the database. I've been thinking about using it to create a "random chat" application (e.g. match people who speak language X with eachother), but that will probably not happen in the foreseeable future :) -- Magnus JID: [EMAIL PROTECTED]
