Re: [Standards] Idea for std. Being implemented here @ wirelessfactory
On Thu Jun 18 08:25:22 2009, Mads Randstoft wrote: We found that we needed a way to ensure delivery of some commands even in the face of offline recipients, takeing the offline messages as basic idea, we are designing an addon for XMPP servers that will allow specified iqcommand stanzas to offline clients to be stored in case of client being offline and sent to the client when this client again comes online. Since not all commands should be stored, it must be possible to configure which types of commands are stored, based on command nodes. If I recall right, the authors of IO Data also had ideas about long-running commands - is this the kind of thing you mean? (As in, commands which take a sufficiently long time to execute that clients might go offline, come back later, and check on progress). At least, I vaguely recall this subject coming up before - in any case, a structure for doing that would be worthwhile if there's support for it. If you're saying that you want command requests to be queued offline, then yes, as Pedro says, you want queueing. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Modifying the schema for auth(RFC 3920)
Moving the discussion to the XMPP working group mailing list since this is RFC-related. It looks like Google's docs for this are here: http://code.google.com/apis/talk/jep_extensions/jid_domain_change.html Should the client just use this bare JID the next time it logs in? If so, we may need to make a change to 3920bis to make this clear. If we're contemplating making a change in -bis, we should make the correct one, not just loosen up the schema. Of course, in your implementation, there's nothing that says you can't use any schema you like to do validation, since validation is not required and the schemas are non-normative. -- Joe Hildebrand From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Mittal Thakkar Sent: Tuesday, June 23, 2009 12:43 AM To: standards@xmpp.org Subject: [Standards] Modifying the schema for auth(RFC 3920) Hi, The clients using the libpurple 2.6.x like Adium and Pidgin sends the following stanza for auth : auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5' xmlns:ga='http://www.google.com/talk/protocol/auth' ga:client-uses-full-bind-result='true'/. At our server xml parsing fails as in the schema for auth it supports only one attribute ie. mechanism. wrt. Appendix C.4 of RFC 3920. Is it valid if we allow any attribute( of other namespace ) for the auth/ as RFC is silent about it. The schema we want to use is as follows: xs:element name='auth' xs:complexType xs:simpleContent xs:extension base='xs:string' xs:attribute name='mechanism' type='xs:string' use='optional'/ xs:anyAttribute namespace='##other' processContents='lax'/ /xs:extension /xs:simpleContent /xs:complexType /xs:element -- Thanks, Regards, Mittal Thakkar
Re: [Standards] [xmpp] Modifying the schema for auth(RFC 3920)
2009/6/23 Joe Hildebrand joe.hildebr...@webex.com: Moving the discussion to the XMPP working group mailing list since this is RFC-related. It looks like Google's docs for this are here: http://code.google.com/apis/talk/jep_extensions/jid_domain_change.html Should the client just use this bare JID the next time it logs in? If so, we may need to make a change to 3920bis to make this clear. If we're contemplating making a change in -bis, we should make the correct one, not just loosen up the schema. In my opinion, this is a pretty Google-specific problem. In normal XMPP world, user account is strictly defined by the combination of node identifier and domain name. This google extension allows user to log in with different domain, then the one user registered with. If we are to modify the spec about this, we must also allow one account to have multiple JIDs, which in turn would require a way to retrieve all the account's aliases (for the proper handling on another servers), along with proper security considerations and so on... Of course, in your implementation, there's nothing that says you can't use any schema you like to do validation, since validation is not required and the schemas are non-normative. IMHO, validation is completely useless on an XMPP server. It just slows it down and possibly breaks it on any unexpected input. The server should handle the communication as long as there is everything needed. Not kick client in the butt for something that shouldn't be here. -- Joe Hildebrand From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Mittal Thakkar Sent: Tuesday, June 23, 2009 12:43 AM To: standards@xmpp.org Subject: [Standards] Modifying the schema for auth(RFC 3920) Hi, The clients using the libpurple 2.6.x like Adium and Pidgin sends the following stanza for auth : auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5' xmlns:ga='http://www.google.com/talk/protocol/auth' ga:client-uses-full-bind-result='true'/. At our server xml parsing fails as in the schema for auth it supports only one attribute ie. mechanism. wrt. Appendix C.4 of RFC 3920. Is it valid if we allow any attribute( of other namespace ) for the auth/ as RFC is silent about it. The schema we want to use is as follows: xs:element name='auth' xs:complexType xs:simpleContent xs:extension base='xs:string' xs:attribute name='mechanism' type='xs:string' use='optional'/ xs:anyAttribute namespace='##other' processContents='lax'/ /xs:extension /xs:simpleContent /xs:complexType /xs:element -- Thanks, Regards, Mittal Thakkar ___ xmpp mailing list x...@ietf.org https://www.ietf.org/mailman/listinfo/xmpp
[Standards] Proposed XMPP Extension: Muji
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Muji Abstract: This specification defines an XMPP protocol extension for initiating and managing multiparty voice and video conferences within an XMPP MUC URL: http://www.xmpp.org/extensions/inbox/muji.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
