Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Andreas Monitzer wrote: > On Mar 16, 2009, at 13:09, Dirk Meyer wrote: > >> Yes, maybe restrict the usage to a stanza and not allow it inside a >> stanza by default. So a client MAY send any return from any XEP out of >> band, but only the whole result. If out of band is allowed somewehere >> deep inside a stanza it SHOULD be added to the XEP defining that >> namespace. > > That's not a good idea, since then you couldn't use it for binary data > at all (since you never have base64-encoded data at the top level). > Having it only in specific stanzas would mean that you couldn't > implement a solution for everything, but only on a case-by-case basis > (or you'd have to carry around a list of situations where it's allowed > – ugh). Yes, but on the other hand it would be a pain for the developer to expect out of band data everywhere. And it is not needed in most cases. Maybe use the service discovery to handle the list: urn:xmpp:jingle:apps:out-of-band:0 urn:xmpp:tmp:media:server+outband This means that the client expects out of band data as first child element in any stanza and inside every element in the media server namespace. I know it kind of sucks to carry the list around. Another way would be that the urn:xmpp:tmp:media:server namespace defines where out of band data may happen. So if you support out of band data, just must expect for every complete stanza and everytwhere in the media server namespace where it is defined. No idea what the best solution is. Dirk -- Drugs cause amnesia and other things I can't remember...
[Standards] UPDATED: XEP-0047 (In-Band Bytestreams)
Version 1.2 of XEP-0047 (In-Band Bytestreams) has been released. Abstract: This specification defines an XMPP protocol extension that enables any two entities to establish a one-to-one bytestream between themselves, where the data is broken down into smaller chunks and transported in-band over XMPP. Changelog: [See revision history] (psa/jk) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0047.html
Re: [Standards] Forwarding Delivery Draft
On 3/17/09 10:10 AM, Michael Grigutsch wrote: > Hi! Hi MiGri! > In 2006 Peter Saint-Andre wrote a Draft for a JEP which would fill an > important gap: It is about forwarding stanzas. > You can find the document at > http://xmpp.org/extensions/inbox/forwarding-delivery.html There was some controversy about forwarding when the XMPP Council last discussed it: http://logs.jabber.org/coun...@conference.jabber.org/2006-02-09.html http://logs.jabber.org/coun...@conference.jabber.org/2006-03-23.html Perhaps you could read those logs and summarize the objections? I can't remember what the issues were at this point. :) > I would love to see the XSF publish this as an official XEP and I > volunteer to help work on the spec so that we can complete this work. That's great, thanks! It seems that I no longer have the original .xml file for that proposal, so I'll need to reconstruct it from the HTML output. I'll do that soon and send you the file. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Forwarding Delivery Draft
Hi! In 2006 Peter Saint-Andre wrote a Draft for a JEP which would fill an important gap: It is about forwarding stanzas. You can find the document at http://xmpp.org/extensions/inbox/forwarding-delivery.html I would love to see the XSF publish this as an official XEP and I volunteer to help work on the spec so that we can complete this work. Regards /MiGri
Re: [Standards] Proposed XMPP Extension: Server IP Check
XMPP Extensions Editor schrieb: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Server IP Check When IPv4 connections are accepted on IPv6 sockets, the application typically sees a mapped IPv4 address, i.e. 192.0.2.100 gets mapped to :::192.0.2.100. Maybe the spec should note, that such addresses should not get returned to the client, and that for IPv4 connections the real IPv4 address should get always returned. Matthias smime.p7s Description: S/MIME Cryptographic Signature
