Hi,
On Apr 2, 2008, at 10:38 PM, Peter Saint-Andre wrote:
pavlix wrote:
On Mon, 31 Mar 2008 11:38:05 +0100
Pedro Melo [EMAIL PROTECTED] wrote:
On Mar 30, 2008, at 6:18 PM, Fabio Forno wrote:
On Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo
[EMAIL PROTECTED] wrote:
I have nothing very strong
Hi,
On Apr 2, 2008, at 11:30 PM, XMPP Extensions Editor wrote:
This message constitutes notice of a Last Call for comments on
XEP-0209 (Metacontacts).
Abstract: This document specifies an XMPP protocol extension for
defining metacontacts and grouping member JIDs.
URL:
On Thu, Apr 3, 2008 at 7:45 AM, Pedro Melo [EMAIL PROTECTED] wrote:
I wrote a email last week in the standards list about this one. Should I
repost it in this thread? Or move it to the jdev list?
It's still in my inbox to reply to you, it didn't go unnoticed :)
/K
On Apr 3, 2008, at 12:22 AM, Dave Cridland wrote:
On Wed Apr 2 23:22:12 2008, [EMAIL PROTECTED] wrote:
Dave I'm not wholly convinced that, in the current design, it will
actually result in better network usage.
Dave The single thing that worries me most on this is simply that
On Apr 2, 2008, at 11:55 PM, Peter Saint-Andre wrote:
Pedro Melo wrote:
snip/
I'll let the XEP authors comment on your feedback. :)
5. Final thoughts
I must admit that the lack of private storage in the GTalk service
is a
big turn off for us.
Perhaps they will deploy PEP someday. :)
For more than 5 years now, this is being used in production at SAPO. If
several contacts have the same hash (based on the algorithm above) then the
client displays them in the same meta-contact.
This poor man's metacontacts approach could be enough, indeed. I don't
really understand yet why
Dave Cridland wrote:
OpenSSL has negotiated the DEFLATE compression codec defined in RFC 3749
since 0.9.8 came out - the documentation may be wrong, but it always is
with OpenSSL.
TLS only negotiates compression when the client sends a TLSv1 hello.
Which few servers do on the public
On Thu Apr 3 00:56:51 2008, Tobias Markmann wrote:
That's nice to hear for OpenSSL but there is GnuTLS, NSS(Mozilla),
Windows'
SSAPI(SChannel) and YASSL.
I can't speak for any of them, but my understanding is that
compression is pretty commonplace on desktop TLS stacks, now, hence
a
Dave Cridland wrote:
[...]
I notice what you mean.. repeaters have double 'from'.. the sending
server and the originating sender. In a simple no-trust situation
these SHOULD be on the same host or domain, then my server is merely
sending stanzas in my name in a more efficient way. That's
On Thu Apr 3 08:23:36 2008, Pedro Melo wrote:
A) Compression
It's crucial on two counts:
1) It's much simpler to implement, and2) Given that we are (or
should be) encrypting every S2S connection, then TLS is giving us
compression anyway, and moreover, it's cheaper to compress than
not
B) RTT delays
The introduction of Stanza Repeaters gives us RTT delays whenever a
list needs changing. That just strikes me as worrying - I don't think
anyone has clear figures on how much delay would be introduced, but
I'm sure you'll agree that additional latency does not a performance
Dnia 2008-04-03, czw o godzinie 11:36 +0200, Magnus Henoch pisze:
Does anyone know why? (Are there any public non-ejabberd servers to
test with nowadays?)
[EMAIL PROTECTED]:~$ gnutls-cli -p 443 chrome.pl
Resolving 'chrome.pl'...
Connecting to '217.173.160.48:443'...
- Certificate type: X.509
Dave Cridland [EMAIL PROTECTED] writes:
Certainly GnuTLS does DEFLATE according to RFC 3749.
I tried, and it doesn't seem to work:
% gnutls-cli --comp DEFLATE -p 5223 jabber.org
Resolving 'jabber.org'...
Connecting to '208.245.212.98:5223'...
*** Fatal error: A TLS packet with unexpected
Hi,
On Apr 3, 2008, at 8:52 AM, Remko Tronçon wrote:
For more than 5 years now, this is being used in production at
SAPO. If
several contacts have the same hash (based on the algorithm above)
then the
client displays them in the same meta-contact.
This poor man's metacontacts approach
Dnia 2008-04-03, czw o godzinie 12:13 +0100, Pedro Melo pisze:
I don't like the term lower-case. I prefer some sort of
case-ignoring
stuff, but I'll leave that for native speakers to sort out. The
point
is to compare ignoring case.
I think we should use our stringprep profiles.
I.e.
If I give too much relevance to the user nickname or other information in
control of the contact, then I think we are opening up a lot of avenues of
attack. Just showing the avatar is problem enough.
I agree, automatic naming of contacts is quite dangerous. Still, users
ask us for that
Changed the order of discussion: Important stuff first.
Dave Cridland typeth:
| The introduction of Stanza Repeaters gives us RTT delays whenever a
| list needs changing. That just strikes me as worrying -
| It may be possible to alter the protocol to remove these.
Yes that's a bad idea. It
Hi,
On Apr 3, 2008, at 12:32 PM, Remko Tronçon wrote:
If I give too much relevance to the user nickname or other
information in
control of the contact, then I think we are opening up a lot of
avenues of
attack. Just showing the avatar is problem enough.
I agree, automatic naming of
On Thu Apr 3 09:32:22 2008, Philipp Hancke wrote:
Dave Cridland wrote:
OpenSSL has negotiated the DEFLATE compression codec defined in
RFC 3749 since 0.9.8 came out - the documentation may be wrong,
but it always is with OpenSSL.
TLS only negotiates compression when the client sends a
Pedro Melo typeth:
| allow_local_subscription /
Yes, I like this one. That's how junctions do it by default.
| Trust, like, I want to know if the notification is really from my
| friend Peter is a problem for PKI and digital signatures, not the
| multi-cast system on top of XMPP. IMHO.
And
Pedro Melo wrote:
But I'm not opposed to the forms when they will be used to interact with
some-sort-of-human. I think that when a protocol will be used between
software only, data-forms are not the best way to do it. As I said
above, only the second case is a valid use for forms
21 matches
Mail list logo
