Re: [Standards] PDFs!
On Wed, Oct 21, 2009 at 18:52, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks to great work by Tobias Markmann, the XSF now publishes PDF versions of its specifications. You can find them here: http://xmpp.org/extensions/ We're still working out a few glitches here and there, so your feedback is appreciated. Since I don't have a clue, I'm asking here: color coding rocks, would that be possible to have the same color code in the XHTML version of the XEPs? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] PDFs!
On Mon, Nov 2, 2009 at 12:14 PM, Nicolas Vérité nicolas.ver...@process-one.net wrot On Wed, Oct 21, 2009 at 18:52, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks to great work by Tobias Markmann, the XSF now publishes PDF versions of its specifications. You can find them here: http://xmpp.org/extensions/ We're still working out a few glitches here and there, so your feedback is appreciated. Since I don't have a clue, I'm asking here: color coding rocks, would that be possible to have the same color code in the XHTML version of the XEPs? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04 Sure it's possible, the question is whether we want it. Cheers, Tobias
Re: [Standards] PDFs!
On Mon, Nov 2, 2009 at 11:30 AM, Tobias Markmann tmarkm...@googlemail.com wrote: Since I don't have a clue, I'm asking here: color coding rocks, would that be possible to have the same color code in the XHTML version of the XEPs? Sure it's possible, the question is whether we want it. I think we do. /K
Re: [Standards] PDFs!
On Mon, Nov 2, 2009 at 12:31 PM, Kevin Smith ke...@kismith.co.uk wrote: On Mon, Nov 2, 2009 at 11:30 AM, Tobias Markmann tmarkm...@googlemail.com wrote: Since I don't have a clue, I'm asking here: color coding rocks, would that be possible to have the same color code in the XHTML version of the XEPs? Sure it's possible, the question is whether we want it. I think we do. /K K..then i'll figure something out. I'm sure out there are easy addable syntax highlighters on JS basis. Cheers, Tobias
Re: [Standards] PDFs!
On Mon, Nov 2, 2009 at 12:31, Kevin Smith ke...@kismith.co.uk wrote: On Mon, Nov 2, 2009 at 11:30 AM, Tobias Markmann tmarkm...@googlemail.com wrote: Since I don't have a clue, I'm asking here: color coding rocks, would that be possible to have the same color code in the XHTML version of the XEPs? Sure it's possible, the question is whether we want it. I think we do. Yes, the indentation is fine, and well documented. However, my eyes are not trained enough when code is monocolor. But they thank me when I read the PDF's code ;-) -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] PDFs!
On 2009/11/02, at 11:34, Tobias Markmann wrote: K..then i'll figure something out. I'm sure out there are easy addable syntax highlighters on JS basis. If you need one for JavaScript, I started using this one, and I'm pleased with the results: http://code.google.com/p/syntaxhighlighter/ Bye,
Re: [Standards] PDFs!
So highlighting should work for all XEP htmls now. They HTML files are rebuild right now. Looking good. Adding a border around the examples unfortunately reveals that we always have trailing whitespace at the end of the verbatim XMPP stanzas (to make the XML sources look prettier). It would be good if we had a transformation that removes trailing whitespaces from examples and/or verbatim blocks. cheers, Remko
Re: [Standards] XEP 203 nits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/09 1:41 PM, Kurt Zeilenga wrote: In looking at this spec recently, I found a few oddities... The specification is not clear whether a stanza can contain multiple delay/ elements such as when its delayed by multiple entities. While I cannot find any example or discussion of multiple delay/ elements in any XEP, I assume multiple delay/ elements are allowed as multiple entities can delay a stanza. But oddly I cannot find any discussion of multiple delay/ elements in XEP 203 or any specification which calls for delay/ elements to be added. Presuming the stanza can contain multiple delay/ elements when its delayed by multiple entities, the specification language could be read as disallows an entity which delays a stanza multiple times from indicating that it has done so by including multiple delay/ elements. For instance, when a server delays a stanza to a chatroom (hosted on another server entity) and than delays the forwarding of that stanza to one or more of the subscribers of the chat room. The specification recommends (in security considerations) that an entity remove delay notices which indicate that they were provided by the entity, or bounce the stanza, without at all noting that an entity should not remove it's own delay notices (or bounce a stanza it previously delayed). IMO, an entity SHOULD NOT remove delay/ purporting to be from it unless it believes they weren't from it. There also seems to be issues in subsequent handling of previously delayed messages as well... but first the above. If the specification does not forbid multiple delay/ elements, then such a usage is permitted. Indeed, I'm not sure how the spec could forbid it, except by saying that if an entity receives a stanza that already contains a delay/ element then it MUST NOT add another delay/ element -- though IMHO that would introduce the potential for a denial of service attack Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvSiYACgkQNL8k5A2w/vxzCQCfUh85RdJ6QsR3UGtKAYnnIT8U DqEAniUQBXnEiRDUtmiLNRwDqXLRgdqS =0X+B -END PGP SIGNATURE-
Re: [Standards] PDFs!
2009/11/2 Remko Tronçon re...@el-tramo.be We're still working out a few glitches here and there, so your feedback is appreciated. Cool. Something seems wrong with the example stanzas, though: there's too much space between the characters, making the examples less readable. Perhaps a bad font selection, or forcing fixed with on a proportional font? Also, copy pasting inserts spaces between the characters, maybe that's related. cheers, Remko XML source in the PDFs is now(might take some minutes until all XEPs are rebuild) using a mono spaced typeface. In our case it's in Inconsolata, http://www.levien.com/type/myfonts/inconsolata.html . I hope it meets your high font standards. :P Cheers, Tobias
Re: [Standards] PDFs!
XML source in the PDFs is now(might take some minutes until all XEPs are rebuild) using a mono spaced typeface. In our case it's in Inconsolata, http://www.levien.com/type/myfonts/inconsolata.html . I hope it meets your high font standards. :P I like Inconsolata, but never used it because it was lacking a bold and italic variant. But our XEPs don't use that (yet), so it sounds like a fine choice to me ;-) cheers, Remko
Re: [Standards] PDFs!
I hope it meets your high font standards. :P Just checked the PDF. Inconsolata is no TheSansMonoCd (it feels a bit too loose to my taste), but I'm willing to shut up about it now. The copy pasting is still a bit off, but I'm sure you're working hard to fix that as we speak :) thanks! Remko
Re: [Standards] PDFs!
2009/11/2 Remko Tronçon re...@el-tramo.be I hope it meets your high font standards. :P Just checked the PDF. Inconsolata is no TheSansMonoCd (it feels a bit too loose to my taste), but I'm willing to shut up about it now. The copy pasting is still a bit off, but I'm sure you're working hard to fix that as we speak :) thanks! Remko With copy and pasting being of you mean that if you copy listing 1 from http://xmpp.org/extensions/xep-0012.pdf in your editor you have different line breaking as you see in the PDF? Cheers, Tobias
Re: [Standards] PDFs!
from http://xmpp.org/extensions/xep-0012.pdf in your editor you have different line breaking as you see in the PDF? No, i means that I get spaces in between characters. Copy pastng from Preview (OS X) gives me: i q f r o m = ’ r o m e o @ m o n t a g u e . n e t / o r c h a r d ’ i d = ’ l a s t 1 ’ t o = ’ j u l i e t @ c a p u l e t . c o m ’ t y p e = ’ g e t ’ q u e r y x m l n s = ’ j a b b e r : i q : l a s t ’ / / i q Oddly enough, this is slightly different than copy pasting from Adobe Reader (OS X): iq from = ’ r o m e o @ m o n t a g u e . net / o r c h a r d ’ id = ’ last1 ’ to = ’ j u l i e t @ c a p u l e t . com ’ type = ’ get ’ query xmlns = ’ j a b b e r : i q : l a s t ’/ / iq Notice how the XML attribute names and tags don't have spaces between the characters. cheers, Remko
[Standards] oauth and xmpp server responsibility
Hi all, I've returned to this because my usecase seems to warrant some ownership by the server. in my setup I have an xmpp component acting as my server application. each server maintains data for the users on that server. but 'users' never log in directly to these servers, but always via some 3rd party application which connects as a simple xmpp client and makes oauth requests on behalf of users. so user-http etc-3rdpartyapp-xmpp client-somexmppserver-needs to route the message to the appropriate server based on the oauth user. since the users all have real xmpp addresses, it seems it could be a reasonable to have the xmpp server itself accept the oauth request (instead of my server component) and vet it against data that could be stored in users private storage (or a new xep just for auth keys permission option storage and matching). If this were in place then any individual (or app with suitable oauth permission) could save tokens permission data to a users private storage. Then an app with granted authority could send an oauth message, which would be vetted and forwarded to the users own xmpp server for processing (or sending again if its a message to elsewhere I guess). The forwarded message should have a new xml fragment included to indicate the original sender, and the various tokens that were included. of course this is all doable with custom components for everything, but why not allow developers to actually use all of the existing xmpp infrastructure and any custom apps, via oauth without having to reinvent everything. One last thing. the existing oauth spec doesnt support the idea that a message may need to carry nested authorities (or messages with authorities). If I have a proxy setup something like user-serverapp1-mule ESB-serverapp2 where muleESB is acting as a proxy for messages from app1 to app2, but it has its own xmpp identity Then to avoid mule needing to check authorities itself, 'app1 oauth user' needs to be wrapped by mule and a new auth added for 'mule oauth app1'. I dont know how this should best be done. If the existing oauth xml spec allowed for arbitrary stanza subelements then a sensible nesting of messages could be sent and processed without the need to change architectures or create other custom message formats workarounds. Thoughts? thanks Jason.
