Re: [Standards] XEP-0147: "?subscribe" or "?roster"

On 2016-06-07 06:11, Georg Lukas wrote: > Hi, > > I want to expose an xmpp: URI of the user's account in my client to > allow easy "contact sharing" to other IM users. Fortunately, XMPP is > ultra flexible, allowing for any reasonable or potential usage form due > to its separation between

Re: [Standards] Notification of lost membership of non participants in MUC

On 2016-05-17 12:43, Daniel Gultsch wrote: > thanks I missed that because the XEP doesn't mention it for members and > neither ejabberd nor prosody actually do send those messages. Latest Prosody trunk has an option for notifying non-present participants about affiliation changes, but it's a

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

On 2016-05-13 18:10, Kevin Smith wrote: > On 13 May 2016, at 17:05, Dave Cridland wrote: >> There's a problem inherent in this that we'd need to actually verify the >> clients have actually implemented the features they claim, and that in turn >> means some volunteer effort

Re: [Standards] Presence Request

On 2016-04-09 12:16, Vaibhav Ranglani wrote: > Is there a way where we can club presence requests in a single packet? > > Example I need to send presence subscribe requests to multiple users. > a packet like > > > The server software implementing this could forward the requests to the >

Re: [Standards] XEP-0363 and Message MIME content type

Hi, On 01/29/2016 05:38 PM, Anurodh Pokharel wrote: > In the process of implementing XEP-0363 (HTTP file uploads > http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the > realization that it would make a lot of sense to include MIME content type > and size in the message stanza.

[Standards] Source of the JIDs being spammed? -- Re: Suspicion of Jabbim services being hacked

On 2014-12-19 15:24, Peter Viskup wrote: > Hi all, > thought it would be interesting to the audience of this mailinglist. > > http://pinky.jabb.im/2014/12/jabbim-bezpecnostni-problem-security.html > > Best regards, > Someone suggested that JIDs leaked in this incident might be what fueled the

Re: [Standards] NEW: XEP-0367 (Message Attaching)

On 2015-12-15 23:33, Sam Whited wrote: > On Tue, Dec 15, 2015 at 2:32 PM, XMPP Extensions Editor > wrote: >> Version 0.1 of XEP-0367 (Message Attaching) has been released. > > FYI: HipChat is already implementing this protocol in prod. We are > using it to indicate to a client

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

On 2015-11-08 17:45, James Cloos wrote: > When TLSA records are used, the SRV destination should be the only name > checked for in the certs. RFC 7673 says both the service name and the SRV target name IFF the SRV record is secure (per the DNSSEC definition). If not, use only the service name,

Re: [Standards] IQ type=set to query messages in XEP-0313

On 2015-10-27 11:55, Michael Uvarov wrote: > Nice. Probably we should update XEP to specify this. Like this? http://xmpp.org/extensions/xep-0313.html#example-12 Or do you think it should be before the iq-set examples? -- Kim "Zash" Alvefur signature.asc Description: OpenPGP digital

Re: [Standards] IQ type=set to query messages in XEP-0313

On 2015-10-27 11:45, Michael Uvarov wrote: > Why should we send "set" IQ to /get/ messages? It was "get" in the older You use iq-get to get the query form and iq-set to submit it. -- Kim "Zash" Alvefur signature.asc Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

On 2015-09-29 22:02, Sam Whited wrote: > I've brought up reconciling privacy lists and the blocking command in > the past [1], but the discussion faltered and it never went before the > council. It was brought up as part of a recent discussion again [2], > and I'd like to formally propose that it

[Standards] Blocking a MUC participant

Hi, With Privacy lists and Blocking command being brought up, I'd like to raise an issue they both have: blocking a MUC participant. Both XEP-0016 and XEP-0191 states that when someone who has been blocked attempts to communicate with the the user: > For message stanzas, the server SHOULD

Re: [Standards] XEP-0060, offline modifications and efficient synchronization

Hi! On 2015-09-05 16:22, Matthieu Rakotojaona wrote: > - MAM only allows something like "give me everything since this moment", > however using dates is always problematic (clocks are not > synchronized, time can drift, ...) FYI: MAM lets you request by archive id. There doesn't seem to be

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

On 2015-08-26 16:36, Evgeny Khramtsov wrote: Wed, 19 Aug 2015 15:44:30 + (UTC) XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle HTTP Transport Method Abstract: This specification defines two Jingle transport

Re: [Standards] File Transfer Roadmap

mån jul 27 00:33:40 2015 GMT+0200 skrev Sam Whited: Thoughts? Sounds good. -- Zash

Re: [Standards] Prosody Admin Web

On 2015-07-11 17:21, kwaye kant wrote: Hi, Hi, This is not the right mailing list. For Prosody help, see https://prosody.im/discuss -- Regards, Kim Zash Alvefur signature.asc Description: OpenPGP digital signature

Re: [Standards] guest access

fre jun 26 16:45:56 2015 GMT+0200 skrev Peter Saint-Andre - yet: Sure, you need to do the SRV two-step. I'm not sure I understand completely, then. Are you proposing that the target of the SRV record is the XMPP host (and thus ignore the port?)? I'm not sure I understand completely

Re: [Standards] Nonzas: What are they and do we need them?

tors apr 23 02:35:24 2015 GMT+0200 skrev Waqas Hussain: On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus f...@geekplace.eu wrote: The discussion drifted a bit into whether non-stanza top-level stream elements should be used for a particular use case/XEP or not. But what I really wanted to

Re: [Standards] Encrypted Storage (Was: off-server archives with MAM)

On 2015-04-18 11:59, Thijs Alkemade wrote: What do you mean with “SASL state”? All of the data the server has after a SCRAM-SHA-1 exchange is either a) stored on the server, b) session specific. You can’t derive a key from that which the server could not derive on its own. During SCRAM, the

Re: [Standards] Encrypted Storage (Was: off-server archives with MAM)

Further, I don't see why you couldn't have a bot that signs in to your account, enables Carbons and then stores all messages in a local archive, which could then be exposed via MAM to your other clients. -- Kim Zash Alvefur signature.asc Description: OpenPGP digital signature

Re: [Standards] OTR

the current usage of OTR for encrypted messaging. Author: Kim Alvefur Copyright: 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES. Status: ProtoXEP

Re: [Standards] XEP 313 error handling

On 2014-12-04 15:11, Kamil Kisiel wrote: On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland d...@cridland.net mailto:d...@cridland.net wrote: On 3 Dec 2014 21:11, Kurt Zeilenga kurt.zeile...@isode.com mailto:kurt.zeile...@isode.com wrote: How does the server, after it has

Re: [Standards] Proposed XMPP Extension: Recipient Server Side Notifications Filtering

On 2014-06-23 15:03, Evgeny Khramtsov wrote: Mon, 23 Jun 2014 12:11:35 +0100 Dave Cridland d...@cridland.net wrote: On 23 June 2014 11:44, Evgeny Khramtsov xramt...@gmail.com wrote: 1) servers hold too much state What state do you think they hold that they should not? CAPs cache for

Re: [Standards] DEFERRED: XEP-0313 (Message Archive Management)

On 2014-06-23 20:25, Ivan Vučica wrote: I've taken a few moments and looked more closely at XEP-0313. A few comments follow, primarily about section 5.1 Simple configuration. This section can be interpreted as if settings for all jids have to be retransmitted, even if only one change has

Re: [Standards] XEP-0170: Recommended Order of Stream Feature Negotiation

On 2014-04-29 18:12, Kim Alvefur wrote: does not mention XEP 198, Stream Management. 198 does point to 170 however. [...] it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. But for c2s connection

[Standards] XEP-0170: Recommended Order of Stream Feature Negotiation

Hello list, I noticed that XEP-0170 1) talks about the old RFCs and 2) does not mention XEP 198, Stream Management. 198 doesn't use a stream restart, so some description about that could be useful. Is it perhaps time for an update to this XEP (or replacement)? -- Kim Zash Alvefur

[Standards] Carbons - inbound messages to bare jid

Hello, It has been brought up that my Carbons implementation does not follow the Receiving Messages to the Bare JID¹ section. This section says include carbons-enabled sessions in the normal forking of messages as described by XMPP IM². What I implemented was instead to send carbons-wrapped

Re: [Standards] XEP-0048: Bookmarks XML Schema error

On 2014-01-29 20:31, Christian Schudt wrote: I just found an error in the XML Schema for XEP-0048: Bookmarks: Otherwise only one element would be allowed per storage/. The document however states otherwise. It is also not very clear (from the document), if you can mix url/ and

Re: [Standards] digest algorithm in XTLS

Hi, On 2014-01-09 05:55, Peter Saint-Andre wrote: To me, the only things that OTR doesn't currently solve are: 1. Multiple devices 2. Encryption of complete stanzas also: 3. Offline messages. -- Kim Zash Alvefur signature.asc Description: OpenPGP digital signature

Re: [Standards] digest algorithm in XTLS

Hi, On 2013-12-27 13:11, Fedor Brunner wrote: I'm comparing the documents http://xmpp.org/extensions/inbox/jingle-xtls.html https://tools.ietf.org/id/draft-meyer-xmpp-e2e-encryption-02.html Maybe it/they should be using [XEP-0300], which I don't think were around when those documents were

Re: [Standards] Standard for Throttling/Queueing Stanzas

On 2013-10-29 17:47, Spencer MacDonald wrote: Thats correct, compared to SIFT I want: - All stanzas to be buffered by the server - On receiving an allowed element the server should flush its buffer upto and including that stanza, opposed to just letting that stanza through. I tried

Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

On 2013-07-06 14:42, Evgeniy Khramtsov wrote: 3) Regarding 5.3 JID matching. I think we should allow bare servers JIDs in always/never lists and process them as *@server.com (i.e. any JID carrying server.com should match). This will allow us to add the whole servers to the matching lists.

Re: [Standards] Re-escalating update of XEP-0313: MAM

On 2013-10-10 17:52, Dave Cridland wrote: But it's hard - I think there's a good argument for moving any purging and resync to a different spec at least, and keeping MAM simple in scope. Yes, we like simple. If you want resync and deletion there's always XEP-0136 :) signature.asc

Re: [Standards] XEP-280 and MUC private chats

Hello, On 2013-06-09 20:40, Mathieu Pasquet wrote: I was starting to implement carbons in poezio when I came across some kind of design issue that I haven’t been able to work out. However, in the case of private MUC messages (XEP-0045, 7.5), the messages are also of type 'chat', causing

Re: [Standards] Application-level delivery notification between server and client

On 2013-08-06 22:15, Daniele Ricci wrote: Please correct me if I'm wrong at any point, just to be sure I understand XEP 198 and how I can use it in the right way. First of all, in this: the client or server can send ack elements at any time over the stream this means that I can send a/ or

Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

On 2013-07-24 19:23, Matthew Wild wrote: On 24 July 2013 17:46, Yann Leboulanger aste...@lagaule.org wrote: On 06/11/2013 10:38 PM, XMPP Extensions Editor wrote: There sould be a way to retrieve preferences. If I use a new client (on another machine for example), or if preferences have chnges

Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

On 2013-07-24 19:50, Matthew Wild wrote: Are push notifications for the prefs really necessary? Not sure. But it would help against race conditions, and save you from needing to fetch the prefs every time before doing any changes. I'm not entirely convinced in either direction. We need more

Re: [Standards] XEP-0313 Message Archive Management Message Removal

On Sat, 18 May 2013, 14:23:43 CEST, Spencer MacDonald spencer.macdonald.ot...@gmail.com wrote: Also you may say something that is confidential that you might want to remove after the recipient has acknowledged it. You really want to use some end-to-end encryption for that. Carbons (XEP-280)

Re: [Standards] Using .well-known/ to supplement XEP-0156

On 2013-05-18 15:44, Matthew Miller wrote: As a self-proclaimed member of the DNS anti-proliferation league, I fully support this. (-: As a self-proclaimed member of the anti-HTTP resistance, I wish to express my great annoyance. :P -- Kim signature.asc Description: OpenPGP digital

Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)

On 2013-02-21 01:43, XMPP Extensions Editor wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. 3. Do you plan to implement

Re: [Standards] XEP-0196 modification

On 2013-03-12 17:29, Mathieu Pasquet wrote: I am implementing User Gaming in poezio in order to share e.g. the current multiplayer game in play, with a server and a port to join (if any, of course), and I think a server_port/ subelement would be useful, because it would be clearer and more

[Standards] XEP-198: Resumption after resource binding

Hi! I noticed that XEP-198 doesn't say anything trying to resume after doing resource binding. And I was looking because I saw a client do this. This doesn't seem like something that should be allowed. Does everyone agree that this is a silly thing and that the XEP should point out how silly

Re: [Standards] some more questions about XEP-0198

On 01/26/2013 10:30 PM, Dave Cridland wrote: Acks without resumption are still interesting - a client can flag unacked stanzas, a server can redirect them into offline storage as appropriate, and so on. Some more discussion (in the XEP) on this would be nice I think. Such a text could

[Standards] Carbons, message types

Hello! XEP-0280 currently only talks about type='chat' messages. In order to truly have a consistent view from all devices, wouldn't you want other types of messages to be carbon'd too? I'm not sure exactly what the best rules would be, for example you would not want PEP events to be included

[Standards] Fwd: Carbons, message types

Resent due to DKIM issue. Apologies if you already received it. Original Message Subject: [Standards] Carbons, message types Date: Sun, 13 Jan 2013 14:56:44 +0100 From: Kim Alvefur z...@zash.se Reply-To: XMPP Standards standards@xmpp.org To: XMPP Standards standards@xmpp.org

Re: [Standards] [Council] XEP-0258 1.1

On 2013-01-10 14:40, Kurt Zeilenga wrote: On Jan 8, 2013, at 8:21 AM, Ashley Ward ashley.w...@surevine.com wrote: Also, I wonder if, as a future update, some kind of hint from the server about catalog lifetime would be useful. Or this may just be a solution in search of a problem! The

Re: [Standards] XMPP OAuth2 login at Google

On 2012-09-17T21:10:20 CEST, Randy Turner wrote: PLAIN is going to be deprecated, even though TLS is pretty much ubiquitous? Looks like it only affects GTalk. -- Regards, Kim Zash Alvefur signature.asc Description: OpenPGP digital signature

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

If we want the `reason` bit to be flexible, why not make it some combination of a text label and a registry, perhaps similar to stanza errors. Maybe reuse the features (XEP 30, Disco) registry, like: decloak reason ver=urn:xmpp:jingle:apps:rtp:audioVoice call/reason /decloak -- Regards, Kim

Re: [Standards] [xmpp] XEP-0170: compression after dialback

. The session management plugin has a setting for enabling it on s2s streams. -- Kim Alvefur z...@zash.se

Re: [Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL

' etc. Regards, Kim Alvefur

Re: [Standards] UPDATED: XEP-0312 (PubSub Since)

to subscribe to you? -- Kim Alvefur z...@zash.se

Re: [Standards] Timezone element in XEP-0080: User Location

XML Namespaces saves the day! One advantage of XEP-0202 over the XEP-0080 approach is that the latter will not work on Google's servers. Both of these are basically data description formats. I don't see why either of them should be limited PEP or simple iq stanzas. -- Kim Alvefur z...@zash.se

Re: [Standards] Timezone element in XEP-0080: User Location

On Wed, 2012-05-16 at 15:20 +, Todd Herman wrote: Are you already using PEP (XEP-0163)? This is not something available by default. It's available on most popular and modern XMPP servers that I know of, with gmail being the one exception. (Sorry for the slight OT) -- Kim Alvefur z

Re: [Standards] Timezone element in XEP-0080: User Location

On Wed, 2012-05-16 at 15:13 +0100, Jonny Lamb wrote: will not work on Google's servers. Btw, there are basically two solutions to this: 1) Work around it. (I.e. don't use PEP) 2) Get Google to add PEP support. One of these is a real and long term solution. :) -- Kim Alvefur z...@zash.se

Re: [Standards] Discovering components and component features

a disco#items query to your own server, then sending disco#info to each of the returned items. -- Kim Alvefur z...@zash.se

Re: [Standards] NEW: XEP-0313 (Message Archive Management)

your outgoing messages, with the archived/ stamp. Or, some cross between that and Delivery Receipts, which just contain the archived/ with the UID. Message Archive Receipts? -- Kim Alvefur z...@zash.se

Re: [Standards] NEW: XEP-0313 (Message Archive Management)

rejoicing. (mw) Finally! Much rejoicing indeed! -- Kim Alvefur z...@zash.se signature.asc Description: This is a digitally signed message part

Re: [Standards] LAST CALL: XEP-0297 (Message Forwarding)

On Thu, 2012-02-16 at 22:29 +, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0297 (Message Forwarding). Abstract: This document defines a protocol to forward a message from one entity to another. URL:

Re: [Standards] XEP-0045 nick changes

On 1/24/12 2:58 PM, Dave Cridland wrote: I recall - ages ago - that we were going to, at one point, mention that if you change your nickname, you should send unavailable persence after the change to the old nick: C: presence to='room@service/new_nick'/ S: presence

[Standards] MAM

On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote: On 01/12/2012 01:41 AM, Kim Alvefur wrote: On Tue, 2012-01-10 at 17:33 +0700, Sergey Dobrov wrote: Matt Wild's upcoming archiving spec is a good candidate for this. /K Where I can take a look on it? Here: http

Re: [Standards] PEP and PubSub

, and queried there. Dave mentioned adding a 'node' parameter which would be helpful in this case. -- Kim Alvefur z...@zash.se

Re: [Standards] PEP and PubSub

On Thu, 2012-01-12 at 22:37 +0700, Sergey Dobrov wrote: On 01/12/2012 08:57 PM, Kim Alvefur wrote: On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote: Then, I understand that the XEP will be useful for current Pubsub but it will not be useful for current PEP because filtering

Re: [Standards] PEP and PubSub

://code.google.com/p/prosody-modules/source/browse/mod_mam/mod_mam.lua http://code.zash.se/verse/file/tip/plugins/archive.lua -- Kim Alvefur z...@zash.se

[Standards] Carbons implementation

://code.matthewwild.co.uk/verse/file/tip/doc/example_carbons.lua -- Kim Alvefur z...@zash.se signature.asc Description: This is a digitally signed message part

Re: [Standards] Use of Message Forwarding in other XEPs

separation of metadata and content. But more importantly, I think that consistency among forwards-using XEPs would be nice. -- Kim Alvefur z...@zash.se

Re: [Standards] Chat continuation on different device

On Fri, 2011-12-23 at 20:01 -0800, Artur Hefczyc wrote: Hi, I frequently switch IM client running on different devices (mobile, laptop, ) and I would love to have a feature to continue last chat with some recent chat messages displayed on a new device. I have an idea how to implement

Re: [Standards] XEP-0077: disco feature

On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote: XEP-0077 (In-Band Registration) does not define a disco feature for advertising support for jabber:iq:register. I have a use case in which this would be very handy. I'm pretty sure this is already standard practice for at least

Re: [Standards] UPDATED: XEP-0267 (Server Buddies)

On Mon, 2011-12-12 at 20:36 +, XMPP Extensions Editor wrote: Changelog: Updated ad-hoc command with field for the sending server; added XMPP Registrar Considerations. (psa) What about the 'to' attribute of the iq/ ? -- Kim Alvefur z...@zash.se

Re: [Standards] UPDATED: XEP-0267 (Server Buddies)

Hi I had some thougts about using PEP in combination with this for sharing things like peer server certs seen, and incident reports. - Original message - Version 0.2 of XEP-0267 (Server Buddies) has been released. Abstract: This specification defines a convention for presence

Re: [Standards] disco#info Results Ordering

to be in a specific order. -- Kim Alvefur z...@zash.se

[Standards] Use of Message Forwarding in other XEPs

/ element[1]. Would it be better or worse to, let's say, have this as a child of the parent message/? 1: http://xmpp.org/extensions/xep-0280.html#example-13 -- Kim Alvefur z...@zash.se signature.asc Description: This is a digitally signed message part

Re: [Standards] XEP-0280: Message Carbons

On Mon, 2011-10-31 at 08:58 -0600, Matthew A. Miller wrote: On Oct 29, 2011, at 14:14, Kim Alvefur wrote: http://xmpp.org/extensions/xep-0280.html#inbound Messages of type chat that are addressed to the bare JID (localpart@domain) MUST be copied by the receiving server to all

[Standards] XEP-0280: Message Carbons

means. The process of making copies is known as forking. This seems weird. What's the reason for mandating this specific behavior instead of just referencing what XMPP-IM says? http://tools.ietf.org/html/rfc6121#section-8.5.2.1 -- Kim Alvefur z...@zash.se

Re: [Standards] fyi: Evented APIs www.eventedapi.org

On Thu, 2011-10-20 at 23:46 +0100, Matthew Wild wrote: If email were just being invented today, it would use HTTP... I have no doubt. http://blog.mailgun.net/post/11622797058/mailgun-api-2-0-forget-mime Just wait for them to propose that as a standard for s2s delivery. -- Kim Alvefur z

[Standards] Time to look at anti-spam XEPs? [Fwd: Re: [Operators] Strange users]

spamming problem on jabber. So, is it time to bring up the various anti-spam/abuse related XEPs? -- Kim Alvefur z...@zash.se

Re: [Standards] UPDATED: XEP-0292 (vCard4 Over XMPP)

it describes? That could make it simple if you only want to fetch a specific item. -- Kim Alvefur z...@zash.se

Re: [Standards] Account Management protoXEP

Would it make any sense whatsoever to have account registration at the SASL level? Just a thougt. - Original message - Council decided to postpone accepting/rejecting this protoXEP until a sense of community opinion had been gathered. What seem to me like reasonable objections to

[Standards] XEP 60: PubSub still has payment-required

The payment-required stream error was afaik removed from XMPP Core, so should it be removed from XEP 60? It could be moved to the pubsub#errors namespace. http://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-error-payment -- Kim Alvefur z...@zash.se

Re: [Standards] Suggestion for XEP-0045 : permit alias for the MUC address

stanza as when the room is destroyed. And maybe we should discourage implementations from letting anyone recreate the room for a while? [1]: http://xmpp.org/extensions/xep-0045.html#destroyroom -- Kim Alvefur z...@zash.se

Re: [Standards] XEP-0198: Stream Management - Clarifications

, the other end might misinterpret that as a failure to ack. A new error condition seems overkill to me. But if an implementation doesn't send any a/s at all, causing the unacked queue to become annoyingly large, policy-violation might make sense. -- Kim Alvefur z...@zash.se

Re: [Standards] MSN does XMPP

connect but it requires X_MESSENGER_OAUTH2 sasl authentication. Is there docs on that somewhere yet?

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

On Wed, 2011-08-24 at 16:19 -0600, Peter Saint-Andre wrote: Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Did someone have a good reason to not allow both methods? -- Kim Alvefur z...@zash.se

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

and want to save a few bytes. ;) Also, maybe we should also look at making XEP-84 MUC-friendlier? -- Kim Alvefur z...@zash.se

Re: [Standards] Avatars

for the hash and one for the actual data. You can still get the vCard with an appropriate item fetching IQ and MEP is something it would be nice to see move forward anyway. Yeah, what exactly does the current iqvcard//iq method gain us over iqpubsubitems node=vcard//pubsub/iq ? -- Kim Alvefur z

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

On Fri, 2011-08-19 at 22:04 +0200, Andreas Monitzer wrote: Why doesn't it use plain PEP, instead defining its own protocol? It did, see this thread: http://mail.jabber.org/pipermail/standards/2011-April/024355.html -- Kim Alvefur z...@zash.se

Re: [Standards] communication context

in that, Perhaps in rfc6121bis we should remove show/ and status/ then? ;-) Let's not descend into We could use PubSub/PEP for everything! ;-P Also +1 on the PEP already does this -- Kim Alvefur z...@zash.se

[Standards] XEP-0157: Contact Addresses for XMPP Services -- Missing admin-addresses in registry?

The example at http://xmpp.org/extensions/xep-0157.html#example-2 has an 'admin-addresses' field, but this is not in the registry, http://xmpp.org/registrar/formtypes.html#http:--jabber.org-network-serverinfo Is this a mistake or should it be added? -- Kim Alvefur z...@zash.se

Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation

measures. Or do we have this already? identity category=client type=phone/ ? How about a Informal XEP about applying ping/keepalive/buffering based on that? -- Kim Alvefur z...@zash.se

Re: [Standards] BOSH vs. TCP for mobile

So, does anyone recommend a standardized method of a sub-70-byte keep alive message ? A space character? And how much is xep-199 pings? Or a 198 ack? And with compression? -- Sent from my totaly awesome N900 :P

Re: [Standards] RFC vs privacy lists

Let's say I configure a list to block all IQ for jid with subscription=none (nice anti-spam rule). Now I don't get any iq answer to, let's say, disco#info on my server. That's normal because RFC [1] says that Privacy lists MUST be the first delivery rule applied by a server, superseding

Re: [Standards] FWD: XEP-0277 message

StatusNet does: link rel='enclosure' type='image/png' length='1057' href='http://example.org/file.png'/ See http://tools.ietf.org/html/rfc4287#section-4.2.7 -- Kim Alvefur z...@zash.se signature.asc Description: This is a digitally signed message part

Re: [Standards] Proposed XMPP Extension: Remote Authentication

do you think? Because legacy MUC passwords are sent in the clear, a given MUC service might not want to accept that other method, but in practice I think they would for quite a while. How about something new instead of `feature var='muc_passwordprotected'/' to advertise SASL support. -- Kim

Re: [Standards] Proposed XMPP Extension: Remote Authentication

On Thu, 2010-12-02 at 20:18 +0500, Waqas Hussain wrote: S2S poses an issue for normal EXTERNAL auth for remote clients. Didn't someone mention direct communication with the MUC host over Jingle? Then XTLS! :D -- Kim Alvefur z...@zash.se signature.asc Description: This is a digitally signed

Re: [Standards] Proposed XMPP Extension: Remote Authentication

and subdomains etc. -- Kim Alvefur z...@zash.se signature.asc Description: This is a digitally signed message part

<    1   2