Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
Looks fine to me, looking forward for Zenek's comments! Pavel On Sat, 16 Aug 2008 20:52:20 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 20:15:35 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Zenon Kuder jr. wrote: Dne Friday 15 of August 2008 23:45:44 Peter Saint-Andre napsal(a): Pavel Simerda wrote: If we need metadata to specify the origin, we can add an additional optional metadata element inside the data/. Sure, we could do that. So something like this? data cid='[EMAIL PROTECTED]' origin='http://bundles.jabbim.cz/'/ Peter Seems nice. We should specify the hash algorithm in the cid somehow though. I don't know what the common practice for that would be. We might do something like this: 1. [EMAIL PROTECTED] 2. [EMAIL PROTECTED] I don't have a strong preference. I might have a slight preference for #1, because it's possible that we might even host image bundles at those domains via HTTP (so if your client supports SHA1 it can go to the URL http://sha1.bob.xmpp.org/ and retrieve the public images hosted there). Possibly. :) I prefer #2. We could possibly host on bob.xmpp.cz anyway. Sure/ If we ever host these images, bob.xmpp.org could round-robin to other domains, or just redirect. And since we use hash now, we don't need to cache per JID. Nifty. But we may if we don't want to check the hash or don't believe the hash functions (future consideration). Depends on the implementation and configuration. Correct. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Pavel On Sat, 16 Aug 2008 20:08:55 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 15:47:17 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Oh sure, one example is [EMAIL PROTECTED] :) /psa But that means we have some sort of room authorization :). And we should know what happens if you invite someone to a room that's members-only and he's not a member. Because just sending a direct invite is no good. Making him a member and sending a direct invite seems natural to me. I've added an implementation note about that. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. I'm leaning toward crossing that bridge when we come to it. My reason for bringing invite-only rooms was not to suggest they should be done, just that this protocol takes away the possibility to implement them (and it happens to be something I was thinking about a couple of weeks ago). We don't have invite-only rooms, but IRC doesn't have members-only rooms. I can't think of many cases an invite-only room would be called for, unless it is an admin doing the inviting, in which case it is easy to add invitees to the member list. That, or just use a password, as exampled in this XEP. Matthew.
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Matthew Wild wrote: On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. I'm leaning toward crossing that bridge when we come to it. My reason for bringing invite-only rooms was not to suggest they should be done, just that this protocol takes away the possibility to implement them (and it happens to be something I was thinking about a couple of weeks ago). We don't have invite-only rooms, but IRC doesn't have members-only rooms. I can't think of many cases an invite-only room would be called for, unless it is an admin doing the inviting, in which case it is easy to add invitees to the member list. That, or just use a password, as exampled in this XEP. Agreed. Members-only rooms seem much more natural than invite-only rooms, especially because we have authenticated identities. IRC doesn't have authentication, so they might need some kind of cryptographic invitations, but AFAICS that's overkill for XMPP. Peter smime.p7s Description: S/MIME Cryptographic Signature
