Thomas Charron:
> Richard Laager wrote:
> > Where's the *harm* in allowing people to redistribute derivative works?
> People possibly change the spec, and distribute it indistinguishable
from the original.
> But then I suppose that could be taken care of by clarifying that the
derivative must b
Greg Hudson wrote:
On Tue, 2007-09-11 at 19:51 +0100, Dave Cridland wrote:
If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for
TLS+YAP (the latter being plaintext-equiv on the server, but only a
single round-trip, so great for mobiles).
You may be missing the most pop
Peter Saint-Andre wrote:
Ian Paterson wrote:
In real life servers will always be compromised (especially in cases
where the attacker is the service provider). So SASL PLAIN still
contains a serious vulnerability that is easily fixed in those cases
where DIGEST-MD5 is a practical option
Kevin Smith wrote:
On 11 Sep 2007, at 17:20, Ian Paterson wrote:
Even where TLS is available, SASL PLAIN requires server operators to
keep copies of all users' passwords. This is a serious (and often
unnecessary) security weakness.
I'm not sure that's true; the server could ha
Peter Saint-Andre wrote:
Back in August I emailed about this issue [1] with the IETF area
directors for applications and security, relevant WG chairs, and
interested others. The conclusion was that in rfc3920bis we would make
the following changes to the mandatory-to-implement technologies:
1. R
Dave Cridland wrote:
On Tue Sep 11 11:55:35 2007, Jonathan Chayce Dickinson wrote:
Interesting because most clients used Digest-MD5, so what do we use now?
Cram-MD5? Or is there some other newfangled method out there?
DIGEST-MD5 is still more secure than CRAM-MD5, and this won't change
becaus
Peter Saint-Andre wrote:
Ian Paterson wrote:
Note that this separation of layers enables the protocols to be used
independently, however, the fact that the two negotiations are carried
out simultaneously creates latency in the establishment of a call
(something that AFAICT is an issue in the
Niklas Höglund wrote:
I'd like all my communication to be encrypted end-to-end, so I like
the development going on in the jabber community on that side. Voice
calls are also very useful, but from a quick look at the jabber XEPs I
can't see how these two features should interoperate.
How should t
Ian Paterson wrote:
Currently the name of the group that contacts will be added to tends
to be hardcoded on the gateway. This causes problems if there are
language issues or, more typically, if the user has two accounts on a
legacy service (accessed via two instances of a gateway server) - in
Tomasz Sterna wrote:
Dnia 15-08-2007, śro o godzinie 18:31 +0100, Ian Paterson napisał(a):
Currently the name of the group that contacts will be added to tends
to be hardcoded on the gateway.
You are talking about gateway XEP-0144 usage?
Yes, or the direct roster editing that
Peter Saint-Andre wrote:
Ian Paterson wrote:
Peter Saint-Andre wrote:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?%40diffMode=u&%40diffWrap=s&r1=1092&r2=1134&u=3&ignore=&k=
TinyURL: http://tinyurl.com/2dxv5j
That looks good, thanks :-)
S
Greg Hudson wrote:
A generic XML editor isn't going to know much about the semantics of the
document it is editing. It's not necessarily going to be a good
framework for a whiteboarding application, any more than emacs is a good
foundation for Photoshop. They both edit files, but...
Nobody
Peter Saint-Andre wrote:
Peter Saint-Andre wrote:
Ian Paterson wrote:
XEP-0100 "Gateway Interaction" doesn't, AFAICT, explain whether the
username supplied at registration should be the "Legacy Service
username" or the "Jabber username". [The
XEP-0100 "Gateway Interaction" doesn't, AFAICT, explain whether the
username supplied at registration should be the "Legacy Service
username" or the "Jabber username". [The difference between these
usernames (typically escaping) is explained in section 6.2 (User
Addressing).]
Can anyone pleas
lient interpreted what she
typed, and can therefore control what the receiving user will see before
clicking .
Alex Jones wrote:
On Wed, 2007-08-08 at 13:21 +0100, Ian Paterson wrote:
Mridul Muralidharan wrote:
If we just add another tag to explicitly mark emoticons - and remove
Alex Jones wrote:
This isn't about formatting, this is about getting rid of the guesswork.
Similar problems arise in parsing out icons in the presence of things
like regular expressions. Or maybe even regular chat:
Count the screws (there should be 8)
Incorrectly gets parsed out as
Count the s
Robin Redeker wrote:
Great, JIDs with '\20' in the beginning and end have been deprecated then?
Shouldn't the RFC be changed then?
Maybe. I don't know what other people think, but it seems like XEP-0106
could be usefully rolled into 3920bis. Employing SHOULDs instead of
MUSTs (for things l
Peter Saint-Andre wrote:
Michal 'vorner' Vaner wrote:
So just one last question - how does a client know, when to send direct
or usual presence?
Sends both?
Perhaps. Inviting people to rooms happens infrequently enough that it's
not a bandwidth issue. But it may be confusing for the rec
Peter Saint-Andre wrote:
The following XEPs have been inactive for 6+ months and therefore are
subject to automatic deferral. If you have an interest in these specs,
please speak up.
XEP-0154: User Profile
http://www.xmpp.org/extensions/xep-0154.html
Now that PEP/PDP are being fin
Dave Cridland wrote:
For maximum pedantry, you might note that the base64 encoding used
MUST NOT contain whitespace (which RFC 4648 says is the default
anyway) and MUST set padding bits to 0 (which RFC 4648 says
applications MAY require).
These requirements mean that the resultant base64 from
Peter Saint-Andre wrote:
Ian Paterson wrote:
- In section 1.2 "How it Works":
1. If Benvolio is publishing caps with a different 'node' but the same
'ver' then I don't need to perform another disco#info. So can you make
that clear from the very outset
Peter Saint-Andre wrote:
I've made a first pass at updating XEP-0115 (Entity Capabilities) in
line with recent list discussion:
This looks like a good first pass.
- In section 1.2 "How it Works":
1. If Benvolio is publishing caps with a different 'node' but the same
'ver' then I don't nee
Peter Saint-Andre wrote:
We already have one such solution/hack in PEP: the +notify
namespaces used in entity capabilities to signal that a subscriber wants
to receive notifications related to a given namespace. Your suggestion
of +whitelist (etc.) is in the same spirit, but +notify does not forc
Ian Paterson wrote:
Wow! consensus on Personal Publishing! I'm off to celebrate :-) :-)
Well, so far only a consensus of 3 people who disagreed in the past.
- Ian
Peter Saint-Andre wrote:
So we'd have something like this:
My nurse's birthday!
http://jabber.org/protocol/pubsub#node_config
whitelist
Peter Saint-Andre wrote:
Whenever a client publishes the first item to a node that ends in
"+[accessmodel]", the pubsub service MUST create the node with a default
access model equal to the specified model (that is "open" or "presence"
or "roster" or "authorize" or "whitelist"). [1] For such a no
Peter Saint-Andre wrote:
Whenever a client publishes the first item to a node that ends in
"+[accessmodel]", the pubsub service MUST create the node with a default
access model equal to the specified model (that is "open" or "presence"
or "roster" or "authorize" or "whitelist"). [1] For such a no
Hi Dave :-)
Dave Cridland wrote:
The scenario you mentioned above becomes significantly more difficult
with ext in play, especially if predefined sets are the norm.
'ext' and pre-defined sets only improve security if the choice of a
"weak" hash makes pre-image attacks "possible". So why don't
Mridul wrote:
So queries for both bare jid and ns#ver will be supported (and return
the same value) ? And all clients using newer spec would use bare jid I
suppose ? (so that we can deprecate ns#ver and remove this in the future)
Yes.
But we do lose ability to enable/disable plugins withou
Dave Cridland wrote:
The hard part remains the timing issue - in order to have any value,
you'd need to pollute the target clients capability cache prior to it
discovering the real capabilities, and that's an extraordinarily short
time window.
It's not short if the attacker discovers the hash
Mridul Muralidharan wrote:
Joe Hildebrand wrote:
Changing the meaning of node breaks backwards compatibility, whereas
nothing else in the current proposal does. If there's no good reason
to break backward compatibility, I suggest that we avoid it.
I am not sure what was decided as the final
Justin Karneges wrote:
Apologies for not understanding this thread at all and just commenting out of
nowhere, but what security is gained by using a hash in the caps protocol?
If there is no security gained by using a hash (e.g. everyone has access to
the raw data such that they can all calcul
sufficient storage to cache the hash for each combination of
plugins also have insufficient storage to cache hashes for each separate
extension (i.e. they can't use caps at all).
Joe Hildebrand wrote:
On Jul 3, 2007, at 6:48 AM, Ian Paterson wrote:
Rachel Blackman wrote:
Let&#
Rachel Blackman wrote:
Let's say we have node='http://ceruleanstudios.com/astra/caps' and
ver='h$someverylongstring' and ext='h$otherverylongstring'
Or how about simply:
node='$' ver='base64encodedHashOfFeatures'
The benefits being it is more compact, and since all modern clients will
adverti
Rachel Blackman wrote:
I admit I still do not quite see why we should not just use the
namespace in place of 'jingle-audio,' as far as this goes. Yeah, okay,
it's a little longer, but on the other hand it has all the information
we need. If you support that namespace, you know that namespace,
Quoting XEP-0219:
> As a user, I may want to know three things:
> 1. If my connection to my server is encrypted.
> 2. If my server's connection to my contact's server is encrypted.
> 3. If my contact's connection to their server is encrypted.
I'd add a fourth item:
4. If my server's encrypted con
Peter Saint-Andre wrote:
CON
The RFCs are more stable. The bis drafts are officially works in
progress and therefore are subject to change. Developers hate coding
to a spec that is a moving target (on the other hand, they hate coding
to a spec that will soon be obsolete, too).
Yes, although
Fabio Forno wrote:
Example 2 in xep 206 shows the initial feature offers of the stream.
I'm wondering if it's correct to show also and
features, since before authentication they aren't available yet.
Thanks, I've removed them in the CVS copy.
- Ian
SASL External Auth (as specified in XEP-0178) relies on the TLS layer to
verify X.509 certificates. However, clients connecting using BOSH
(XEP-0124) don't use TLS encryption, they use https:// instead (i.e.,
they do not present a certificate before SASL). I think it might
therefore be useful t
39 matches
Mail list logo
