--- On Mon, 13/4/09, Peter Saint-Andre wrote:
> From: Peter Saint-Andre
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards"
> Date: Monday, 13 April, 2009, 12:45 AM
> On 4/10/09 8:36 PM, Mridul
> Muralidharan wrote:
> >
&
--- On Sat, 11/4/09, Peter Saint-Andre wrote:
> From: Peter Saint-Andre
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards"
> Date: Saturday, 11 April, 2009, 4:04 AM
> On 4/1/09 12:07 PM, Mridul
> Muralidharan wrote:
> >
&
far as I can make out.
Regards,
Mridul
--- On Thu, 9/4/09, Robin Redeker wrote:
> From: Robin Redeker
> Subject: Re: [Standards] unavailable presence from bare JID
> To: standards@xmpp.org
> Date: Thursday, 9 April, 2009, 10:42 PM
> On Thu, Apr 09, 2009 at 10:01:09PM
--- On Thu, 9/4/09, Justin Karneges
wrote:
> From: Justin Karneges
> Subject: Re: [Standards] unavailable presence from bare JID
> To: "XMPP Standards"
> Date: Thursday, 9 April, 2009, 8:30 PM
> On Thursday 09 April 2009 04:16:32
> Mridul Muralidharan wrote:
&g
--- On Thu, 9/4/09, Justin Karneges
wrote:
> From: Justin Karneges
> Subject: Re: [Standards] unavailable presence from bare JID
> To: "XMPP Standards"
> Date: Thursday, 9 April, 2009, 3:41 AM
> On Wednesday 08 April 2009 14:30:14
> Mridul Muralidharan wrot
e where an unavailable (and not available) can get sent is a
response to probe - and that is interpreted as no resource available for the
barejid.
Regards,
Mridul
--- On Wed, 8/4/09, Justin Karneges
wrote:
> From: Justin Karneges
> Subject: Re: [Standards] unavailable presence from bare
he moment you start considering privacy lists, the
> entire thing breaks, because evaluation of those needs
> handling at both ends, so a reverse roster lookup fails.
> Instead, what's needed is list building, which means
> evaluating the privacy list locally n times, in order to
&g
If I recall right, probe can be sent to a full jid in case a directed presence
was received from it in the past - and the behavior would be different (return
last presence stanza sent iirc).
Has that behavior changed or is the description below only for bare jid's ?
Regards,
Mridul
-
sence
broadcasts, the 'source of truth' for a contact's roster must always be the
hosting server - and not remote servers : else any distributed system breaks
down over time.
Regards,
Mridul
--- On Wed, 1/4/09, Pedro Melo wrote:
> From: Pedro Melo
> Subject: Re: [Standa
Server processes stanza's in order - so both should are valid.
- Mridul
Pedro Melo wrote:
HI,
reading through 3921, I have a question regarding section 3.1.1, Client
Generation of Outbound Subscription Request.
In the last paragraph its mentioned that before sending the subscri
Particularly flow control, if nothing else.
- Mridul
Joe Hildebrand wrote:
I think it would be cool to reuse the work from BEEP (RFC 3080) for this
sort of thing, if possible.
On Sep 25, 2007, at 10:32 AM, Peter Saint-Andre wrote:
The XMPP Extensions Editor (c'est moi) has recei
ough spi's) or
existing out of the box ones disabled based on the deployment
configuration - and it is essential that we give admin the freedom to
customize it the way he wants.
Btw, we did have some confusion regarding mandatory to implement vs
deploy, but devcon 2006 cleared it up for us :)
- Mridul
- Ian
os KDC, of course, but I
don't hold out much hope for that being universally implemented in
clients.)
Yes, I mentioned the same a few posts back - auth proxying can be done
across a variety of mechisms/deployments only with sasl plain (and the
deprecated jabber:iq:auth) in xmpp.
- Mridul
ce.
If end to end there is tls (from the client to the server), then there
is not much difference between both.
(assuming something stupid is not done at the server)
DIGEST-MD5 on the other hand has a lot of other problems - proxy auth is
something which has bit us quite a lot.
Mridul
2. Add
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Isn't this spec, for example, just special casing presence-out:deny ?
"
"
Yes it is. Bu
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Isn't this spec, for example, just special casing presence-out:deny ?
"
"
Yes it is. But then you need access to a server and client that suppor
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
XMPP Extensions Editor wrote:
Version 0.6 of XEP-0186 (Invisible Command) has been released.
Abstract: This document specifies an XMPP-compatible protocol for user
invisibility.
Changelog: Clarified that this specification is intended to
better designed if that is a
concern ?) - having both together means neither server, not client can
rely on support of these (unless they implement all).
- Mridul
Peter Saint-Andre wrote:
Mridul wrote:
Curtis King wrote:
On Aug 29, 2007, at 6:20 PM, Mridul Muralidharan wrote:
3921.Section 5.1.1 - "In addition, the user's server MUST broadcast
initial presence from the user's new available resource to any of the
user's existing ava
Curtis King wrote:
>
> On Aug 29, 2007, at 6:20 PM, Mridul Muralidharan wrote:
>
>>
>> 3921.Section 5.1.1 - "In addition, the user's server MUST broadcast
>> initial presence from the user's new available resource to any of the
>> user's ex
Mridul Muralidharan wrote:
Rachel Blackman wrote:
I don't think it's a modification, just a clarification.
As Rachel Blackman mentioned, this is a change of behavior between the
rfc's, and any client depending on this behavior will not be able to
work properly with existing s
ot receive self-presence).
It looks pretty well defined in 3921 !
Maybe the language might be clarified better - but the flow is pretty
clearly spelled out.
- Mridul
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
But (2) seems OK. When you send presence to your server, your server
delivers that presence to all of your available resources. Consider a
user with two resources
are no available resources -
should we not just have a reference to AMP spec and leave it at that ?
How it gets handled might be impl detail, or based on AMP.
- Mridul
***
Peter
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
The old "xmppbis" page [1] had the following note:
***
It is unnecessary, potentially confusing, and not recommended to add
your own JID to your roster. However, RFC 3921 currently does not talk
about ho
ng
that. Would it confuse the client?
/psa
bis compliant clients will 'expect' this behavior - and so will break
when they talk to older servers (assuming they do something with this
presence status).
Reverse might also be the case - of existing clients breaking when they
get prese
nsions to supporting binary content inband in xml,
the point is about interoperability & adoption - not whether it can or
cant be done.
A few specs have pulled this off like wbxml, etc ... and have wider
adoption & implementation. I would really not quote DIME, etc in this
context.
resource, the server or an intermediary -
while the pong would come from the actual destination.
- Mridul
Jonathan Dickinson wrote:
Hey All,
XEP-0199 defines that if a server or client does not support ping it
should return the following stanza:
type='error'>
dont see the need for the multicast behavior when this can be handled
appropriately.
Regards,
Mridul
cJ wrote:
> Hi, I am wondering why the RFC (3921, 11.1) specifies "If two or more
> available resources have the same priority, the server MAY use some other
> rule (e.g., most
Peter Saint-Andre wrote:
Hi Mridul!
Mridul Muralidharan wrote:
Hi,
A lot of these specs have seen quite radical change recently in
comparison to the 'lifetime' of the spec.
If we don't try to push some of these forward, we never will. :)
+ 1 !
Naturally we won't
ve been fairly stable and have multiple interoperable
implementations .. seem like good candidates for becoming final.
Regards,
Mridul
Peter Saint-Andre wrote:
I think that we need to push more specs from Draft to Final. This will
require multiple implementations and some interop testing (preferably
already,
and so the issues you observed.
Regards,
Mridul
Mats Bengtsson wrote:
> FYI:
> Since there is (was) conflicting recommendations in XEP-0170,
> Recommended Order of Stream Feature Negotiation,
> (SASL -> compression)
> and XEP-0138, Stream Compression, (compression ->
ger valid/exists.
So from what I see, this should not be a problem.
Or am I missing something here ?
- Mridul
Possible fixes that came to my mind:
* Define this to be a special case and demand to send an HTTP error
condition. Breaks with concept of separating error conditions at the
protocol lev
have responses to the rest inline.
Thanks,
Mridul
Peter Saint-Andre wrote:
As promised, here are some questions and comments on the proposed MUC
message moderation specs:
http://www.xmpp.org/extensions/inbox/msg_moderate.html
http://www.xmpp.org/extensions/inbox/room_moderator.html
1. I thi
sa
This will not work in case the conference component or room is not
'online' at that time.
Regards,
Mridul
with IM-XHTML itself ?
Regards,
Mridul
Robin Redeker wrote:
On Sun, Aug 05, 2007 at 05:10:13AM +0530, Mridul Muralidharan wrote:
Robin Redeker wrote:
On Fri, Aug 03, 2007 at 04:29:15AM +0530, Mridul Muralidharan wrote:
Just mentioning a basic problem which was discussed at jdev.
If two 1.0 server move to 1.1, all the 'older
Robin Redeker wrote:
On Fri, Aug 03, 2007 at 04:29:15AM +0530, Mridul Muralidharan wrote:
Just mentioning a basic problem which was discussed at jdev.
If two 1.0 server move to 1.1, all the 'older' 1.0 jid's will become
unroutable - which are present in user roster/affiliatio
Just mentioning a basic problem which was discussed at jdev.
If two 1.0 server move to 1.1, all the 'older' 1.0 jid's will become
unroutable - which are present in user roster/affiliations/privacylists/etc.
Regards,
Mridul
Robin Redeker wrote:
(Warning, long mail ahead! G
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Component Connections
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to
Hi Peter,
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
4. One solution would be to define version 2 of nodeprep in rfc3920bis.
As far as I can see, nodeprep2 would allow " & ' < > since those can be
escaped in XML (e.g., XMPP 'to&#x
PROTECTED] and domain/[EMAIL PROTECTED] cant be differentiated if / is
allowed.
Btw, changing nodeprep now will cause quite a lot of problem with
existing deployments - since the contact jid's are part of the user data
- and would pretty much mean we cant adopt bis spec.
The number of deploy
for example,
so you can never translate full names to usernames in either addressing
scheme.
Do we really need to have these extra characters?
Yes, we do.
I have mentioned quite a lot of instances where this is required.
- Mridul
lls under IM.
You can have chat state along with a body/xhtml - I thought the proposal
said you cant have more than one element from a profile within a message ?
- Mridul
If a client receives a message stanza with no profile (this can occur if the
stanza is actually empty, or contains o
rt of registrar in some way ?
Mridul
very useful proposal.
Mridul
[1] http://www.xmpp.org/extensions/inbox/dix.html
Hi,
Not sure where the confusion was ... I always assumed that support for
CDATA was a given since it is just another xml construct.
Regards,
Mridul
Mickaël Rémond wrote:
> Hello,
>
> Le 30 juil. 07 à 21:35, Peter Saint-Andre a écrit :
>
>> Sergei Golovan wrote:
>>
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
For the server, this xep is required since its user population could
include users which have these prohibited characters in the uid .. and
so requires it to
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
For the server, this xep is required since its user population could
include users which have these prohibited characters in the uid .. and
so requires it to identify the backend user
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
IMO, (un)escaping should only be done by the entities which need to do
so - we should not mix a routing construct with display.
Sure. We never mess with the routing. From the client perspective,
XEP-0106 is only for display purposes.
From
, it does not matter - the rest of the system does not
depend on how the gateway encodes or decodes - ofcourse it helps to
standardize so that implementations dont end up with illegal nodes.
Regards,
Mridul
to give a hint of the identity would be wrong.
Mridul
nly over the inbound socket - after
the session has been established. That is, you could have stanza's
exchanged both ways over an s2s stream before session establishment is
complete.
Regards,
Mridul
Thanks, Toly
Greg Hudson wrote:
On Wed, 2007-07-25 at 10:02 +0530, Mridul Muralidharan wrote:
As long as we have prohibited characters - and '@' is always going to be
there in node part, we will need escaping :-)
There's an underlying assumption here that JID nodes must be able to
co
Robin Redeker wrote:
> On Wed, Jul 25, 2007 at 03:22:04AM +0530, Mridul Muralidharan wrote:
>> Hi Robin,
>>
>> You should analyze as to who will actually need to encode or decode nodes.
>
>> 1) Gateway's.
>
> I know that JID escaping is for gateways,
to be
there in node part, we will need escaping :-)
Mridul
ated to and required for
xmpp routing.
Hopefully, from this point of view, the xep might make more sense.
More inline ...
Robin Redeker wrote:
On Tue, Jul 24, 2007 at 10:10:45PM +0530, Mridul Muralidharan wrote:
Robin Redeker wrote:
On Sat, Jul 21, 2007 at 08:17:19PM -0600, Peter Saint-Andre wr
7; are replaced by
'mapping' and 'unmapping', because thats what is happening here.
Not really very specialized clients - even common clients will need it.
Example, if uid's used in the server are mailid's for example.
Then the client will need to escape the node for the bind.
- Mridul
Robin
bare response (from="[EMAIL PROTECTED]" id="reqid" type="result" />). I have seen libraries
assuming recommended behavior as though it was MUST and not handling
these cases.
Mridul
?
I don't know if the spec needs to talk about this, but it couldn't hurt
(since it's different for c2s vs. s2s).
/psa
What is this 'stream header' you are refering to here ?
The actual stanzas to be routed ? then yes - anything else, then no.
- Mridul
nfo?
Thank you,
William
Hi,
You could encode the sequence number into the 'id' attribute ?
Regards,
Mridul
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
I understand handling of fields that are preconditions, it's what we
outlined before:
1. If the node exists and the precondition is not met (in this case, if
the access model is something other than "
to the implementation or deployment whether it
supports any of these field types.
A means to specify, dont publish if precondition is not met - a means to
use it as config assertion.
Regards,
Mridul
Thoughts?
/psa
econditions are great way to assert access level for
clients/nodes which require strict acl's.
Regards,
Mridul
PS : Hope this is not going back to the same path's earlier, just wanted
to get it clarified.
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Now, a 'from' address of the full JID seems odd to me. What if I
send an
IQ-set from one of my resources to another? Does that mean I can do
roster pushes directly from one r
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Now, a 'from' address of the full JID seems odd to me. What if I send an
IQ-set from one of my resources to another? Does that mean I can do
roster pushes directly from one resource to another without updating the
roster on the se
server can't perform the usual
swapping of 'from' and 'to' addresses anyway, so it seems easier to not
include the 'from' address.
In our case, server handles roster iq's, irrespective of destination
specified in stanza and will always be processed for the sender.
Regards,
Mridul
Peter
Ian Paterson wrote:
> 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 compatibilit
undocumented features.
Validation of caps data using hash is invaluable (esp for pep), but I am
not very happy about breaking compatibility with existing clients and
servers.
Regards,
Mridul
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul wrote:
Joe Hildebrand wrote:
On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Forgot to add, change name from ver & ext to verh and exth ?
Why?
Conflict with exis
Peter Saint-Andre wrote:
Mridul wrote:
Joe Hildebrand wrote:
On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Forgot to add, change name from ver & ext to verh and exth ?
Why?
Conflict with existing clients - too many of the
Joe Hildebrand wrote:
>
> On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:
>
>> Peter Saint-Andre wrote:
>>> Mridul Muralidharan wrote:
>>>> Forgot to add, change name from ver & ext to verh and exth ?
>>> Why?
>>
>> Conflict
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Forgot to add, change name from ver & ext to verh and exth ?
Why?
Conflict with existing clients - too many of them in the wild dont use
these semantics.
But introducing
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Forgot to add, change name from ver & ext to verh and exth ?
Why?
Conflict with existing clients - too many of them in the wild dont use
these semantics.
Mridul
Mridul Muralidharan wrote:
Joe Hildebrand wrote:
On Jun 27, 2007, at 2:32 AM, Jacek Konieczny wrote:
That is not true. Years ago I have proposed other solution: instead of
announcing client name version and caps clients should announce digest
(e.g. MD5 or SHA) of normalized set of supported
else we do will be at least this bad if not worse.
yes
If we add these bits to -115, will everyone agree to never bring up
changing caps again, and to all agree on that the next time a n00b comes
around?
heh
--Joe Hildebrand
Regards,
Mridul
this, then rest is just an implementation detail imo with
a recommendation to clients/servers to support atleast so many characters.
Regards,
Mridul
Peter Saint-Andre wrote:
Matthias Wimmer wrote:
Hi Michal!
Michal 'vorner' Vaner schrieb:
What is the problem with saying the server c
this, but those are
implementation details - something standard will give both clients and
servers a upper limit confidence.
Regards,
Mridul
PS: Strange, I was discussing about this with some others just a couple
of weeks back :)
Joe Hildebrand wrote:
On Jun 21, 2007, at 2:33 PM, Mridul Muralidharan wrote:
Joe Hildebrand wrote:
A body inside the namespace for the particular PEP node is perfectly
fine, if it makes sense for that namespace. If a client doesn't know
about that namespace, it's not going
Joe Hildebrand wrote:
On Jun 14, 2007, at 8:45 PM, Mridul Muralidharan wrote:
You are right, application payloads getting sent (as messages) should,
imo, not contain unless it expects to communicate that to the
user.
In a lot of cases for pep typically, it would be consumed by the
client
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Matthias Wimmer wrote:
Hi Peter!
Peter Saint-Andre schrieb:
1. Dialback itself is not mandatory to implement, so a change to
dialback would not affect the XMPP versioning.
Well ... I think it would be okay to
lexity is not a good thing to have
in a spec - and dialback already allows various weird combinations
possible in a cluster.
Mridul
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Matthias Wimmer wrote:
Hi Peter!
Peter Saint-Andre schrieb:
1. Dialback itself is not mandatory to implement, so a change to
dialback would not affect the XMPP versioning.
Well ... I think it would be okay to just remove dialback without
'xmpp 1.0', and combinations seems to have issues across servers.
Btw, are we not moving to using the stream feature instead of the db
namespace in the stream to advertise dialback ?
In which case, we could just deprecate both use of the namespace, and
support for dialback.
Rega
ally, this is great !
Thanks :)
- Mridul
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Justin Karneges wrote:
On Thursday 14 June 2007 2:59 pm, Peter Saint-Andre wrote:
Would it be appropriate to recommend that client and server developers
bundle support for the root certificate under which the XMPP ICA issues
domain
ttempts it.
Dialback is already complex enough with the edgecases, tls, pre-1.0 and
what not without adding more to it.
Mridul
pen internet.
That said, I think making a recommendation like this is mostly redundant.
Yes, if it is trusted, most keystores will already include it as a ca by
default.
Mridul
-Justin
to show the plain text info to user.
That being said, we should not preclude addition of body, it might make
sense for usecases (maybe where pep is more used like pubsub with
infrequent updates ?)
Mridul
This makes a lot of sense.
This is how we tend to use the bis specs right now.
Regards,
Mridul
Joe Hildebrand wrote:
As much as I expect that the bis drafts are better, they haven't had
cross-area review.
I'd recommend 3920 and 3921, with a reference to the bis drafts for
cla
Loved the last line in the logs ... almost cinematic :-)
Mridul
Peter Saint-Andre wrote:
FYI.
Original Message
Date: Wed, 13 Jun 2007 11:51:35 -0600
From: Peter Saint-Andre <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Council] meeting minutes, 2007-06-13
Resu
XMPP Registrar wrote:
The Alternative XMPP Connection Methods registry has been created.
Version: 0.1
Changelog: Initial version (populated from XEP-0156, version 1.0). (psa)
URL: http://www.xmpp.org/registrar/altconn.html
404 ?
Mridul
ication, how they sync up
config/current room state, etc - that would be quite interesting problem
to solve (apart from the other issues already mentioned here).
Regards,
Mridul
I hope that we are not trying to clone IRC's behavior just for the sake of
saying we can.
-Justin
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Lauri Kaila wrote:
2007/6/5, Peter Saint-Andre <[EMAIL PROTECTED]>:
Lauri Kaila wrote:
> I was trying to sort out Jingle initiation when someone has many
> clients (resources) online. XEP-0168 (RAP) is
currently for alerts, notifications, etc by
our bots.
Mridul
95 matches
Mail list logo
