Re: [Standards] LAST CALL: XEP-0209 (Metacontacts)
On Thu, Apr 3, 2008 at 7:45 AM, Pedro Melo <[EMAIL PROTECTED]> wrote: > I wrote a email last week in the standards list about this one. Should I > repost it in this thread? Or move it to the jdev list? It's still in my inbox to reply to you, it didn't go unnoticed :) /K
Re: [Standards] LAST CALL: XEP-0209 (Metacontacts)
Hi, On Apr 2, 2008, at 11:30 PM, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0209 (Metacontacts). Abstract: This document specifies an XMPP protocol extension for defining metacontacts and grouping member JIDs. URL: http://www.xmpp.org/extensions/xep-0209.html This Last Call begins today and shall end at the close of business on 2008-04-18. Please consider the following questions during this Last Call and send your feedback to the standards@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! I wrote a email last week in the standards list about this one. Should I repost it in this thread? Or move it to the jdev list? Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0235: data forms?
Hi, On Apr 2, 2008, at 10:38 PM, Peter Saint-Andre wrote: pavlix wrote: On Mon, 31 Mar 2008 11:38:05 +0100 Pedro Melo <[EMAIL PROTECTED]> wrote: On Mar 30, 2008, at 6:18 PM, Fabio Forno wrote: On Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo <[EMAIL PROTECTED]> wrote: I have nothing very strong against Data Forms. My point was that, for clients that use XPath to parse the known parts of the stanza (and transparently ignore anything that the client does not support), data forms are a bit messy :) and a nice semantic XML is much easier to parse. In fact I'd say that Data Forms are good when you don't know in advance all the possible fields, or when you have complex input schemes that must be rendered in clients (e.g. muc or pubsub configuration). I think that only the second case holds, when you need to present it to a human. If you don't know in advance the fields, your software will not know what to do with them either, right? Exactly. Sure, but the service will send you only the fields it understands, and your client will just present a data form and you'll fill in what you know (the client doesn't need to understand all the form fields, just like your browser doesn't need to understand the fields in an HTML form). But I'm not opposed to the forms when they will be used to interact with some-sort-of-human. I think that when a protocol will be used between software only, data-forms are not the best way to do it. As I said above, only the second case is a valid use for forms (software- to-human). Forms are great for humans, not so great for software-to-software. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Meta-Contacts: implementation notes
Pedro Melo wrote: I'll let the XEP authors comment on your feedback. :) > 5. Final thoughts > > I must admit that the lack of private storage in the GTalk service is a > big turn off for us. Perhaps they will deploy PEP someday. :) > If we are willing to loose the order attribute (and I would not like > that, but I want something that just works), there is a fallback > protocol that requires only the usual roster to keep meta-contacts. If > we assume that roster items with the same name + groups (basically, if > the tag algorithm above yields the same hash for your roster entries) > belong to the same meta-contact, we can implement meta-contacts without > the need of any extra storage, just the roster. > > The two down-sides are: > > 1. you must rename the roster entries and stick them in the same groups > if they belong to the same meta-contact: personally I have no problems > with this, because it works pretty well even if I log in with a contact > without meta-data support. > 2. you loose the user-order of contacts inside a meta-contact: so you > have to revert to the usual presence priority. > > We used this method (client-side calc of hash based on the above > algorithm) in our windows client for 5 years now, with good results. This is interesting. Are you saying that we don't need private data storage or PEP at all for Metacontacts? That would certainly simplify the deployment task. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] ACTIVE: XEP-0239 (Binary XMPP)
Joe Hildebrand wrote: > As well, the text doesn't adequately specify the translation from XML to > binary. I would recommend text like: > > To convert from traditional XMPP to bxmpp, the UTF-8 encoded representation > that would have been transmitted is converted an octet at a time into a > binary representation. Each input octet (with value from 0-255) MUST be > converted into exactly 8 XML elements (with value of or ), > with the most significant bit coming first. For example, to send the > character '>', it is UTF-8 encoded octet with decimal value 62, which turns > into the XML representation of 0010: > . Fixed, thanks for the suggested text, that's always appreciated. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Council on Stanza Repeaters without Multicast
On Thu, Apr 3, 2008 at 1:47 AM, Dave Cridland <[EMAIL PROTECTED]> wrote: > On Thu Apr 3 00:32:54 2008, Tobias Markmann wrote: > > > On Thu, Apr 3, 2008 at 1:22 AM, Dave Cridland <[EMAIL PROTECTED]> wrote: > > > On Wed Apr 2 23:22:12 2008, [EMAIL PROTECTED] wrote: > > > 1) It's much simpler to implement, and2) Given that we are (or should > > be) > > > encrypting every S2S connection, then TLS is giving us compression > > anyway, > > > and moreover, it's cheaper to compress than not to compress. > > > > That may be right from the spec but in real world it's a lot worse. TLS > > doesn't really give use compression anyway. > > See this from the man page on SSL_COMP_add_compression_method(3) > > (OpenSSL): > > > > > The TLS standard (or SSLv3) allows the integration of compression > > methods > > > into the communication. The TLS RFC does however not specify > > compression > > > methods or their corresponding identifiers, so there is currently no > > > compatible way to integrate compression with unknown peers. It is > > therefore > > > currently not recommended to integrate compression into applications. > > > Applications for non-public use may agree on certain compression > > methods. > > > Using different compression methods with the same identifier will lead > > to > > > connection failure. > > > > > > The only way to make use of TLS's compression capabilities is to get all > > XMPP servers and clients use the same compression methods and same > > identifiers for those methods otherwise TLS just does NOT do > > compression. > > Since this seems very unlikely I prefer applying XEP-0138 and then TLS. > > > > OpenSSL has negotiated the DEFLATE compression codec defined in RFC 3749 > since 0.9.8 came out - the documentation may be wrong, but it always is with > OpenSSL. > > > Dave. > -- > Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]<[EMAIL > PROTECTED]> > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > That's nice to hear for OpenSSL but there is GnuTLS, NSS(Mozilla), Windows' SSAPI(SChannel) and YASSL. I doubt compression can be used between any two different implementations which is a pretty bad situation one might not want to base on. Though it is nice if servers can use TLS' capabilities of compression it seems better to me also or only implement usage of XEP-0138 before TLS. Tobias
Re: [Standards] Council on Stanza Repeaters without Multicast
On Thu Apr 3 00:47:08 2008, Dave Cridland wrote: OpenSSL has negotiated the DEFLATE compression codec defined in RFC 3749 since 0.9.8 came out - the documentation may be wrong, but it always is with OpenSSL. I should point out, though, that the situation *is* a lot worse over on mobile devices, where the TLS implementation still don't have DEFLATE support, in a place you'd think would benefit most. Hence the existence of RFC 4978, and XEP-0138. But, if for some reason your server runs with a TLS stack that fails to support compression, then using XEP-0138 on S2S is a reasonable fallback, and will lower - not raise - CPU cost, although in this instance it will cause an increase in RTTs at connection set-up time. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Council on Stanza Repeaters without Multicast
On Thu Apr 3 00:32:54 2008, Tobias Markmann wrote: On Thu, Apr 3, 2008 at 1:22 AM, Dave Cridland <[EMAIL PROTECTED]> wrote: > On Wed Apr 2 23:22:12 2008, [EMAIL PROTECTED] wrote: > 1) It's much simpler to implement, and2) Given that we are (or should be) > encrypting every S2S connection, then TLS is giving us compression anyway, > and moreover, it's cheaper to compress than not to compress. That may be right from the spec but in real world it's a lot worse. TLS doesn't really give use compression anyway. See this from the man page on SSL_COMP_add_compression_method(3) (OpenSSL): > The TLS standard (or SSLv3) allows the integration of compression methods > into the communication. The TLS RFC does however not specify compression > methods or their corresponding identifiers, so there is currently no > compatible way to integrate compression with unknown peers. It is therefore > currently not recommended to integrate compression into applications. > Applications for non-public use may agree on certain compression methods. > Using different compression methods with the same identifier will lead to > connection failure. The only way to make use of TLS's compression capabilities is to get all XMPP servers and clients use the same compression methods and same identifiers for those methods otherwise TLS just does NOT do compression. Since this seems very unlikely I prefer applying XEP-0138 and then TLS. OpenSSL has negotiated the DEFLATE compression codec defined in RFC 3749 since 0.9.8 came out - the documentation may be wrong, but it always is with OpenSSL. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Council on Stanza Repeaters without Multicast
On Thu, Apr 3, 2008 at 1:22 AM, Dave Cridland <[EMAIL PROTECTED]> wrote: > On Wed Apr 2 23:22:12 2008, [EMAIL PROTECTED] wrote: > 1) It's much simpler to implement, and2) Given that we are (or should be) > encrypting every S2S connection, then TLS is giving us compression anyway, > and moreover, it's cheaper to compress than not to compress. That may be right from the spec but in real world it's a lot worse. TLS doesn't really give use compression anyway. See this from the man page on SSL_COMP_add_compression_method(3) (OpenSSL): > The TLS standard (or SSLv3) allows the integration of compression methods > into the communication. The TLS RFC does however not specify compression > methods or their corresponding identifiers, so there is currently no > compatible way to integrate compression with unknown peers. It is therefore > currently not recommended to integrate compression into applications. > Applications for non-public use may agree on certain compression methods. > Using different compression methods with the same identifier will lead to > connection failure. The only way to make use of TLS's compression capabilities is to get all XMPP servers and clients use the same compression methods and same identifiers for those methods otherwise TLS just does NOT do compression. Since this seems very unlikely I prefer applying XEP-0138 and then TLS. Tobias
Re: [Standards] Council on Stanza Repeaters without Multicast
On Wed Apr 2 23:22:12 2008, [EMAIL PROTECTED] wrote: I was pointed to your council meeting log at http://logs.jabber.org/[EMAIL PROTECTED]/2008-04-02.html Given that PSYC's webpages suggest that "Only politics can stop that now", I think we may be off to a non-useful conversation, here, but anyway. Some thoughts and numbers about http://www.xmpp.org/extensions/inbox/repeaters.html you discussed between 14:40 and 14:55. this is an odd spec - it loses us the 'no spoofing' which we currently enjoy I notice what you mean.. repeaters have double 'from'.. the sending server and the originating sender. In a simple no-trust situation these SHOULD be on the same host or domain, then my server is merely sending stanzas in my name in a more efficient way. That's something to add to "10. Security Considerations". Yes, I concur that this - although weird - doesn't introduce any fundamental security issues if done right. However, it does make it easier to break thing at the implementation stage. I'm not wholly convinced that, in the current design, it will actually result in "better" network usage. The single thing that worries me most on this is simply that nobody seems to have done any figures on whether this genuinely saves bandwidth. I know Fippo's postings aren't the easiest read. He expects everyone to be as deep in it as he is himself. He has used stpeter's model from http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-03.html found a bug in the formulas, then with the corrected formula figured out numbers for scenario 5.1 as follows: 58000 for the "standard" behaviour of xmpp (also dubbed "rfc") 25120 for repeaters XEP 19720 for smart presence XEP from 2004 For completeness, smart presence is here: http://www.xmpp.org/extensions/inbox/smartpresence.html It basically does the same as repeaters, but focused on presence only. Right, but *NONE OF THESE* figures take into account two things: A) Compression It's crucial on two counts: 1) It's much simpler to implement, and 2) Given that we are (or should be) encrypting every S2S connection, then TLS is giving us compression anyway, and moreover, it's cheaper to compress than not to compress. We've been down the road before where on some admittedly fairly simple figures I did a while back - and repeated for Peter's scalability draft in the SIMPLE WG, I think - the existing presence "splurges" compress really well, often better than the "optimized" alternatives. Smart Presence was one proposal that beat pure compression, as I recall, but it has security implications which I'm not going to accept. B) RTT delays The introduction of Stanza Repeaters gives us RTT delays whenever a list needs changing. That just strikes me as worrying - I don't think anyone has clear figures on how much delay would be introduced, but I'm sure you'll agree that additional latency does not a performance improvement make. It may be possible to alter the protocol to remove these. He resumes: | Regardless of protocol details, the concept of remote fan-out using | lists stored on the remote side is superior to the "current" way of | doing things. That's an opinion, not a fact. The facts are that Stanza Repeaters *do* introduce at least some round-trips, and have not been considered WRT post-compression figures, which the scalability drafts specifically don't touch because it would put XMPP in such a horrific advantage to SIMPLE, and is exceedingly difficult to put into a simple formula. This isn't even taking into account what a huge gain repeaters represent when applied to MUCs. large pubsubs also start having a chance to actually scale. But you can do both MUC and PubSub way better if you design something specific to them, and I think that's possible to do. All of this gets even better when you apply real multicast to it, but you don't need to worry about that now. You are already improving a lot by being more strategic in the way you unicast. That is what the repeaters XEP and similar earlier protoXEPs propose. Unfortunately, your notions of junctions and multicast simply don't fit the security model of XMPP. They do, however, work perfectly well if considered as a highly distributed XMPP cluster, but that's another story. right, we don't have, still, afaik a decent model for testing the effect of such things on 'real' usage I hope stpeter's draft isn't the worst of choices. Not the worst of choices, but bear in mind that the draft in question was a comparison to a draft discussing SIP/SIMPLE scaling - it doesn't match XMPP usage, but a rather sterile guess at probable activities of SIMPLE users. So Kevin's right here - we don't have a decent model, and the best one we have is basically forced on us from another protocol. Not at all. My sendmail is busy until ne
Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)
XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0136 (Message Archiving). > > Abstract: This document defines mechanisms and preferences for the > archiving and retrieval of XMPP messages. > > URL: http://www.xmpp.org/extensions/xep-0136.html Per XMPP Council consensus, I will split this into two specifications during the Last Call period -- we will move the encryption aspects to a separate document. Feedback is welcome regarding that decision and the spec in general. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] LAST CALL: XEP-0209 (Metacontacts)
This message constitutes notice of a Last Call for comments on XEP-0209 (Metacontacts). Abstract: This document specifies an XMPP protocol extension for defining metacontacts and grouping member JIDs. URL: http://www.xmpp.org/extensions/xep-0209.html This Last Call begins today and shall end at the close of business on 2008-04-18. Please consider the following questions during this Last Call and send your feedback to the standards@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!
[Standards] LAST CALL: XEP-0136 (Message Archiving)
This message constitutes notice of a Last Call for comments on XEP-0136 (Message Archiving). Abstract: This document defines mechanisms and preferences for the archiving and retrieval of XMPP messages. URL: http://www.xmpp.org/extensions/xep-0136.html This Last Call begins today and shall end at the close of business on 2008-04-18. Please consider the following questions during this Last Call and send your feedback to the standards@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!
[Standards] Council on Stanza Repeaters without Multicast
I was pointed to your council meeting log at http://logs.jabber.org/[EMAIL PROTECTED]/2008-04-02.html Some thoughts and numbers about http://www.xmpp.org/extensions/inbox/repeaters.html you discussed between 14:40 and 14:55. this is an odd spec - it loses us the 'no spoofing' which we currently enjoy I notice what you mean.. repeaters have double 'from'.. the sending server and the originating sender. In a simple no-trust situation these SHOULD be on the same host or domain, then my server is merely sending stanzas in my name in a more efficient way. That's something to add to "10. Security Considerations". Also needs to go into "4. Creating a Repeater" with "10. Security Considerations" mentioning in the "A repeater service SHOULD restrict the JIDs that are included in a repeater list to local entities ..." paragraph, that if such condition is not met, a SHOULD be generated. on list I said I'd be happy with this if we included proof that it's a valid forwarded stanza This should be a separate XEP on top of repeaters which define a form of multicast repeaters with digital proof. Repeaters without multicast do fine without proof if the security implications are properly implemented. Repeaters in closed trust systems also do fine without proof. I'm not wholly convinced that, in the current design, it will actually result in "better" network usage. The single thing that worries me most on this is simply that nobody seems to have done any figures on whether this genuinely saves bandwidth. I know Fippo's postings aren't the easiest read. He expects everyone to be as deep in it as he is himself. He has used stpeter's model from http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-03.html found a bug in the formulas, then with the corrected formula figured out numbers for scenario 5.1 as follows: 58000 for the "standard" behaviour of xmpp (also dubbed "rfc") 25120 for repeaters XEP 19720 for smart presence XEP from 2004 For completeness, smart presence is here: http://www.xmpp.org/extensions/inbox/smartpresence.html It basically does the same as repeaters, but focused on presence only. He resumes: | Regardless of protocol details, the concept of remote fan-out using | lists stored on the remote side is superior to the "current" way of | doing things. That's essentially what's in http://mail.jabber.org/pipermail/standards/2008-March/018276.html He adds some more numbers in the following posting at http://mail.jabber.org/pipermail/standards/2008-March/018320.html | B6 for scenario 5: | rfc: 19944 bytes/second | bis:4500 bytes/second | smart/rep: 454 bytes/second This means, the optimizations suggested in RFC "bis" will reduce presence overhead according to scenario 5 to a fourth of the current RFC style. When applying repeaters or smart unicast we end up at less than a 40th of the current network traffic. This isn't even taking into account what a huge gain repeaters represent when applied to MUCs. large pubsubs also start having a chance to actually scale. All of this gets even better when you apply real multicast to it, but you don't need to worry about that now. You are already improving a lot by being more strategic in the way you unicast. That is what the repeaters XEP and similar earlier protoXEPs propose. right, we don't have, still, afaik a decent model for testing the effect of such things on 'real' usage I hope stpeter's draft isn't the worst of choices. if people want to use this in their closed ecosystems, it doesn't seem a bad method really Kev: if that's the only usage model, I'm not sure if we should publish a XEP on it I'm afraid you are confusing my Multicast Repeaters extension idea with the actual Stanza Repeaters protoXEP as it stands. The normal usage model is to optimize traffic on any given S2S link. By thinking ahead I confused your vision of what the protoXEP is proposing, sorry for that. I thought it was sufficiently clear. at least a decent number of people think we need multicast though, and I don't have much reason to doubt them Yes, but we aren't even discussing real multicast yet. We need this building block first. This one, or one of the older ones from 2004. In closed ecosystems, there are better solutions, since you can use trust relationships between servers much easier. You are right. You can throw XMPP-S2S into the dumpster and use an optimized proprietary binary protocol or something like that. But I don't think it's the XSF's job to come up with something to replace XMPP. I /would/ like to see work done on pubsub repeaters, though. Shouldn't be hard to apply repeaters to pubsub. I do believe them - I have quite some doubt on us being able to scale indefinitely, server deployment-wise My experience with multicast tells me you are || <- this close from taking a major leap into fr
[Standards] [Fwd: [Council] meeting minutes, 2008-04-02]
FYI. Original Message From: Peter Saint-Andre <[EMAIL PROTECTED]> To: XMPP Council <[EMAIL PROTECTED]> Date: Wed, 02 Apr 2008 16:14:15 -0600 Subject: [Council] meeting minutes, 2008-04-02 Results of the XMPP Council meeting held 2008-04-02... Agenda: http://www.jabber.org/council/meetings/agendas/2008-04-02.html Log: http://logs.jabber.org/[EMAIL PROTECTED]/2008-04-02.html 0. Roll call Present: Dave Cridland, Ralph Meijer, Ian Paterson, Peter Saint-Andre, Kevin Smith. All members presence, quorum achieved. 1. Agenda bashing None. 2. Next meeting. To be scheduled on the council@ list. 3. XEP-0171: Language Translation Advance version 0.3 to Draft? Dave and Peter voted +1. Ralph, Ian, and Kevin to vote on the list or at the next meeting. 4. XEP-0222: Best Practices for Persistent Storage of Public Data via Publish-Subscribe Advance version 0.2 to Draft? Dave, Ralph, Peter, and Kevin voted +1. Ian to perform a final review and vote on the list or at the next meeting. 5. XEP-0223: Best Practices for Persistent Storage of Private Data via Publish-Subscribe Advance version 0.2 to Draft? Ralph and Peter voted -1 pending further review regarding examples and the underlying publication model 6. XEP-0189: Public Key Publishing Advance version 0.7 to Draft? Dave and Peter voted +1. Ralph, Ian, and Kevin to vote on the list or at the next meeting. 7. XEP-0136: Message Archiving Issue Last Call? Consensus to issue a last call. Peter to mention as part of the last call that the Council wishes to split XEP-0136 into two parts (with the complicated encryption stuff being moved to a new spec). 8. XEP-0209: Metacontacts Issue Last Call? Consensus to issue a last call. 9. Proto-XEP: Stanza Repeaters Accept as a XEP? Lengthy discussion regarding security concerns. Council members to post to the standards@ list to follow up. 10. Google Summer of Code Council members need to register in order to help choose the students, see http://mail.jabber.org/pipermail/council/2008-March/002309.html 11. Any other business? None. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0235: data forms?
pavlix wrote: > On Mon, 31 Mar 2008 11:38:05 +0100 > Pedro Melo <[EMAIL PROTECTED]> wrote: > >> On Mar 30, 2008, at 6:18 PM, Fabio Forno wrote: >>> On Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo >>> <[EMAIL PROTECTED]> wrote: I have nothing very strong against Data Forms. My point was that, for clients that use XPath to parse the known parts of the stanza (and transparently ignore anything that the client does not support), data forms are a bit messy :) and a nice semantic XML is much easier to parse. >>> In fact I'd say that Data Forms are good when you don't know in >>> advance all the possible fields, or when you have complex input >>> schemes that must be rendered in clients (e.g. muc or pubsub >>> configuration). >> I think that only the second case holds, when you need to present it >> to a human. >> >> If you don't know in advance the fields, your software will not know >> what to do with them either, right? >> > > Exactly. Sure, but the service will send you only the fields it understands, and your client will just present a data form and you'll fill in what you know (the client doesn't need to understand all the form fields, just like your browser doesn't need to understand the fields in an HTML form). P -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0235: data forms?
On Mon, 31 Mar 2008 11:38:05 +0100 Pedro Melo <[EMAIL PROTECTED]> wrote: > > On Mar 30, 2008, at 6:18 PM, Fabio Forno wrote: > > On Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo > > <[EMAIL PROTECTED]> wrote: > >> > >> I have nothing very strong against Data Forms. My point was > >> that, for > >> clients that use XPath to parse the known parts of the stanza (and > >> transparently ignore anything that the client does not support), > >> data > >> forms are a bit messy :) and a nice semantic XML is much easier to > >> parse. > >> > > > > In fact I'd say that Data Forms are good when you don't know in > > advance all the possible fields, or when you have complex input > > schemes that must be rendered in clients (e.g. muc or pubsub > > configuration). > > I think that only the second case holds, when you need to present it > to a human. > > If you don't know in advance the fields, your software will not know > what to do with them either, right? > Exactly. > > > In the other cases as best practice I wouldn't abuse > > on them, in order not to be too much verbose (though we may find a > > way to "binarize" them ;)) > > One binary form will rule them all... > > Best regards, -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
[Standards] XMPP and W3C Digital Signature Specification
Over the last couple of years we have discussed various approaches to add digital signature support to XMPP that did not violate the XML nature of XMPP like RFC3923. We would like to propose a method of using W3C¹s XML Digital Signature specification. Below is description of how we use the W3C spec with XMPP. We have been using this approach for about 3 years and it seems to work quite well though it is a bit expensive in terms of message size but with digital signatures, I¹m not sure that can be avoided. We are curious what other people think and if its worth moving forward with a XEP to formally describe the approach. boyd details: We chose to use the W3C because its standardized, well understood, and widely implemented. We were not planning to address how the public keys between the users are exchanged or how the certificates are validated. A digital signature is encapsulated in the element. This signature element is a child element of either , , . A client or server would use JID in XMPP stanzas to lookup a client's X509 certificate. When multiple certificates are available for that JID, the will identify which to use. The carries a X509 fingerprint which is a MD5 digest of the X509 certificate and formatted as hex characters, each byte separated by a colon. For example, 94:01:67:A6:45:70:B3:AD:8D:A3:8D:B9:2F:46:AA:52 A digitally signed IQ stanza. Note this does cause a slight incompatibility with the current IQ schema as we would like to put the digital signature as a 2nd child node of IQ to make it consistent with message and presence stanzas. http://jabber.org/protocol/disco#info";> http://www.w3.org/TR/2001/REC-xml-c14n-20010315";> http://www.w3.org/2000/09/xmldsig#rsa-sha1";> http://www.w3.org/2000/09/xmldsig#enveloped-signature";> http://www.w3.org/TR/2001/REC-xml-c14n-20010315";> http://www.w3.org/2000/09/xmldsig#sha1";> FVBU+ucCf8bPWdiJbo7RXXGJhcI= usN4/Zb+eufe8lOIGez+TuxEiVGwOg3QZNzzx1Ld6fKBjYIIgB2Z9X1KuGkrWbrqcQg5EvOyhopa RkgaWyRNtbYT6h2uw8C6af07iWR5Plwiv36r8Fiutcyx+ZSRzzF03uL8KfuKOvgerhjUS/ntAmHa zvMrE37A5N39h/S6ZZIGZrmK2/2JxZRKEdnQtmgLMrccmfgmCUrSSEgs52kQ1Bt7PB5PW2Lxoj04 T5lU92o2f4QIxqLkND+rHYY09KzG28Vb9ImXg0vfhs1oWqP5j5HtxGoNfJ1eXQIQt/Mk9NOQFUHa Zh8pwvfjbWeY2z7FW5x2RuYFGnpkd9OphBSwNw== MIIDwzCCAqugAwIBAgIBADANBgkqhkiG9w0BAQQFADCBpDELMAkGA1UEBhMCVVMxGDAWBgNVBAoT D1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxDjAMBgNVBAsTBUNE Q0lFMR8wHQYDVQQDExZyZWwtY2cucmVsLmplLmpvaW50LnVzMS4wLAYJKoZIhvcNAQkBFh9jb2Fs bG9nMUByZWwtY2cucmVsLmplLmpvaW50LnVzMB4XDTA4MDIxOTE5NTczN1oXDTA5MDIxODE5NTcz N1owgaQxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0Rv RDEMMAoGA1UECxMDUEtJMQ4wDAYDVQQLEwVDRENJRTEfMB0GA1UEAxMWcmVsLWNnLnJlbC5qZS5q b2ludC51czEuMCwGCSqGSIb3DQEJARYfY29hbGxvZzFAcmVsLWNnLnJlbC5qZS5qb2ludC51czCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOsouVSsIFZMqQOYCBiDgyfQG3g2Z47MDm+e qhJ1xqcvZfrvuIg/wPGYxiA/C3WOXN/aMmoTHkapP0K/wtXQQ4Csm1D7iwkN4UnKlccoh7EwqAOi 0ED+PGxjP8JB5VxDib6SWUKA0acE5NAgX0PX/KaMG1rrl5wDsFUtpt5r8j6RSx95ARGlYBZQWuWd NBuy03vukiyuIT5fbSVqPKU9NCQIvJTjNFgemECdyQanrFdqQR8oBWXZ9uoWHa5+lKrnYWHHTUE/ ylTd05nlW725w9aNGFbkZNh/eYPOFtUuDOtxC7Uu2ii+gaKbjDK5NcqJwM3XgfNgU9mykqvU4zGJ uukCAwEAATANBgkqhkiG9w0BAQQFAAOCAQEAmY+M5lV//+qL5JczL9vrdZCnxOxt3N3uw7JE4tIb +oHC+TMHxLPEGoLOSb6muTpDiKLDeJBsrFf3KkvhnJZyU+dF3OPutm2nI8r9KsXIzF/mWHBPbZOE HJHmenvR0v+7gcW4PJLQogb8sgdhIJmdo3ANPahppo+QyqDu4EeIFtf+qSNb7OA6EYDwNZCR67tO ApA9dEOHtkGEIdoHAdmzYu6uIP3EhmYRSGulVqaVBB6OZdoq6OPlh6ER90xeDba2O5t7GkdbKdD9 vN3Qo9ZUVY9KkOP5wYgW6lvaD1xKf9LM/Er9dEVrJFPtPJFVOuTZlGIfQGSVz70Grv1Dwc2cIw== 82:9D:A9:E4:0B:B2:A5:A2:77:D3:A5:D1:43:C0:79:CA A digitally signed PRESENCE stanza Online< priority>0http://jabber.org/protocol/muc";>http://www.w3.org/2000/09/xmldsig#"; xml:lang="en"> http://www.w3.org/TR/2001/REC-xml-c14n-20010315";> http://www.w3.org/2000/09/xmldsig#rsa-sha1";> http://www.w3.org/2000/09/xmldsig#enveloped-signature";> http://www.w3.org/TR/2001/REC-xml-c14n-20010315";> http://www.w3.org/2000/09/xmldsig#sha1";> +Ux4t7g6eXoNzYQdMlI5lnAuAfQ= 4bVVbgHaekPhBVAeDm8Fku6kLLiyy3Duvhy5BaJ9QDN4qyC7kwqxjd3SFzQ4NxtGqno1/QEjJBwG 371fTzxsYMBjSsDVSU2JdGJttsNs9vVF5CHvvqVugnHFBt2LQWaPKfxGLI9aEGwCrkkmtdMMGMBz 3q/JUzbG0PeG41SzUXpvnpiC/4PmhJv2G5pjrVXRTOyyi6DbeQY9bVOrcD4annwPKcSlAVvXOsRR k6VhxtwTXqDl9/jOyktMfiFYcAQzyi6xvKRY/KBbybUhie9Mq5f1O88AJipr4+B2u8pNyCDvGNiW zRuzG4bw7QlXuKUH8PcWDVbtXcXE+aJELTucwg== MIIDwzCCAqugAwIBAgIBADANBgkqhkiG9w0BAQQFADCBpDELMAkGA1UEBhMCVVMxGDAWBgNVBAoT D1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxDjAMBgNVBAsTBUNE Q0lFMR8wHQYDVQQDExZyZWwtY2cucmVsLmplLmpvaW50LnVzMS4wLAYJKoZIhvcNAQkBFh9jb2Fs bG9nMUByZWwtY2cucmVsLmplLmpvaW50LnVzMB4XDTA4MDIxOTE5NTczN1oXDTA5MDIxODE5NTcz N1owgaQxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0Rv RDEMMAoGA1UECxMDUEtJMQ4wDAYDVQQLEwVDRENJRTEfMB0GA1UEAxMWcmVsLWNnLnJlbC5qZS5q b2ludC51czEuMCwGCSqGSIb3DQEJARYfY29hbGxvZzFAcmVsLWNnLnJlbC5qZS5qb2ludC51czCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOsouVSs
[Standards] new SIP-XMPP list
FYI, some folks who want to better define interworking between SIP and XMPP have started an informal discussion list. You can subscribe via either of the following URLs: http://mail.jabber.org/mailman/listinfo/sip-xmpp mailto:[EMAIL PROTECTED] The intended outcome of these efforts is a full set of I-Ds that define mappings for addresses, presence, "pager mode" messages, 1-to-1 chat sessions (via MSRP on the SIP side), multiparty chat sessions (via MSRP on the SIP side and MUC on the XMPP side), multimedia sessions (via Jingle on the XMPP side), and eventually even features like file transfer, notifications, and device capabilities. We may also request a BOF at a future IETF meeting for the purpose of forming a working group or exploratory group (in accordance with RFC 5111). However, that is yet to be determined. Right now we're just hashing out some of the issues involved with interworking, so if you have an interest in the topic, feel free to join the list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-136 and XEP-59 implementation comments
Peter, Quoting Peter Saint-Andre <[EMAIL PROTECTED]>: I think it is counter-intuitive. Logic would hint that domain.com is exact match and @domain.com is a wild match. Similar with [EMAIL PROTECTED] is exact match and [EMAIL PROTECTED]/ is wild match. Yes, probably, but that would break current behavior for sure, while the original approach seems to be less dangerous in this respect ... If backward compatibility is not a problem, though, I personally would be happy with either way of doing it. Well, hmm, breaking backward-compatibility is not good, eh? Yes, but don't forget that my original proposal was the opposite variant ;-) (which, hopefully, should not cause serious problems with backward compatibility, but as Tomasz and you pointed out may be counter-intuitive for someone) I suppose that for XEP-136 backward compatibility is not a problem - it's MUC where most likely it is. ... and we still have another option: attribute 'exactMatch', which is certainly backward-compatible ... Good luck! Alexander This message was sent using IMP, the Internet Messaging Program.
