That seems quite sensible. Why force the indirection?
I think it was explained up a bit more
- Resource names need to be unique. Forcing a user to choose a unique
name is a heavy thing to do. See the example where a user names both
his laptop and his desktop at work 'Work'.
- With identities,
On Oct 06, 2008, at 18:08, Jonathan Schleifer wrote:
Yes, I agree, privacy lists give us all we need for invisibility.
Some might see this as abusing privacy lists, but IMO, that's what
they are for. They are to block presence or messages to specific
users and/or groups. And all users
On Mon, 6 Oct 2008 16:35:03 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:43 PM, Jonathan Schleifer wrote:
Am 06.10.2008 um 13:30 schrieb Pedro Melo:
IMHO, you should use caps for that.
That's the proper way to solve it. Use an identity client/phone
or
On Tue, 7 Oct 2008 13:12:49 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
Hi,
On Oct 7, 2008, at 12:17 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:33:59 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:39 PM, Michal 'vorner' Vaner wrote:
On Mon, Oct 06, 2008 at 12:30:10PM
On Oct 7, 2008, at 1:12 PM, Pedro Melo wrote:
On Oct 7, 2008, at 12:17 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:33:59 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:39 PM, Michal 'vorner' Vaner wrote:
On Mon, Oct 06, 2008 at 12:30:10PM +0100, Pedro Melo wrote:
On Mon,
On Mon, 6 Oct 2008 17:02:24 +0100
Artur Hefczyc [EMAIL PROTECTED] wrote:
Hi,
While reviewing XEP-0186 just now, I noticed that when a resource
goes invisible, its server must send presence of type unavailable
from that resource. As far as I can see, when a contact's server
receives
Hi,
On Oct 7, 2008, at 1:00 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 11:53:51 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 5, 2008, at 2:07 PM, Pavel Simerda wrote:
Please look into real world, not idealistic.
Servers have sometimes long timeouts (nobody says they can't),
don't do
any
On Oct 7, 2008, at 12:29 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 19:07:24 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 5:27 PM, Jonathan Schleifer wrote:
Ok, I can understand your suggestions now. However, you're missing
one point: What advantage do we get by a
On Oct 7, 2008, at 12:20 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 11:39:11 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 5, 2008, at 1:48 AM, Jonathan Schleifer wrote:
Matthew Wild [EMAIL PROTECTED] wrote:
If they type it manually then they know what they are doing, and
when they
Hi,
On Oct 7, 2008, at 1:19 PM, Kevin Smith wrote:
Doesn't it break the purpose of the caps? I originally thought the
authors wanted to have a reasonable number of different caps to
cache
at the servers.
There's also that the disco spec says that identity / should be
consistent beyond
Pavel Simerda wrote:
On Mon, 6 Oct 2008 17:02:24 +0100
Artur Hefczyc [EMAIL PROTECTED] wrote:
Hi,
While reviewing XEP-0186 just now, I noticed that when a resource
goes invisible, its server must send presence of type unavailable
from that resource. As far as I can see, when a contact's
Pedro Melo wrote:
When I move to invisible, I don't want people to know that I'm
invisible, so if someone in my rosters asks for last activity, the
response should be consistent with my make-believe offline mode: the
last-activity is the time of my logout.
Right.
Giving a radically
On Tue, Oct 7, 2008 at 2:43 PM, Pedro Melo [EMAIL PROTECTED] wrote:
There's also that the disco spec says that identity / should be
consistent beyond what is being suggested here.
You mean section 6.3, Response Consistency?
I do.
I think overloading identity at the deployment level is a bad
On Tue, 7 Oct 2008 13:09:07 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
Hi,
On Oct 7, 2008, at 12:13 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:35:03 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:43 PM, Jonathan Schleifer wrote:
Am 06.10.2008 um 13:30 schrieb
On Mon, 6 Oct 2008 20:06:01 +0200
Remko Tronçon [EMAIL PROTECTED] wrote:
Another idea would be that the client requests a resource from the
server and when it gets disconnected tries to re-use that resource
on reconnecting so the dead connection gets kicked. Two clients
can't kick each
On Mon, 6 Oct 2008 17:24:38 +0200
Remko Tronçon [EMAIL PROTECTED] wrote:
Doesn't solve the issue with you are connected via laptop and
desktop at home and are online using GPRS on the laptop
Neither does setting a resource named 'Laptop', as that doesn't say
anything about your
Imho this is not a protocol issue, but a client issue
This has been discussed in length before, and the conclusion was that
there is no user friendly *and* correct way to do invisibility on top
of privacy lists, or any kind of simple operation (such as blocking).
Psi has a 'simple' user
On Mon, 6 Oct 2008 13:35:56 +0200
Remko Tronçon [EMAIL PROTECTED] wrote:
IMHO, you should use caps for that.
+1. And clients should support this better by showing icons for
different types of resources.
That might prove much better than the current approach.
cheers,
Remko
--
Pavel
Hi,
On Oct 7, 2008, at 12:41 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 19:08:55 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 6:45 PM, Remko Tronçon wrote:
However, that's orthogonal to the original point: If you ask for a
specific resource, I assume you know what you're
Hi,
On Oct 7, 2008, at 12:13 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:35:03 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:43 PM, Jonathan Schleifer wrote:
Am 06.10.2008 um 13:30 schrieb Pedro Melo:
IMHO, you should use caps for that.
That's the proper way to solve
Hi,
On Oct 6, 2008, at 9:07 PM, Justin Karneges wrote:
On Monday 06 October 2008 12:15:56 Pedro Melo wrote:
On Oct 6, 2008, at 7:38 PM, Justin Karneges wrote:
On Monday 06 October 2008 10:45:06 Remko Tronçon wrote:
So, I agree with Pedro that resources should be opaque, and that
what
we
On Mon, 6 Oct 2008 11:53:51 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
Hi,
On Oct 5, 2008, at 2:07 PM, Pavel Simerda wrote:
Please look into real world, not idealistic.
Servers have sometimes long timeouts (nobody says they can't),
don't do
any sort of pings (nobody says they must)
On Mon, 6 Oct 2008 18:28:30 -0400
Eric Will [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 4:31 PM, Peter Saint-Andre wrote:
That seems quite sensible. Why force the indirection?
This seems to be largely a matter of taste as opposed to good
technical reasoning. I don't think there IS a good
On Oct 7, 2008, at 2:52 PM, Kevin Smith wrote:
On Tue, Oct 7, 2008 at 2:43 PM, Pedro Melo [EMAIL PROTECTED]
wrote:
I think overloading identity at the deployment level is a bad
idea, fwiw.
I like to have a name for each connection, and I don't think using
the
resource is the sane way to
On Tue, 7 Oct 2008 13:19:22 +0100
Kevin Smith [EMAIL PROTECTED] wrote:
Doesn't it break the purpose of the caps? I originally thought the
authors wanted to have a reasonable number of different caps to
cache at the servers.
There's also that the disco spec says that identity / should be
Hi,
On Oct 6, 2008, at 9:07 PM, Justin Karneges wrote:
On Monday 06 October 2008 12:15:56 Pedro Melo wrote:
cool, you should name the connections. I think we all agree on that.
I'm just suggesting that you use the name attribute of the disco
identity to do it.
That's what he is there for.
Hi,
On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:50:54 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote:
While reviewing XEP-0186 just now, I noticed that when a resource
goes invisible, its server must send presence of
On Tue, Oct 7, 2008 at 10:43 AM, Andreas Monitzer [EMAIL PROTECTED] wrote:
The privacy lists are very potent, but their complexity is just too much for
mere mortals.
Imho this is not a protocol issue, but a client issue: the interface
should be designed better for hiding the complexity of
Doesn't it break the purpose of the caps? I originally thought the
authors wanted to have a reasonable number of different caps to cache
at the servers.
There's also that the disco spec says that identity / should be
consistent beyond what is being suggested here.
I think overloading identity
Hi,
On Oct 7, 2008, at 12:17 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:33:59 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:39 PM, Michal 'vorner' Vaner wrote:
On Mon, Oct 06, 2008 at 12:30:10PM +0100, Pedro Melo wrote:
On Mon, Oct 06, 2008 at 11:37:34AM +0100, Pedro
On Mon, 6 Oct 2008 19:07:24 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 5:27 PM, Jonathan Schleifer wrote:
Ok, I can understand your suggestions now. However, you're missing
one point: What advantage do we get by a resource that has no
meaing? IMO, nothing. A
Remko Tronçon wrote:
Imho this is not a protocol issue, but a client issue
This has been discussed in length before, and the conclusion was that
there is no user friendly *and* correct way to do invisibility on top
of privacy lists, or any kind of simple operation (such as blocking).
Psi
Version 0.9 of XEP-0186 (Invisible Command) has been released.
Abstract: This document specifies an XMPP-compatible protocol for user
invisibility.
Changelog: Further clarified server and client handling of stanzas during an
invisibility session. (psa)
Diff: http://is.gd/3F9Q
URL:
On Tue, 7 Oct 2008 14:34:15 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
Hi,
On Oct 7, 2008, at 1:00 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 11:53:51 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 5, 2008, at 2:07 PM, Pavel Simerda wrote:
Please look into real world, not
On Tue, 7 Oct 2008 14:40:28 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 7, 2008, at 12:20 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 11:39:11 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 5, 2008, at 1:48 AM, Jonathan Schleifer wrote:
Matthew Wild [EMAIL PROTECTED]
On Tue, 7 Oct 2008 14:50:35 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
Hi,
On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:50:54 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote:
While reviewing XEP-0186 just
Hi,
On Oct 7, 2008, at 5:45 PM, Pavel Simerda wrote:
On Tue, 7 Oct 2008 14:50:35 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:50:54 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre
On Tuesday 07 October 2008 06:46:56 Pedro Melo wrote:
I've started to read the dns-sd.txt you pointed me to, and although I
haven't finished yet, I think you analogie breaks down pretty quickly.
Hmm, you're right. The DNS-SD discussion is about fixed device ids with a
separate name attribute.
On Tuesday 07 October 2008 11:57:21 Justin Karneges wrote:
question whether the extra complexity of having two values instead of one
is worthwhile.
And on that note, the best argument *I* personally see in having two values is
with regard to usability:
- Most users don't want to have to
On Tue, Oct 7, 2008 at 11:27 AM, Remko Tronçon [EMAIL PROTECTED] wrote:
Imho this is not a protocol issue, but a client issue
This has been discussed in length before, and the conclusion was that
there is no user friendly *and* correct way to do invisibility on top
of privacy lists, or any
I just thought of something else:
If you subscribe a bot that sends you messages, maybe you only want it
to send messages when you use a special resource. If we instead use
random resources, that bot needs to ask caps from *EVERY* resource I'm
connected with and search for the name of the
Many argue that privacy lists are too complex for invisibility or
blocking users. For example, the Pidgin developers. They complained
that they need to implement privacy lists completely in order to
achieve invisibility and blocking.
IMO, we could change the XEP to include some reserved
The existing resource generation process from RFC 3920 seems to work
just fine. If clients want to generate randomized resources, they can do
so, or they can ask the server to do so. There's no reason for servers
to be smart about this by overriding client-generated resources. I've
been
Fabio Forno wrote:
(sorry for the delays, but in the last two days of many standards_ml
mails went into the spam folder :( )
Hopefully I just put an end to that!
I agree with the fact there is no general abstraction for privacy
lists and there complexity is far beyond the capabilities of
On Tue Oct 7 22:45:47 2008, Peter Saint-Andre wrote:
Extra side benefit: we can kill off this interminable thread with
the
subject line RCF3920bis07: Resource generation!!!
So we're meant to start a new one with this subject instead?
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] -
On Tue, 7 Oct 2008 17:58:59 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
Hi,
On Oct 7, 2008, at 5:45 PM, Pavel Simerda wrote:
On Tue, 7 Oct 2008 14:50:35 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 16:50:54 +0100
Version 0.32 of XEP-0166 (Jingle) has been released.
Abstract: This specification defines an XMPP protocol extension for initiating
and managing peer-to-peer media sessions between two XMPP entities in a way
that is interoperable with existing Internet standards. The protocol provides a
urn:xmpp:protoname:1
That last portion we'll treat as a version number. Any time we cause
incompatibility between versions of the XEP, we update it. (Note, that's not
every new XEP).
I dislike this solution. One reason is that matching against two
choices (one with :tmp: and one without) is
48 matches
Mail list logo
