On Thu, 14 Aug 2008 11:27:22 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Pavel Simerda wrote:
> > On Wed, 13 Aug 2008 08:18:43 -0500
> > XMPP Extensions Editor <[EMAIL PROTECTED]> wrote:
> >
> >> http://www.xmpp.org/extensions/inbox/direct-invitations.html
> >
> > Hmm, good idea, this s
On Thu, 14 Aug 2008 11:18:23 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Zenon Kuder jr. wrote:
> > Dne Thursday 14 of August 2008 17:00:37 Pavel Simerda napsal(a):
> >> On Thu, 14 Aug 2008 15:40:14 +0200
> >>
> >> "Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
> >>> Hi again, I came up wit
Pavel Simerda wrote:
On Thu, 14 Aug 2008 10:38:42 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
Pavel Simerda wrote:
What I suggest to satisfy the Jabbim developers (and possibly others
with similar needs) the following two modifications:
1) Only force UUID if we use the domain part of t
On Thu, 14 Aug 2008 10:38:42 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Pavel Simerda wrote:
> > On Thu, 14 Aug 2008 13:26:00 +0200
> > "Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
> >
> >> Hello,
> >> I have a few questions regarding BoB which came up in our Jabbim
> >> client developm
The 2007-2008 XMPP Council and XSF Board of Directors were elected in
September 2007. Therefore we have to select the next Board and Council. XMPP
Council members must be elected members of the XSF, there is no such
restriction for the Board of Directors.
If you are interested in running for Board
Matthew Wild wrote:
On Thu, Aug 14, 2008 at 6:27 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
Pavel Simerda wrote:
It seems MUC authorization was removed from [xep 0235]. Isn't now
the time to find a better place for it?
Maybe. I'm not sure how useful MUC authorization is.
IRC has the c
On Thu, Aug 14, 2008 at 6:27 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Pavel Simerda wrote:
>> It seems MUC authorization was removed from [xep 0235]. Isn't now
>> the time to find a better place for it?
>
> Maybe. I'm not sure how useful MUC authorization is.
>
IRC has the concept of inv
Alban Crequy wrote:
Le Thu, 14 Aug 2008 11:16:00 -0600,
Peter Saint-Andre <[EMAIL PROTECTED]> a écrit :
Peter Saint-Andre wrote:
Yes, that seems good. I will update the spec along these lines and
post a temporary link to the provisional version.
Here is my revised text.
***
9. Ending a Me
Le Thu, 14 Aug 2008 11:16:00 -0600,
Peter Saint-Andre <[EMAIL PROTECTED]> a écrit :
> Peter Saint-Andre wrote:
>
> > Yes, that seems good. I will update the spec along these lines and
> > post a temporary link to the provisional version.
>
> Here is my revised text.
>
> ***
>
> 9. Ending a Mes
Pavel Simerda wrote:
On Wed, 13 Aug 2008 08:18:43 -0500
XMPP Extensions Editor <[EMAIL PROTECTED]> wrote:
http://www.xmpp.org/extensions/inbox/direct-invitations.html
Hmm, good idea, this simple direct invitation protocol, it makes sense
to send invitation to the people I invite.
Well that'
Zenon Kuder jr. wrote:
Dne Thursday 14 of August 2008 17:00:37 Pavel Simerda napsal(a):
On Thu, 14 Aug 2008 15:40:14 +0200
"Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
Hi again, I came up with some more comments :-)
From introductory text of section 2.1:
"[...] If the data is not cached, the
Peter Saint-Andre wrote:
Yes, that seems good. I will update the spec along these lines and post
a temporary link to the provisional version.
Here is my revised text.
***
9. Ending a Messaging Session
To end the chat, either party closes the XML stream:
Example 6. Ending the Chat
The o
Dne Thursday 14 of August 2008 17:00:37 Pavel Simerda napsal(a):
> On Thu, 14 Aug 2008 15:40:14 +0200
>
> "Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
> > Hi again, I came up with some more comments :-)
> >
> > From introductory text of section 2.1:
> > "[...] If the data is not cached, the recipie
Alban Crequy wrote:
Le Wed, 13 Aug 2008 12:58:10 -0600,
Peter Saint-Andre <[EMAIL PROTECTED]> a écrit :
Alban Crequy wrote:
Hi,
In a link-local conversation with XEP-0174, a client A sends the
ending stanza to the other end's client B: ""
http://www.xmpp.org/extensions/xep-0174.html#end
Af
Pavel Simerda wrote:
On Thu, 14 Aug 2008 15:40:14 +0200
"Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
Hi again, I came up with some more comments :-)
From introductory text of section 2.1:
"[...] If the data is not cached, the recipient would then retrieve
the data by sending an IQ-get to the s
Pavel Simerda wrote:
On Thu, 14 Aug 2008 13:26:00 +0200
"Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
Hello,
I have a few questions regarding BoB which came up in our Jabbim
client development room. I have read throught the mails regarding it
in this list (more or less thoroughtfully, so please
Maciek Niedzielski <[EMAIL PROTECTED]> wrote:
> MUC server doesn't need any complex algorithm to generate a name that
> is not used - it can pick a random name and simply check if it's
> already used or not ;)
On the server side, it doesn't even need to be a random number. It
could just be a coun
Pavel Simerda wrote:
On Thu, 14 Aug 2008 09:09:28 +0200
Yann Leboulanger <[EMAIL PROTECTED]> wrote:
Peter Saint-Andre wrote:
But then you have a dependency on the server side, right? Why not
just generate a UUID on the client side?
Because we don't know all the rooms that are opened, and we can
Pavel Simerda wrote:
On Wed, 13 Aug 2008 15:03:21 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
Look, we're trying to work around presence blocking. Some servers
will only let through because of privacy
lists (or what looks like a privacy list anyway, a la Google Talk),
and a new value for
This seems to be a good reason to keep things as they work :).
Pavel
On Thu, 14 Aug 2008 15:21:22 +0200
Jonathan Schleifer <[EMAIL PROTECTED]> wrote:
> Am 14.08.2008 um 15:12 schrieb Kevin Smith:
>
> > Well, in this case what I imagined was a server that's happy to host
> > short-lived one-to-o
Nothing is guaranteed, in practice.
On Thu, 14 Aug 2008 15:20:26 +0200
"Remko Tronçon" <[EMAIL PROTECTED]> wrote:
> > Um, the whole point of a UUID is that it's universally unique, no?
>
> No, the point of a UUID is that everybody can generate an ID that has
> a (very) high probability of being
On Thu, 14 Aug 2008 09:09:28 +0200
Yann Leboulanger <[EMAIL PROTECTED]> wrote:
> Peter Saint-Andre wrote:
> > Yann Leboulanger wrote:
> >> Peter Saint-Andre wrote:
> >>> Has any MUC implementation coded in support for the "unique room
> >>> name request" feature described in Section 10.1.4 of XEP-
On Wed, 13 Aug 2008 15:03:21 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Pavel Simerda wrote:
> > On Tue, 12 Aug 2008 00:31:00 -0700
> > Justin Karneges <[EMAIL PROTECTED]> wrote:
> >
> >> On Monday 11 August 2008 14:04:22 Pavel Simerda wrote:
> >>> On Mon, 11 Aug 2008 13:45:08 -0600
> >
On Thu, 14 Aug 2008 15:40:14 +0200
"Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
> Hi again, I came up with some more comments :-)
>
> From introductory text of section 2.1:
> "[...] If the data is not cached, the recipient would then retrieve
> the data by sending an IQ-get to the sender (or pote
Kevin Smith wrote:
But then you have a dependency on the server side, right? Why not just
generate a UUID on the client side?
Well - turn this on its head:
There are two options on the table.
1) Do it client side, and /probably/ everything works.
2) Do it server side (where it's easier), and ev
On Thu, 14 Aug 2008 13:26:00 +0200
"Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
> Hello,
> I have a few questions regarding BoB which came up in our Jabbim
> client development room. I have read throught the mails regarding it
> in this list (more or less thoroughtfully, so please excuse me if I
>
Hi again, I came up with some more comments :-)
From introductory text of section 2.1:
"[...] If the data is not cached, the recipient would then retrieve the data
by sending an IQ-get to the sender (or potentially some other entity) [...]"
I think the "potential other entity" might be an intere
Am 14.08.2008 um 15:12 schrieb Kevin Smith:
Well, in this case what I imagined was a server that's happy to host
short-lived one-to-one-to-many-to-many chats at randomly selected room
names, but doesn't want to be hosting public chat rooms such as
[EMAIL PROTECTED], but it's probably unimportant
> Um, the whole point of a UUID is that it's universally unique, no?
No, the point of a UUID is that everybody can generate an ID that has
a (very) high probability of being unique; it's not, however,
guaranteed to be unique.
cheers,
Remko
On Thu, Aug 14, 2008 at 4:50 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> Plus it's conceivable that a muc service would only want to serve
>> rooms at addresses it supplies.
> What difference does it make if the MUC service generates a UUID or the
> client generates a UUID? One UUID is as g
Matthew Wild wrote:
On Wed, Aug 13, 2008 at 6:41 PM, Justin Karneges
<[EMAIL PROTECTED]> wrote:
There are many places where a UUID may be appropriate, but I don't think this
is one of them. You're desiring an unique handle to the MUC service, and the
MUC itself is really the authority for that.
Kevin Smith wrote:
I'd buy client-asserted hashes if conferencing was some peer-to-peer thing,
but MUC is a client/server design.
Plus it's conceivable that a muc service would only want to serve
rooms at addresses it supplies.
What difference does it make if the MUC service generates a UUID
Justin Karneges wrote:
On Tuesday 12 August 2008 23:01:13 Kevin Smith wrote:
On Wed, Aug 13, 2008 at 12:24 AM, Peter Saint-Andre <[EMAIL PROTECTED]>
wrote:
Has any MUC implementation coded in support for the "unique room name
request" feature described in Section 10.1.4 of XEP-0045? I think th
Hello,
I have a few questions regarding BoB which came up in our Jabbim client
development room. I have read throught the mails regarding it in this list
(more or less thoroughtfully, so please excuse me if I missed something), but
haven't followed the chat sessions Pavel and Peter had.
I'm sor
Le Wed, 13 Aug 2008 12:58:10 -0600,
Peter Saint-Andre <[EMAIL PROTECTED]> a écrit :
> Alban Crequy wrote:
> > Hi,
> >
> > In a link-local conversation with XEP-0174, a client A sends the
> > ending stanza to the other end's client B: ""
> >
> > http://www.xmpp.org/extensions/xep-0174.html#end
>
>> But then you have a dependency on the server side, right? Why not just
>> generate a UUID on the client side?
Well - turn this on its head:
There are two options on the table.
1) Do it client side, and /probably/ everything works.
2) Do it server side (where it's easier), and everything certain
Peter Saint-Andre wrote:
Yann Leboulanger wrote:
Peter Saint-Andre wrote:
Has any MUC implementation coded in support for the "unique room name
request" feature described in Section 10.1.4 of XEP-0045? I think
this feature is unnecessary and (in the interest of simplification) I
would like to
37 matches
Mail list logo
