From mridulm80 at yahoo.com  Wed Apr  1 01:11:27 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Wed, 1 Apr 2009 11:41:27 +0530 (IST)
Subject: [Standards] Presence distribution
Message-ID: <323344.23395.qm@web95404.mail.in2.yahoo.com>



I remember proposing use of ad-hoc distribution lists for this purpose about three years back (though it was not limited to presence). Rejoining last week, I see that the discussions continue to be the same :-)

While number of stanza's in S2S connections are usually dominated by presence 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 <melo at simplicidade.org> wrote:

> From: Pedro Melo <melo at simplicidade.org>
> Subject: Re: [Standards] Presence distribution
> To: "XMPP Standards" <standards at xmpp.org>
> Date: Wednesday, 1 April, 2009, 12:03 AM
> 
> On Mar 31, 2009, at 5:36 PM, Dave Cridland wrote:
> 
> > On Tue Mar 31 16:00:20 2009, Pedro Melo wrote:
> >> 1) as much as you have right now: remote servers
> can do whatever they? want with your presence, you have
> no control after they leave your own? server (a
> pessimist would even say that you don't have any
> control? after they leave your client);
> > Well, there's trust, and responsibility. If a contact
> has an outright evil server, there's little you can do -
> similarly if your own server, or even client, is subverted.
> For things like this, it's really game over. We generally
> choose to model a trusted client and a trusted server,
> although we assume an untrusted server for content in the
> case of e2e encryption.
> > 
> > But then there's responsibility - right now, it's
> inarguably your local server which enforces who gets your
> presence, and a reverse-roster lookup causes immediate
> problems there - if people don't get to see your presence
> (or worse, do when they shouldn't), you've then got two
> places to debug instead of one.
> 
> Yes, agreed. The multi-cast solution would change the
> responsibility axis of the problem, not the security axis.
> 
> 
> >> 2) if subscription state gets out of sync, the
> protocol will behave? better or worse than the current
> version :), it really depends which? roster is correct.
> There was a thread 2 or 3 weeks back with a? tentative
> solution to keep subscription state in sync using the?
> initial <presence type="probe" />.
> > I'm not sure your initial analysis is correct, and
> it's related to the above comments I make - if rosters are
> out of sync now, while it's tricky to discover, you know
> where the blame lies instantly in each case.
> > 
> > And a rough analysis suggests that in the current
> situation, you'll either get presence when you *no longer*
> wanted it, or else you won't get presence when you want it.
> With a reverse roster lookup, it's possible to end up in a
> situation where you'll get presence when the sender doesn't
> want you to, which is substantially worse, and without any
> bad actor involved. (I could be wrong here, please check
> this.)
> 
> if I accept your subscription (my server will move to
> 'both' or 'to') but if that <presence
> type="subscribed"> does not reach you (you keep 'none' or
> 'to') then the remote fan-out is less revealing. I guess I
> could also argue from your side and say that in that case I
> already gave you permission to see so in principle I'm
> disclosing as much as I wanted.
> 
> I do believe that out-of-sync rosters is a separate
> problem, and it could be solved with a handshake between
> servers at presence-probe time, but maybe thats the topic of
> another thread.
> 
> 
> >> But let me clarify something: although the
> bandwidth and processing? savings of a multi-cast
> approach to presence distribution should be? relevant,
> I don't believe this is compatible with a lot of other?
> protocols that we have, so although I think multi-cast
> presence is a? worthy long-term goal, I don't think we
> are ready to address it at? this moment.
> > 
> > I'm not even convinced of this.
> > 
> > We have this famous thing about ~87% (the figure
> varies) of traffic being presence, and I'm afraid I think
> these figures skew vastly the moment compression takes
> effect, since, by the very nature of the data we're sending,
> it compresses really well. In fact, I'm not sure that it's
> even worth worrying about as a problem, given how well this
> should compress.
> 
> My main concern is actually not bandwidth but processing
> cost. One stanza, one access and sequential fetch to a index
> seems to be more efficient that processing several stanzas.
> 
> 
> > I basically refuse to consider any solution seriously
> unless you're measuring the effects of it post-compression -
> and I agree that's hard.
> 
> Sure, and given that I actually think of this as an
> optimization for overall processing cost, then it will be
> even more difficult to prove.
> 
> I guess I need to hack on some server to prove this
> hypothesis.
> 
> Best regards,
> 


      Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/


From editor at xmpp.org  Wed Apr  1 07:04:12 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 01 Apr 2009 07:04:12 -0500
Subject: [Standards] ACTIVE: XEP-0263 (ECO-XMPP)
Message-ID: <E1LozAy-00033K-00@apollo>

Version 1.0 of XEP-0263 (ECO-XMPP) has been released.

Abstract: This specification defines best practices and protocol modifications that will reduce the energy consumption of XMPP systems and thereby help to save the planet.

Changelog: April Fools! (psa/ff)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0263.html


From jajcus at jajcus.net  Wed Apr  1 07:53:38 2009
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 1 Apr 2009 14:53:38 +0200
Subject: [Standards] ACTIVE: XEP-0263 (ECO-XMPP)
In-Reply-To: <E1LozAy-00033K-00@apollo>
References: <E1LozAy-00033K-00@apollo>
Message-ID: <20090401125337.GG22464@jajo.eggsoft>

On Wed, Apr 01, 2009 at 07:04:12AM -0500, XMPP Extensions Editor wrote:
> Version 1.0 of XEP-0263 (ECO-XMPP) has been released.
> 
> Abstract: This specification defines best practices and protocol
> modifications that will reduce the energy consumption of XMPP systems
> and thereby help to save the planet.

Great document! I am sure European Union will be happy to refund
implementations here in Europe. I am sure someone would really be able
to get some funds for this. :)

Greets,
        Jacek

From fabio.forno at gmail.com  Wed Apr  1 08:36:12 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Wed, 1 Apr 2009 15:36:12 +0200
Subject: [Standards] ACTIVE: XEP-0263 (ECO-XMPP)
In-Reply-To: <20090401125337.GG22464@jajo.eggsoft>
References: <E1LozAy-00033K-00@apollo> <20090401125337.GG22464@jajo.eggsoft>
Message-ID: <2fd53c3a0904010636w51a1eecfs73c4ccfbdfe3469d@mail.gmail.com>

On Wed, Apr 1, 2009 at 2:53 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> On Wed, Apr 01, 2009 at 07:04:12AM -0500, XMPP Extensions Editor wrote:
>> Version 1.0 of XEP-0263 (ECO-XMPP) has been released.
>>
>> Abstract: This specification defines best practices and protocol
>> modifications that will reduce the energy consumption of XMPP systems
>> and thereby help to save the planet.
>
> Great document! I am sure European Union will be happy to refund
> implementations here in Europe. I am sure someone would really be able
> to get some funds for this. :)

We could get some sponsorships for initiatives like the JID give up
Day, in which users unregister from servers and uninstall their
favorite client ;)


-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From dmeyer at tzi.de  Wed Apr  1 08:43:09 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Wed, 01 Apr 2009 15:43:09 +0200
Subject: [Standards] ACTIVE: XEP-0263 (ECO-XMPP)
In-Reply-To: <20090401125337.GG22464@jajo.eggsoft> (Jacek Konieczny's message
	of "Wed\, 1 Apr 2009 14\:53\:38 +0200")
References: <E1LozAy-00033K-00@apollo> <20090401125337.GG22464@jajo.eggsoft>
Message-ID: <873acsqyky.fsf@phex.sachmittel.de>

Jacek Konieczny wrote:
> On Wed, Apr 01, 2009 at 07:04:12AM -0500, XMPP Extensions Editor wrote:
>> Version 1.0 of XEP-0263 (ECO-XMPP) has been released.
>> 
>> Abstract: This specification defines best practices and protocol
>> modifications that will reduce the energy consumption of XMPP systems
>> and thereby help to save the planet.
>
> Great document! I am sure European Union will be happy to refund
> implementations here in Europe. I am sure someone would really be able
> to get some funds for this. :)

The sad thing is: I really believe some people would be able to get
funding for this from the EU.


Dirk

-- 
"I don't read books, but I have friends who do." -Presidential
Candidate George W. Bush

From luca.tagliaferri at gmail.com  Wed Apr  1 08:56:04 2009
From: luca.tagliaferri at gmail.com (luca)
Date: Wed, 01 Apr 2009 15:56:04 +0200
Subject: [Standards] ACTIVE: XEP-0263 (ECO-XMPP)
In-Reply-To: <873acsqyky.fsf@phex.sachmittel.de>
References: <E1LozAy-00033K-00@apollo> <20090401125337.GG22464@jajo.eggsoft>
	<873acsqyky.fsf@phex.sachmittel.de>
Message-ID: <49D37274.4020404@gmail.com>



Dirk Meyer ha scritto:
> Jacek Konieczny wrote:
>   
>> On Wed, Apr 01, 2009 at 07:04:12AM -0500, XMPP Extensions Editor wrote:
>>     
>>> Version 1.0 of XEP-0263 (ECO-XMPP) has been released.
>>>
>>> Abstract: This specification defines best practices and protocol
>>> modifications that will reduce the energy consumption of XMPP systems
>>> and thereby help to save the planet.
>>>       
>> Great document! I am sure European Union will be happy to refund
>> implementations here in Europe. I am sure someone would really be able
>> to get some funds for this. :)
>>     
>
> The sad thing is: I really believe some people would be able to get
> funding for this from the EU.
>
>
> Dirk
>
>   

+1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090401/92944e31/attachment.htm 

From js-xmpp-standards at webkeks.org  Wed Apr  1 09:02:45 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Wed, 1 Apr 2009 16:02:45 +0200
Subject: [Standards] Question about XEP-0241
Message-ID: <9DF620F0-109C-4661-BC4F-BFF9271A266F@webkeks.org>

Hi!

I've got a question regarding XEP-0241. I have to admit that I haven't  
completely read it yet, but what I'm wondering is:
If I understand it right, auto-archiving has to be enabled for every  
session manually, even though it's encrypted. Wouldn't it be feasible  
to make this a permanent option, so that if you turn it on, it's on  
for every current and future session, as it's encrypted anyway? That  
would make it possible to also use it with clients that don't support  
server side history. For example, I could implement XEP-0241 in Gajim  
and use JWChat when I'm somewhere else. When I return home, I have can  
see the history in Gajim.

--
Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 801 bytes
Desc: Signierter Teil der Nachricht
Url : http://mail.jabber.org/pipermail/standards/attachments/20090401/d8de8c48/attachment.pgp 

From stpeter at stpeter.im  Wed Apr  1 09:41:58 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 01 Apr 2009 08:41:58 -0600
Subject: [Standards] Proposed XMPP Extension: File Transfer Thumbnails
In-Reply-To: <e962983d0903311530q431418c7w466414b11caa7b14@mail.gmail.com>
References: <E1LoMOr-0005YI-00@apollo>	<C24461F4-0447-455D-A4DA-CAFD2CCD8446@webkeks.org>	<49D21E94.505@stpeter.im>	<09EEE7E6-C983-4800-99E6-CCE2C2BA4522@webkeks.org>
	<e962983d0903311530q431418c7w466414b11caa7b14@mail.gmail.com>
Message-ID: <49D37D36.2010609@stpeter.im>

On 3/31/09 4:30 PM, Ji?? Z?rev?ck? wrote:
> 2009/3/31 Jonathan Schleifer <js-xmpp-standards at webkeks.org>:
>> Am 31.03.2009 um 15:45 schrieb Peter Saint-Andre:
>>
>>> Typically our protocol documents don't specify user interface details
>>> like that.
>> Hm, ok. But sometimes, it would make sense if a particular feature is
>> presented the same way to the user in every client. This looks more
>> consistent for the user if two users are using different clients.
>>
> 
> It makes sense for some features, but I don't think it's important for
> file thumbnails. It can be displayed in a chat window, or it can be
> part of a confirmation dialog. There is no difference in
> functionality. One is just convenient for some people (but can be
> annoying for others). IMHO the whole point of having different clients
> is to have different ways of doing things such as this, that suit
> different people.

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090401/9c633d54/attachment.bin 

From stpeter at stpeter.im  Wed Apr  1 09:50:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 01 Apr 2009 08:50:55 -0600
Subject: [Standards] Presence distribution
In-Reply-To: <003765A8-ACED-47B7-8146-689CBC72A828@simplicidade.org>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>	<49D21F25.8050009@stpeter.im>	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>	<13438.1238517419.538659@puncture>
	<003765A8-ACED-47B7-8146-689CBC72A828@simplicidade.org>
Message-ID: <49D37F4F.6080400@stpeter.im>

On 3/31/09 12:33 PM, Pedro Melo wrote:
> 
> On Mar 31, 2009, at 5:36 PM, Dave Cridland wrote:
> 
>> On Tue Mar 31 16:00:20 2009, Pedro Melo wrote:
>>
>>> 2) if subscription state gets out of sync, the protocol will behave 
>>> better or worse than the current version :), it really depends which 
>>> roster is correct. There was a thread 2 or 3 weeks back with a 
>>> tentative solution to keep subscription state in sync using the 
>>> initial <presence type="probe" />.
>> I'm not sure your initial analysis is correct, and it's related to the
>> above comments I make - if rosters are out of sync now, while it's
>> tricky to discover, you know where the blame lies instantly in each case.
>>
>> And a rough analysis suggests that in the current situation, you'll
>> either get presence when you *no longer* wanted it, or else you won't
>> get presence when you want it. With a reverse roster lookup, it's
>> possible to end up in a situation where you'll get presence when the
>> sender doesn't want you to, which is substantially worse, and without
>> any bad actor involved. (I could be wrong here, please check this.)
> 
> if I accept your subscription (my server will move to 'both' or 'to')
> but if that <presence type="subscribed"> does not reach you (you keep
> 'none' or 'to') then the remote fan-out is less revealing. I guess I
> could also argue from your side and say that in that case I already gave
> you permission to see so in principle I'm disclosing as much as I wanted.
> 
> I do believe that out-of-sync rosters is a separate problem, and it
> could be solved with a handshake between servers at presence-probe time,
> but maybe thats the topic of another thread.

Yes, I'll read the thread about "inconsistent subscriptions" and post
there. In rfc3921bis I've tried to clarify the use of unsubscribe and
unsubscribed on this point, but perhaps it's not enough.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090401/77409849/attachment-0001.bin 

From stpeter at stpeter.im  Wed Apr  1 12:49:50 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 01 Apr 2009 11:49:50 -0600
Subject: [Standards] Inconsistent Subscriptions in XMPP
In-Reply-To: <6667E2FB-D766-4559-AA0B-83519FD605D0@simplicidade.org>
References: <20090224014950.0b613c9f@tiger>	<1B964E11-BAB2-4496-A77D-EE1F8B005B71@simplicidade.org>	<20090225203633.092729e8@tiger>	<0C29ED93-5BB8-4909-8902-EF218B794E96@simplicidade.org>	<7fc4fa880902280218w24b8ea20me320e6a46b4c9cc0@mail.gmail.com>
	<6667E2FB-D766-4559-AA0B-83519FD605D0@simplicidade.org>
Message-ID: <49D3A93E.8080302@stpeter.im>

On 3/5/09 5:37 AM, Pedro Melo wrote:
> Hi,
> 
> On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote:
>
>> What action is appropriate is open for debate. What should the
>> resulting state be? The lowest common permissions (possibly sending
>> unsubscribe[d] to the contact or changing the user's subscription for
>> contact)? The highest common permissions (possibly sending a
>> subscrive[d] to the contact and changing the user's subscription for
>> the contact)?
> 
> Highest common permissions, maybe. I've started a table below for some
> cases, 

Yes, roster stuff always results in big tables. :)

> and I have some doubts. Should we upgrade the Receiver
> subscription to a better state? For example: if you have a To
> subscription to me and I have a None to you, should I be upgraded to a
> From? Not sure yet. It can be used for presence spam. A more careful
> approach would send a unsubscribe.
> 
> And we need to look this in the other direction. If the Receiver is 'To'
> or 'Both' and the other side is 'None' or 'To', should we send a
> 'subscribed'? It makes sense for the Receiver, but from the POV of the
> Sender, you are modifying my own subscription status, upgrading it.

I prefer the terms "user" and "contact" to be consistent with RFC 3921.

> I wrote the following table of what I think are the most safe
> transactions: none of the subscriptions are "upgraded" in any way.

I've annotated it with comments and pseudo-XMPP. Now it's even more
verbose. :)

> (note: for each "Recv resets to 'X'" it is implied that a roster push
> would be sent to all connected resources)
> 
> Sender: none
> Recv: to
> 
>  => Recv resets to 'none'
> 
> 
> Sender: none
> Recv: from
> 
>  => Recv resets to 'none'
> 
> 
> Sender: none
> Recv: Both
> 
>  => Recv resets to 'none'

Why would the user's server send a probe to the contact if it thinks
that the subscription state is none? (Granted, the user's client could
generate a presence probe, but that's a different story.)

> Sender: To
> Recv: none
> 
>  => Recv sends 'unsubscribe'

So: user's server thinks that user is sub'd to contact. It sends [probe
state='both']. Contact's server thinks that user is not sub'd. Therefore
I think contact's server would send [presence unsubscribed], i.e., "I am
not going to send you contact's presence because you're not subscribed
to his presence".

> Sender: To
> Recv: To
> 
>  => Recv resets to 'none', sends 'unsubscribe'

As above, I think contact's server would send [presence unsubscribed].

> Sender: To
> Recv: Both
> 
>  => Recv resets to 'From'

I think this is OK. I assume that after the roster push (state=from),
the contact might send a new subscription request.

> Sender: From
> Recv: none
> 
>  => Recv sends 'unsubscribed'
> 
> 
> Sender: From
> Recv: From
> 
>  => Recv resets to 'none', sends 'unsubscribed'
> 
> 
> Sender: From
> Recv: Both
> 
>  => Recv resets to 'To'

As above for none, why would the user's server send a probe to the
contact if it thinks that the subscription state is from (i.e., the user
has a subscription from the contact but not to the contact)?

> Sender: Both
> Recv: none
> 
>  => Recv sends 'unsubscribe' and 'unsubscribed'

Right.

> Sender: From
> Recv: From
> 
>  => Recv resets to 'none', sends 'unsubscribed'

IMHO user's server would not probe in this case.

> Sender: From
> Recv: Both
> 
>  => Recv resets to 'To'

IMHO user's server would not probe in this case.

>> From an IM user's point of view, trying to settle on the highest
>> common permissions seems more appropriate (and less confusing).
> 
> Well, the fact that we have asymmetrical states is a source of some
> confusion. If you want to eliminate that, then you should have 'none'
> and 'both' only.
> 
> But asymmetrical presences are very useful on some IM scenarios, like
> transports.

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090401/c12fb0b1/attachment.bin 

From mridulm80 at yahoo.com  Wed Apr  1 13:07:59 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Wed, 1 Apr 2009 23:37:59 +0530 (IST)
Subject: [Standards] Inconsistent Subscriptions in XMPP
Message-ID: <333428.3869.qm@web95410.mail.in2.yahoo.com>



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

--- On Wed, 1/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> From: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards" <standards at xmpp..org>
> Date: Wednesday, 1 April, 2009, 11:19 PM
> On 3/5/09 5:37 AM, Pedro Melo wrote:
> > Hi,
> > 
> > On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote:
> >
> >> What action is appropriate is open for debate.
> What should the
> >> resulting state be? The lowest common permissions
> (possibly sending
> >> unsubscribe[d] to the contact or changing the
> user's subscription for
> >> contact)? The highest common permissions (possibly
> sending a
> >> subscrive[d] to the contact and changing the
> user's subscription for
> >> the contact)?
> > 
> > Highest common permissions, maybe. I've started a
> table below for some
> > cases, 
> 
> Yes, roster stuff always results in big tables. :)
> 
> > and I have some doubts. Should we upgrade the
> Receiver
> > subscription to a better state? For example: if you
> have a To
> > subscription to me and I have a None to you, should I
> be upgraded to a
> > From? Not sure yet. It can be used for presence spam.
> A more careful
> > approach would send a unsubscribe.
> > 
> > And we need to look this in the other direction. If
> the Receiver is 'To'
> > or 'Both' and the other side is 'None' or 'To', should
> we send a
> > 'subscribed'? It makes sense for the Receiver, but
> from the POV of the
> > Sender, you are modifying my own subscription status,
> upgrading it.
> 
> I prefer the terms "user" and "contact" to be consistent
> with RFC 3921.
> 
> > I wrote the following table of what I think are the
> most safe
> > transactions: none of the subscriptions are "upgraded"
> in any way.
> 
> I've annotated it with comments and pseudo-XMPP. Now it's
> even more
> verbose. :)
> 
> > (note: for each "Recv resets to 'X'" it is implied
> that a roster push
> > would be sent to all connected resources)
> > 
> > Sender: none
> > Recv: to
> > 
> >? => Recv resets to 'none'
> > 
> > 
> > Sender: none
> > Recv: from
> > 
> >? => Recv resets to 'none'
> > 
> > 
> > Sender: none
> > Recv: Both
> > 
> >? => Recv resets to 'none'
> 
> Why would the user's server send a probe to the contact if
> it thinks
> that the subscription state is none? (Granted, the user's
> client could
> generate a presence probe, but that's a different story.)
> 
> > Sender: To
> > Recv: none
> > 
> >? => Recv sends 'unsubscribe'
> 
> So: user's server thinks that user is sub'd to contact. It
> sends [probe
> state='both']. Contact's server thinks that user is not
> sub'd. Therefore
> I think contact's server would send [presence
> unsubscribed], i.e., "I am
> not going to send you contact's presence because you're not
> subscribed
> to his presence".
> 
> > Sender: To
> > Recv: To
> > 
> >? => Recv resets to 'none', sends
> 'unsubscribe'
> 
> As above, I think contact's server would send [presence
> unsubscribed].
> 
> > Sender: To
> > Recv: Both
> > 
> >? => Recv resets to 'From'
> 
> I think this is OK. I assume that after the roster push
> (state=from),
> the contact might send a new subscription request.
> 
> > Sender: From
> > Recv: none
> > 
> >? => Recv sends 'unsubscribed'
> > 
> > 
> > Sender: From
> > Recv: From
> > 
> >? => Recv resets to 'none', sends
> 'unsubscribed'
> > 
> > 
> > Sender: From
> > Recv: Both
> > 
> >? => Recv resets to 'To'
> 
> As above for none, why would the user's server send a probe
> to the
> contact if it thinks that the subscription state is from
> (i.e., the user
> has a subscription from the contact but not to the
> contact)?
> 
> > Sender: Both
> > Recv: none
> > 
> >? => Recv sends 'unsubscribe' and
> 'unsubscribed'
> 
> Right.
> 
> > Sender: From
> > Recv: From
> > 
> >? => Recv resets to 'none', sends
> 'unsubscribed'
> 
> IMHO user's server would not probe in this case.
> 
> > Sender: From
> > Recv: Both
> > 
> >? => Recv resets to 'To'
> 
> IMHO user's server would not probe in this case.
> 
> >> From an IM user's point of view, trying to settle
> on the highest
> >> common permissions seems more appropriate (and
> less confusing).
> > 
> > Well, the fact that we have asymmetrical states is a
> source of some
> > confusion. If you want to eliminate that, then you
> should have 'none'
> > and 'both' only.
> > 
> > But asymmetrical presences are very useful on some IM
> scenarios, like
> > transports.
> 
> Agreed.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From kevin at kismith.co.uk  Wed Apr  1 14:55:58 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Wed, 1 Apr 2009 20:55:58 +0100
Subject: [Standards] Fwd: Meeting minutes 2009-04-01
In-Reply-To: <f5aae3ec0904011255m229bc0d7kc8b0eefecd092537@mail.gmail.com>
References: <f5aae3ec0904011255m229bc0d7kc8b0eefecd092537@mail.gmail.com>
Message-ID: <f5aae3ec0904011255p62c63f36nece9889979ce39cc@mail.gmail.com>

FYI...


---------- Forwarded message ----------
From: Kevin Smith
Date: Wed, Apr 1, 2009 at 8:55 PM
Subject: Meeting minutes 2009-04-01
To: XMPP Council <council at xmpp.org>


Date: ? 2009-04-01
Time: ? 19:00 UTC
Place: ?xmpp:council at conference.jabber.org
Log: ? ?http://logs.jabber.org/council at conference.jabber.org/2009-02-18.html


0. Roll call.

Dave, Kev, Ralph and Peter present. Jack joined midway.

1. Agenda bashing.

Peter and Dave added IBR discussion and Schema discussion.

2. File Transfer Thumbnails - Accept as XEP?

All agree. Consensus that it'll need more work, but it can happen as a XEP.

3. Calendaring Extensions to Publish-Subscribe - Accept as XEP?

Consensus to delay until after discussion with calendaring people -
Dave to instigate.

4. Out-of-Band Stream Data - Accept as XEP?

Consensus to publish. Dirk to create a 'howto' for media use.

5. Roster Versioning - Ready for last call?

Agreement to wait until there are working client/servers.

6. Jingle - heads up for next week.

6a. IBR

Agreement that self-provisioning of accounts should be strongly
discouraged through inband registration.

6b. Schemas.

Discussion followed about the normativeness and syntax of schemas.
Dave proposed that schemas be marked as normative or not, depending on
the XEP, and Peter suggested that we might like to move to Relax NG.
Discussion to continue on-list.

7. Any other business?

No.

8. Next meeting.

Wednesday 8th April, 19:00 UTC.

Best,
/K

From registrar at xmpp.org  Wed Apr  1 15:07:04 2009
From: registrar at xmpp.org (XMPP Registrar)
Date: Wed, 01 Apr 2009 15:07:04 -0500
Subject: [Standards] UPDATED REGISTRY: Service Discovery Features
Message-ID: <E1Lp6iG-0004YZ-00@apollo>

The Service Discovery Features registry has been updated.

Version: 0.17

Changelog: Deleted disco#publish, which was removed from XEP-0030. (psa)

URL: http://www.xmpp.org/registrar/disco-features.html

From CvL at mail.symlynX.com  Wed Apr  1 16:17:11 2009
From: CvL at mail.symlynX.com (Carlo v. Loesch)
Date: Wed, 1 Apr 2009 23:17:11 +0200 (CEST)
Subject: [Standards] Presence distribution
In-Reply-To: <49D28442.90909@goodadvice.pages.de>
Message-ID: <200904012117.n31LHB20028753@lectern.tobij.de>

| Dave Cridland wrote:
|  > I basically refuse to consider any solution seriously unless you're
|  > measuring the effects of it post-compression

Philipp Hancke typeth:
| you are assuming that we are talking about a mere optimization of
| interdomain traffic which can be measured in byte/second?

I presume the amount of xmpp parsing - not just the amount of data -
brings in some unnecessary load on servers.

Let's optimistically consider the case s2s federation has to deal
with roughly half as many stanzas as before.. wouldn't that be a
great relief, no matter how much compression and xml parsing tricks
are applied?

Maybe a more thorough effort in counting the number of redundant
stanzas would be useful to find out how much applying repeaters (or
whatever else) brings.

I know real multicast is even further down the road for xmpp, but
that would relieve the load on "source" servers enormously if they
no longer need to get in touch with each and every subscriber's server.

So, Dave, if you think the repeaters strategy isn't good enough,
what about going for the real deal and come up with a multicast plan?



From zarevucky.jiri at gmail.com  Wed Apr  1 16:31:00 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 1 Apr 2009 23:31:00 +0200
Subject: [Standards] Fwd: Meeting minutes 2009-04-01
In-Reply-To: <f5aae3ec0904011255p62c63f36nece9889979ce39cc@mail.gmail.com>
References: <f5aae3ec0904011255m229bc0d7kc8b0eefecd092537@mail.gmail.com>
	<f5aae3ec0904011255p62c63f36nece9889979ce39cc@mail.gmail.com>
Message-ID: <e962983d0904011431v6ed10573gd4f226a326412fb0@mail.gmail.com>

> 6b. Schemas.
>
> Discussion followed about the normativeness and syntax of schemas.
> Dave proposed that schemas be marked as normative or not, depending on
> the XEP, and Peter suggested that we might like to move to Relax NG.
> Discussion to continue on-list.

I certainly support Relax NG. I just took a look at it and it seems to
be very easy to learn and use, while being more flexible and
descriptive. I could even help with moving, eventually.

From klaus.hartke at googlemail.com  Wed Apr  1 18:55:25 2009
From: klaus.hartke at googlemail.com (Klaus Hartke)
Date: Thu, 2 Apr 2009 01:55:25 +0200
Subject: [Standards] Proposed XMPP Extension: Calendaring Extensions to
	Publish-Subscribe
In-Reply-To: <E1LoM1z-00051r-00@apollo>
References: <E1LoM1z-00051r-00@apollo>
Message-ID: <4d1e95de0904011655g3c6c80ct302a650c97bac77d@mail.gmail.com>

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Calendaring Extensions to Publish-Subscribe
>
> Abstract: This specification defines calendaring extensions to Publish-Subscribe for the purposes of group calendaring and scheduling between "Calendar Users" (CUs), accessing, managing, and sharing calendaring and scheduling information on a Calendar Server, and a mechanism for alarm notifications.
>
> URL: http://www.xmpp.org/extensions/inbox/calendaring.html

In case you don't want to read the whole document, here's the tl;dr version:

* The proposal is an extension of XEP-0060 Publish-Subscribe, which
already provides us with
   - a hierarchy of nodes and items,
   - create, read, update and delete methods,
   - push notifications of new/changed/deleted items,
   - access control.

* The extension extends the pubsub <items/> query to allow complex
calendaring-specific queries, reusing the syntax defined by CalDAV.

* The extension enables scheduling interactions by extending the
<publish/> request to support iTIP methods. Unlike iMIP, these are
primarily handled by the pubsub service and not the user agents.

* The extension provides a mechanism for alarm notifications.

So it's actually quite simple; the complexity comes from the
referenced RFCs (CalDAV and iTIP).

Some background: The proposed extension is a result of an undergrad
project I participated in in the last two years. It's unfinished work,
but I was encouraged to submit it as there is some interest in the
community in this topic. Some remaining issues are:

* There are some TODOs in the document that I didn't have the time to
fill in yet, mainly related to calendar subscriptions and permissions.
* I couldn't come up with a Shakespeare-related theme for the
examples, so they're a bit messy at the moment. They all have the
right shape though.
* The document currently borrows too much text from the referenced RFCs.
* There are new CalDAV Scheduling Extensions that I wasn't aware of at
the time of writing.

I've also created a RelaxNG schema for the xCal namespace which
unfortunately hasn't made it to the surface yet (hint, hint).

--K.

From elmex at x-paste.de  Wed Apr  1 19:54:35 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Thu, 2 Apr 2009 02:54:35 +0200
Subject: [Standards] Presence distribution
In-Reply-To: <13438.1238517419.538659@puncture>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>
	<49D21F25.8050009@stpeter.im>
	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>
	<13438.1238517419.538659@puncture>
Message-ID: <20090402005435.GA31322@elmex2>

On Tue, Mar 31, 2009 at 05:36:59PM +0100, Dave Cridland wrote:
> On Tue Mar 31 16:00:20 2009, Pedro Melo wrote:
>> 1) as much as you have right now: remote servers can do whatever they  
>> want with your presence, you have no control after they leave your own  
>> server (a pessimist would even say that you don't have any control  
>> after they leave your client);
>>
>>
> Well, there's trust, and responsibility. If a contact has an outright  
> evil server, there's little you can do - similarly if your own server, or 
> even client, is subverted. For things like this, it's really game over. 
> We generally choose to model a trusted client and a trusted server, 
> although we assume an untrusted server for content in the case of e2e 
> encryption.
>
> But then there's responsibility - right now, it's inarguably your local 
> server which enforces who gets your presence, and a reverse-roster lookup 
> causes immediate problems there - if people don't get to see your 
> presence (or worse, do when they shouldn't), you've then got two places 
> to debug instead of one.
>
>
>> 2) if subscription state gets out of sync, the protocol will behave  
>> better or worse than the current version :), it really depends which  
>> roster is correct. There was a thread 2 or 3 weeks back with a  
>> tentative solution to keep subscription state in sync using the   
>> initial <presence type="probe" />.
>>
>>
> I'm not sure your initial analysis is correct, and it's related to the 
> above comments I make - if rosters are out of sync now, while it's tricky 
> to discover, you know where the blame lies instantly in each case.
>
> And a rough analysis suggests that in the current situation, you'll  
> either get presence when you *no longer* wanted it, or else you won't  
> get presence when you want it. With a reverse roster lookup, it's  
> possible to end up in a situation where you'll get presence when the  

If the server does route the wrong information to the wrong people it's buggy.
With a reverse roster lookup on a corrupted database anything might happen. I
don't get why this would justify the horrible amount of redundant information
that is sent. I want to tell my 10 contacts on jabber.org that I am online. So
sending 1 stanza will be 10 times less parsing, less bandwith, less CPU cost
for compression, than sending 10.

That factor scales with the number of contacts on a roster, which is linear,
which is incredibly bad for something that can be accomplished with O(1)
complexity.

If the problem is synchronization of subscription states, well, then fix
the problem with synchronization of subscription states.

> sender doesn't want you to, which is substantially worse, and without  
> any bad actor involved. (I could be wrong here, please check this.)

So we argue to "optimize" the protocol for this case? "Hmm, the other
side might get information I didn't want to tell him, well, lets send it
10 times instead of once. I guess that will 'fix' the problem."

I understand what you mean: Going from 10 to 1 message will indeed
be a privacy problem in case of lost 'unsubscribed' stanzas. But the
solution is to ask why the unsubscribed stanza was lost. XEP-0198 will
address at least parts of this problem.

>> But let me clarify something: although the bandwidth and processing  
>> savings of a multi-cast approach to presence distribution should be  
>> relevant, I don't believe this is compatible with a lot of other  
>> protocols that we have, so although I think multi-cast presence is a  
>> worthy long-term goal, I don't think we are ready to address it at  
>> this moment.
>
> We have this famous thing about ~87% (the figure varies) of traffic  
> being presence, and I'm afraid I think these figures skew vastly the  
> moment compression takes effect, since, by the very nature of the data 
> we're sending, it compresses really well. In fact, I'm not sure that it's 
> even worth worrying about as a problem, given how well this should 
> compress.

Oh yay, let's burn some more CPU cycles, energy is sooo cheap. Everytime you
send out 10 instead of 1 presence stanzas an additional amount of warmth is added
to the global warming.

Compression is a good optimization if you don't have anything else to save
anymore and really want to pay for the CPU time. But in this case, wouldn't be
preventing the redundancy in the first place be more beneficial in the overall
performance?

> I basically refuse to consider any solution seriously unless you're  
> measuring the effects of it post-compression - and I agree that's hard.

Everytime you compress a redundant presence stanza a tree dies. Please
think of the trees.


   Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

From imoracle.3pzqs0 at no-mx.jabberforum.org  Wed Apr  1 20:05:52 2009
From: imoracle.3pzqs0 at no-mx.jabberforum.org (imoracle)
Date: Thu, 2 Apr 2009 03:05:52 +0200
Subject: [Standards] Problem after enabling MUC in ejabberd
Message-ID: <imoracle.3pzqs0@no-mx.jabberforum.org>


Hi,

I am trying to dig into MUC protocol, but I have having problem on my
very first step.

I went to ejabberd.cfg and added the following for enabling group
chat:

Code:
--------------------
    
  {host_config, "localhost", [{auth_method, [anonymous]}, {anonymous_protocol, sasl_anon}]}.
  
  {mod_muc,      [
  		  {host, "localhost"},
  		  {access, muc},
  		  {access_create, muc},
  		  {access_persistent, muc},
  		  {access_admin, muc_admin}
  		 ]},
  
--------------------


However after enabling MUC chat in ejabberd, all of a sudden I am
unable to log in as single user using PSI IM. It just replies back as
wrong authentication credentials.

Here are the logs from PSI-IM:

Code:
--------------------
    
  <?xml version="1.0"?>
  
  
  <stream:stream xmlns:stream="http://etherx.jabber.org/streams" version="1.0" xmlns="jabber:client" to="localhost" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" >
  
  
  <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='3723173006' from='localhost' version='1.0' xml:lang='en'>
  
  
  <stream:features>
  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  <mechanism>ANONYMOUS</mechanism>
  <mechanism>DIGEST-MD5</mechanism>
  <mechanism>PLAIN</mechanism>
  </mechanisms>
  <register xmlns="http://jabber.org/features/iq-register"/>
  </stream:features>
  
  
  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
  
  
  <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
  
  
  <?xml version="1.0"?>
  
  
  <stream:stream xmlns:stream="http://etherx.jabber.org/streams" version="1.0" xmlns="jabber:client" to="localhost" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" >
  
  
  <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='1262345304' from='localhost' version='1.0' xml:lang='en'>
  
  
  <stream:features>
  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  <mechanism>ANONYMOUS</mechanism>
  <mechanism>DIGEST-MD5</mechanism>
  <mechanism>PLAIN</mechanism>
  </mechanisms>
  <register xmlns="http://jabber.org/features/iq-register"/>
  </stream:features>
  
  
  <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="DIGEST-MD5" />
  
  
  <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">bm9uY2U9Ijg0MTc1ODE1NiIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==</challenge>
  
  
  <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dXNlcm5hbWU9ImFkbWluIixub25jZT0iODQxNzU4MTU2Iixjbm9uY2U9IjE5ZFFkOU01WVFlOUpqUHZhSGJXd1dRd2lENkVINm1ac20xeGRwekpNa1k9IixuYz0wMDAwMDAwMSxkaWdlc3QtdXJpPSJ4bXBwL2xvY2FsaG9zdCIscW9wPWF1dGgscmVzcG9uc2U9NzJlMWRjMTM5ZDc3NTg3NmFlNzFlZTVlNTk3MWJkNDUsY2hhcnNldD11dGYtOA==</response>
  
  
  <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  <not-authorized/>
  </failure>
  
--------------------


However if i disable ANONYMOUS login, I can successfully login as
single user. Finally I am unable to join any chat room using PSI-IM ->
Join Group chat feature. When I click Join Group chat and a pop-up comes
up, I am unable to understand how to set an identity. For me the
identity drop down just comes blank and I am unable to understand how to
add that.

Can someone kindly help me on this issue please,
Regards,
Abhinav


-- 
imoracle

------------------------------------
JAXL - Jabber XMPP Library in PHP
http://code.google.com/p/jaxl
------------------------------------
------------------------------------------------------------------------
imoracle's Profile: http://www.jabberforum.org/member.php?userid=17412
View this thread: http://www.jabberforum.org/showthread.php?t=1754


From sachin at geodesic.com  Thu Apr  2 00:36:09 2009
From: sachin at geodesic.com (Sachin Khandelwal)
Date: Thu, 2 Apr 2009 11:06:09 +0530
Subject: [Standards] XEP-0136 - Message Archiving Preferences doubt
Message-ID: <200904021106.09674.sachin@geodesic.com>

Hi,

We are planning to implement automatic archiving (XEP-0136) for xmpp server.

Firstly I should start with my understanding of Archiving Preference (server's 
perspective) after  reading the xep, The xmpp server will have a default 
preference for all users. The user can change its default preference and 
contact specific preferences and that will be saved in the server. Now whenever 
the user logs in, as per his saved preference the server will decide whether 
to archive messages or not.

But there are some confusions : 
 1) statement from Sec 2.1 (third para) - 
However, a client MAY maintain a set of preferences in a local file which takes 
precedence over the preferences stored on the server for both local archiving 
and server-side archiving.

DOUBT:  in case of auto archiving how the server will come to know about the 
client's local file (say the local file and server stored preference is 
different). So even if in local file the auto archiving is disabled, the server 
will archive messages in its enabled in server stored preference of user.

2) statement from Sec 2.2 (4th point) - 
MUST include at least three <method/> elements, differentiated by the value of 
the 'type' attribute (i.e., at least one <method/> element each for "auto", 
"local", and "manual").

DOUBT:  But as per sec. 2.2.4.1, type attribute can only have values (auto, 
local, manual). So my understanding is that there can be at most 3 methods 
instead of at least three as specified in the above statement. If I'm wrong  
then please provide an example of more then three methods.

3) regarding sec "3.1 OTR Negotiation " -

DOUBT : My understanding is that the SSN negotiation is in between the 
clients. So how the server will come to know about the final result of 
negotiation. Say the otr mode stored in server for user and contact is require 
and forbid respectively. Now after SSN negotiation contact agrees for otr (SSN 
negotiation is successful ) then how the server will come to know about it.

And in another case say they have haven't done the SSN negotiation then with 
the above otr mode, what is expected from server, whether to archive the 
message or not.

Kindly help me with the above doubts.

Regards,

Sachin Khandelwal


From lists at ndl.kiev.ua  Thu Apr  2 07:08:20 2009
From: lists at ndl.kiev.ua (Alexander Tsvyashchenko)
Date: Thu, 02 Apr 2009 15:08:20 +0300
Subject: [Standards] XEP-0136 - Message Archiving Preferences doubt
In-Reply-To: <200904021106.09674.sachin@geodesic.com>
References: <200904021106.09674.sachin@geodesic.com>
Message-ID: <edab29795f6f40dda93fc695d9ed8124@ndl.kiev.ua>


Hello Sachin,

I cannot give the "authoritative" answers to your questions, but I'll try
to answer based on my understanding of XEP and experience from its
implementation, and it's up to you to decide whether these answers make
sense or not ;-)

On Thu, 2 Apr 2009 11:06:09 +0530, Sachin Khandelwal <sachin at geodesic.com>
wrote:

[skipped]
> whenever 
> the user logs in, as per his saved preference the server will decide
> whether 
> to archive messages or not.


From dawid.nowak at nortel.com  Thu Apr  2 07:57:17 2009
From: dawid.nowak at nortel.com (Dawid Nowak)
Date: Thu, 2 Apr 2009 13:57:17 +0100
Subject: [Standards] XEP-0166: Jingle INITIATOR and FROM fields
Message-ID: <CF268C57160BE84289D36FF46801A2C805D365DC@zharhxm0.corp.nortel.com>

Hi,

I hope somebody could clarify this for me or point me to the
documentation.

In

<iq from='romeo at montague.lit/orchard'
    id='xs51r0k4'
    to='juliet at capulet.lit/balcony'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle:1'
          action='session-initiate'
          initiator='romeo at montague.lit/orchard'


Do "from" and "initiator" fields have to be the same or is it possible
that "intitator" is different than "from" field ?

Best regards
Dawid Nowak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090402/ec1c4c45/attachment-0001.htm 

From stpeter at stpeter.im  Thu Apr  2 08:01:58 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 07:01:58 -0600
Subject: [Standards] XEP-0166: Jingle INITIATOR and FROM fields
In-Reply-To: <CF268C57160BE84289D36FF46801A2C805D365DC@zharhxm0.corp.nortel.com>
References: <CF268C57160BE84289D36FF46801A2C805D365DC@zharhxm0.corp.nortel.com>
Message-ID: <49D4B746.4050905@stpeter.im>

On 4/2/09 6:57 AM, Dawid Nowak wrote:
> Hi,
> 
> I hope somebody could clarify this for me or point me to the documentation.
> 
> In
> 
> <iq from='romeo at montague.lit/orchard'
>     id='xs51r0k4'
>     to='juliet at capulet.lit/balcony'
>     type='set'>
>   <jingle xmlns='urn:xmpp:jingle:1'
>           action='session-initiate'
>           initiator='romeo at montague.lit/orchard'
> 
> 
> Do "from" and "initiator" fields have to be the same or is it possible
> that "intitator" is different than "from" field ?

It is possible for the fields to be different. The definition of the
'initiator' attribute <http://xmpp.org/extensions/xep-0166.html#table-2>
says:

***

The full JID of the entity that has initiated the session flow. This can
be different from the 'from' address on the IQ-set of the
session-initiate message (e.g., to handle certain interactions involving
call managers, soft switches, and media relays); however, if the
'initiator' and 'from' values are different then the responder MUST NOT
interact with the 'initiator' JID unless it trusts the 'initiator' JID
or trusts the 'from' JID to authorize the 'initiator' JID to act on its
behalf.

***

The scenarios in which they are different are not yet well defined, but
http://xmpp.org/extensions/xep-0251.html will be updated at some point
to reflect discussions about this from the Jingle Thingle in early February.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090402/b123dc52/attachment.bin 

From ogoffart at kde.org  Thu Apr  2 18:01:04 2009
From: ogoffart at kde.org (Olivier Goffart)
Date: Fri, 3 Apr 2009 01:01:04 +0200
Subject: [Standards] XEP-0136 - Message Archiving Preferences doubt
In-Reply-To: <edab29795f6f40dda93fc695d9ed8124@ndl.kiev.ua>
References: <200904021106.09674.sachin@geodesic.com>
	<edab29795f6f40dda93fc695d9ed8124@ndl.kiev.ua>
Message-ID: <200904030101.08271.ogoffart@kde.org>

Le Torsdag 2 april 2009, Alexander Tsvyashchenko a ?crit?:
> Hello Sachin,
>
> I cannot give the "authoritative" answers to your questions, but I'll try
> to answer based on my understanding of XEP and experience from its
> implementation, and it's up to you to decide whether these answers make
> sense or not ;-)

Same for me ;-)

> On Thu, 2 Apr 2009 11:06:09 +0530, Sachin Khandelwal <sachin at geodesic.com>
> wrote:
>
> >  1) statement from Sec 2.1 (third para) -
> > However, a client MAY maintain a set of preferences in a local file which
> > takes
> > precedence over the preferences stored on the server for both local
> > archiving
> > and server-side archiving.
> >
> > DOUBT:  in case of auto archiving how the server will come to know about
> > the
> > client's local file (say the local file and server stored preference is
> > different). So even if in local file the auto archiving is disabled, the
> > server
> > will archive messages in its enabled in server stored preference of user.

That is because be specification tries to address different uses case.
Manual archiving and automatic archiving.
Local preferences makes no sens at all regarding automatic archiving.


And while having the local preference stored on the server makes perfect sens, 
having it mixed with the automatic logging preference is IMO confusing and 
lead to misinterpretation. (and makes the whole XEP more complex)
(something like private storage would be more suited)

> It doesn't need to: it's client role to bring server configuration up to
> client expectations.

Right.  

But the client should not keep the server configuration locally, as it may be 
changed by another computer/client/resource

> Moreover, note that auto-archiving might be slightly confusing in XEP-136:
> in the normal (non-enforced) auto-archiving mode the auto-archiving state
> of all new streams does not depend on preferences for auto-archiving, see
> 6: "Automatic archiving MUST default to disabled when each stream is
> opened."

And i think this is stupid!
It is missing a way to configure the server to have automatic log always 
active.

> The normal/enforced auto-archiving mode is specified via some external
> means not related to XEP-136 (such as server configuration) and is not
> influenced by archiving preferences.
>
> Therefore for normal auto-archiving mode it's just the opposite case that
> you should worry about: if local client settings specify that
> auto-archiving should be on by default, then when opening new stream the
> client should tell the server to enable auto-archiving, see example 29 in
> XEP-136.
>
> To be true, while I can understand the reasoning behind such scheme, in my
> implementation I've added also the intermediate mode (which can be set in
> server configuration) which turns on auto-archiving by default for all
> streams (unlike in "normal" mode), but allows clients to turn it off
> (unlike in "enforced" mode). This settings has proven to be useful for me,
> though strictly speaking it violates XEP-136.

And i think the XEP-136 should be changed to follow that scheme.


> Also note that not all preferences are meant to be interpreted by the
> server at all: for example "method" preferences are in fact for client
> interpretation only, so that client can request these methods from server
> and based on this decide how to proceed.

yep, see above.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.jabber.org/pipermail/standards/attachments/20090403/5327caf9/attachment.pgp 

From stpeter at stpeter.im  Thu Apr  2 20:59:14 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 19:59:14 -0600
Subject: [Standards] groupchat and error message routing
In-Reply-To: <7fc4fa880902110951h1592bc39s224c6a1637729d07@mail.gmail.com>
References: <7fc4fa880902110951h1592bc39s224c6a1637729d07@mail.gmail.com>
Message-ID: <49D56D72.2090506@stpeter.im>

On 2/11/09 10:51 AM, Waqas Hussain wrote:
> Hi,
> 
> When messages of type 'groupchat' and 'error' are sent to a
> non-existing resource, they are routed to the set of highest priority
> available resources. IMHO this behaviour in counter-intuitive. I don't
> see why an unintended resource would want a groupchat or error
> message, or how it's supposed to deal with it. Also note that the 'to'
> attribute gets overwritten, so the recieving resource doesn't even
> know to which resource the messages were originally directed. Could
> someone describe some cases where this is useful?
> 
> 
> Relevent rfc3921bis-07 sections:
> 
> 8.2.2.  No Resource Matches
> <http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#rules-fulljid-nomatch>
> "For a message stanza, the server SHOULD treat the stanza as if it
> were addressed to <user at domain> as described in the next section (but
> without modifying the value of the 'to' attribute)."
> 
> 8.3.1.1.  Message
> <http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#rules-barejid-resource-message>
> "For a message stanza of type "chat", "error", "groupchat", or
> "normal", the server SHOULD deliver the stanza to the highest-priority
> available resource."

Fixed:

http://svn.xmpp.org:18080/browse/XMPP/trunk/internet-drafts/draft-saintandre-rfc3921bis-09.xml?%40diffMode=u&%40diffWrap=s&r1=2960&r2=2961&u=3&ignore=&k=

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090402/1f6ca3ac/attachment.bin 

From editor at xmpp.org  Thu Apr  2 22:27:43 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 02 Apr 2009 22:27:43 -0500
Subject: [Standards] NEW: XEP-0264 (File Transfer Thumbnails)
Message-ID: <E1Lpa4F-0008Vr-00@apollo>

Version 0.1 of XEP-0264 (File Transfer Thumbnails) has been released.

Abstract: This specification defines a way for a client supply a preview image for a file transfer.

Changelog: Initial published version. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0264.html


From editor at xmpp.org  Thu Apr  2 22:29:56 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 02 Apr 2009 22:29:56 -0500
Subject: [Standards] NEW: XEP-0265 (Out-of-Band Stream Data)
Message-ID: <E1Lpa6O-00005i-00@apollo>

Version 0.1 of XEP-0265 (Out-of-Band Stream Data) has been released.

Abstract: This specification defines how to send parts of an XML stream over a direct connection between peers. This allows to send large stanzas or binary data without blocking the XML stream for other stanzas.

Changelog: Initial published version. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0265.html


From stpeter at stpeter.im  Sat Apr  4 17:18:34 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sat, 04 Apr 2009 16:18:34 -0600
Subject: [Standards] XEP-50: Ad hoc command protocol is stateful
In-Reply-To: <D0040312-E60F-4BA4-9050-97F109B30677@Isode.com>
References: <1CC0EBD5-3C9A-4644-9146-D78A077871DE@Isode.com>	<133fd4c60812120206w56ca778cmde36d22d6d49767e@mail.gmail.com>	<6A68B309-D42C-4EBD-BC28-08CBE0E1FAE9@Isode.com>	<133fd4c60812120703u4f5f0722lfd9971e3e2a74834@mail.gmail.com>
	<D0040312-E60F-4BA4-9050-97F109B30677@Isode.com>
Message-ID: <49D7DCBA.2000808@stpeter.im>

On 12/12/08 8:10 AM, Kurt Zeilenga wrote:
> 
> On Dec 12, 2008, at 7:03 AM, Remko Tron?on wrote:
> 
>> Hi Kurt,
>>
>>> Doesn't work for moving to previous stages.  The design expects the
>>> server
>>> to remember the previous states, not the client.
>>
>> Hmm, I see, good point.
>>
>> How about adding the extra requirement that sending the 'prev' command
>> also submits the hidden parameters from the form? Although it sounds a
>> bit weird to submit forms on previous actions, maybe the state should
>> be kept outside of the form element.
> 
> Seems either approach would likely address the problem.  I don't have a
> strong preference to which approach is taken.

Does the XEP need to be updated along these lines, perhaps just to
include an implementation note?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090404/41d2726f/attachment.bin 

From editor at xmpp.org  Sat Apr  4 21:02:49 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Sat, 04 Apr 2009 21:02:49 -0500
Subject: [Standards] UPDATED: XEP-0177 (Jingle Raw UDP Transport Method)
Message-ID: <E1LqHhB-0002jD-00@apollo>

Version 0.17 of XEP-0177 (Jingle Raw UDP Transport Method) has been released.

Abstract: This specification defines a Jingle transport method that results in sending media data using raw datagram associations via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required.

Changelog: Removed security consideration about sending IP address before session acceptance, since that functionality is no longer supported. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0177.xml?%40diffMode=u&%40diffWrap=s&r1=2858&r2=2980&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0177.html


From stpeter at stpeter.im  Sun Apr  5 13:18:59 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 12:18:59 -0600
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <30276.1226523901.569488@peirce.dave.cridland.net>
References: <30276.1226523901.569488@peirce.dave.cridland.net>
Message-ID: <49D8F613.1010903@stpeter.im>

I'm open to doing this if someone wants to help with the CSS/XSL.

On 11/12/08 (!) 2:05 PM, Dave Cridland wrote:
> I appreciate that this is almost inexcusably trivial, but bear with me.
> 
> On the Council list, Peter Saint-Andre happens to mention the potential
> confusion of having both Standards Track XEPs and Informational XEPs
> (and there's others) all in the same series.
> 
> This has hit the IETF, too - everyone refers to an RFC as a "Standard",
> even though many RFCs aren't standards at all - in fact, strictly
> speaking, very few indeed are - see RFC 1796 for a discussion. (And that
> RFC is not a standard, either).
> 
> So to make it more obvious, I suggested colour coding the different
> XEPs. The remainder of this email is what I sent to the Council list -
> I'd be interested in people's opinions, although I'm not desperately
> interested in *which* colours, precisely. Something I've noticed is that
> the XSF's logo can now be retromemed into symbolizing the various
> streams of documents we produce. :-)
> 
> ...
> 
> Perhaps we could consider styling them differently - I'm put in mind of
> the UK Government (and probably elsewhere, too) practise of "white
> papers", "green papers", etc, and wondering whether we literally follow
> that practise - so Informational documents would "go white" when they
> went Active, and documents in the "working" phase of the lifecycle -
> Experimental and Proposed - would be Green. It's probably worth making
> Proposed blue, such that it's a "blueprint" of the proposal.
> 
> For the various "failure" states, I'd simply pick grey.
> 
> For Standards Track documents, I quite like the idea of Final documents
> "going gold", and that just leaves Draft, which for no good reason I'll
> pick Pink.
> 
> This yields:
> 
> Retracted, Deferred, Rejected, Deprecated, Obsolete -> #7F7F7F
> Active -> #FFFFFF
> Experimental -> #CFEFCF
> Proposed -> #AFCFFF
> Draft -> #FFEFEF
> Final -> #FFFFCF
> 
> These colours can live in the side margins of the document, so there's a
> very clear visual indicator of the status of the document.
> 
> And this can be accomplished reasonably easily with a minor XSL and CSS
> tweak, which I've attached in patch form.
> 
> Dave.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/8dec93d1/attachment.bin 

From stpeter at stpeter.im  Sun Apr  5 13:21:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 12:21:31 -0600
Subject: [Standards] Gateway behavior regarding nicknames and custom
	status
In-Reply-To: <495BA8B8.10706@pobox.com>
References: <495BA8B8.10706@pobox.com>
Message-ID: <49D8F6AB.7010305@stpeter.im>

On 12/31/08 10:15 AM, Matt Campbell wrote:
> Hello from an XMPP newcomer:
> 
> I've noticed that when a user logs in, the PyMSNt gateway queries the
> server for the user's vCard and, if a nickname is set in that vCard,
> passes that nickname on to the legacy IM network.  Likewise, when the
> user broadcasts a presence stanza with a <status> element, PyMSNt passes
> this custom status on to the legacy network.  However, it is sometimes
> desirable to set one's nickname and custom status on the legacy network
> independently.  Is such a feature beyond the intended scope of XMPP
> gateways, or is this an area that has simply not been considered and
> discussed?  I've verified that XEP-0100 doesn't cover this topic.  I'd
> appreciate any thoughts or clarifications.

As far as I know, this was always out of scope for the gateways.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/15bc2e91/attachment.bin 

From stpeter at stpeter.im  Sun Apr  5 13:32:06 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 12:32:06 -0600
Subject: [Standards] Errata, and some suggestions to various specs
In-Reply-To: <7fc4fa880811051319u7e425d1ar14d85bdc1de959c7@mail.gmail.com>
References: <7fc4fa880811051319u7e425d1ar14d85bdc1de959c7@mail.gmail.com>
Message-ID: <49D8F926.7020203@stpeter.im>

On 11/5/08 2:19 PM, Waqas wrote:
> A file I have been adding to while recently going over the specs with
> an implementor's point of view:
> 
> ===== Start errata.txt =====
> 
> http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#substates-out-unsubscribe
> (XMPP-IM)
> 
> |  "To + Pending In"       |  MUST    |  "Pending In"             |
> 
> should be
> 
> |  "To + Pending In"       |  MUST    |  "None + Pending In"      |

Fixed.

> ---
> http://xmpp.org/extensions/xep-0049.html (Private XML Storage)
> 
> The XEP doesn't specify what to do when a user requests non-existing
> private data. Servers seem to return the stanza as is, and no error.
> This should be explicitly specified.

We'd need to find out what servers are currently doing here. I would
think that returning <item-not-found/> (404) would be appropriate.

> It would also be useful for there to be a way for the client to ask
> the server to list all data stored for that client. I'm for example
> interested in learning what my various clients might have stored over
> the years. Doing that when the client has not sent a child for the
> query element would be a simple and backwards compatible way to do it.

That's a feature request. I don't think we'll be adding new features to
XEP-0049, which is Historical.

> ---
> http://xmpp.org/extensions/xep-0049.html#example-3 (Private XML Storage)
> 
> Since the preceding text states:
> 
>   "the server MUST return a "Forbidden" or "Service Unavailable" error
> to the sender (the latter condition is in common use by existing
> implementations, although the former is preferable)."
> 
> the example should preferably use a "Forbidden" error.

Done. Remember, this is an Historical specification. The last time I
checked, implementations used <service-unavailable/>. Feel free to check
up on how current implementations do this (probably checked jabberd14 only).

> ---
> http://xmpp.org/extensions/xep-0049.html#example-4 (Private XML Storage)
> 
> Since the preceding test states "the server SHOULD return a "Bad
> Format" error", therefore, the example SHOULD use a "Bad Format"
> error.

Done.

> ---
> http://xmpp.org/extensions/xep-0228.html#intro (Requirements for Shared Editing)
> 
> "have been developed usign XMPP"
> 
> should be
> 
> "have been developed using XMPP"

Please send minor typo reports to editor at xmpp.org.

> ---
> http://xmpp.org/extensions/xep-0045.html#invite-direct (Multi-User Chat)
> 
> "A method for sending a direct invitation (not mediated by the room
> itself) is defined in another specification."
> 
> Saying "another specification" is rather vague. I have no idea which
> other specification is being referred to.

That's XEP-0249, which perhaps was still in the inbox when we last
updated XEP-0045.

> ===== End errata.txt =====
> 
> Hopefully this was the Right Way to post these. I was wondering if I
> should have posted these separately, particularly the part about
> XEP-0049.

I prefer it you send the really small stuff to editor at xmpp.org (or
directly to me, preferably via IM), and provide more substantial
feedback to the list with one message per XEP, which makes it easier to
track.

Thanks for the feedback, and sorry that it's taken me almost 5 months to
process it!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/6a676aad/attachment-0001.bin 

From stpeter at stpeter.im  Sun Apr  5 13:40:16 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 12:40:16 -0600
Subject: [Standards] Section 2.3 of XEP-0107
In-Reply-To: <C5A64ECC-AF7D-4098-9390-A60C131D8C9E@webkeks.org>
References: <097CDEF2-1521-4311-960C-0D0277DDAD8B@webkeks.org>	<4993365C.3010105@ralphm.ik.nu>
	<C5A64ECC-AF7D-4098-9390-A60C131D8C9E@webkeks.org>
Message-ID: <49D8FB10.3020209@stpeter.im>

On 2/12/09 7:44 AM, Jonathan Schleifer wrote:
> Am 11.02.2009 um 21:34 schrieb Ralph Meijer:
> 
>> If Gajim implements sending along moods in messages, for the sole
>> purpose of replacing PEP, I would consider that a bug. It goes against
>> the very reason we started to define our publish-subscribe
>> specifications for.
> 
> We had a few discussions about that in the Gajim team and finally could
> agree that this is not intended. and reverted that diff a long while
> ago. It seems a few misunderstood the XEP and after re-reading it got it
> right, so maybe we could add some clarification there.

Clarified:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0107.xml?%40diffMode=u&%40diffWrap=s&r1=2467&r2=2990&u=3&ignore=&k=

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/ee2d57e1/attachment.bin 

From stpeter at stpeter.im  Sun Apr  5 14:01:15 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 13:01:15 -0600
Subject: [Standards] Call for Experience: XEP-0085
	(Chat	StateNotifications)
In-Reply-To: <Lastwebpage.3j8oyo@no-mx.jabberforum.org>
References: <C51AF143.FBB1%boyd.fletcher@jfcom.mil><Lastwebpage.3hndro@no-mx.jabberforum.org>	<20081021231934.44007205@webkeks.org><Lastwebpage.3hoz2z@no-mx.jabberforum.org>	<490793A4.3030004@stpeter.im>
	<Lastwebpage.3j8oyo@no-mx.jabberforum.org>
Message-ID: <49D8FFFB.2020805@stpeter.im>

On 11/21/08 12:10 PM, Lastwebpage wrote:
> one more...
> (I see the "Call for experience" today, but it's for developers, not
> for "foolish end user" like myself, therefore I post it here... )
> 
> some comments:
> 
> 1) Time Values
> in the XEP I see, "e.g. 5sec, e.g. 30sec, e.g. 2 minutes."
> What means this *e.g.*? A client side adjustable setting?

I sure hope not.

> Imagine I am an slow typer and setup 20sec, 30sec,...
> in this case the other side would see many changes between paused an
> inactive. And the other side don't know if the state is really X or Y,
> why this phrase is not "Should be 5 sec","Should be 30 sec", or however
> ?
> sorry, this e.g. confuse me a little bit.

It might be good to remove all mention of specific time values.

> 2)2 min and gone
> I really don't know if it is a good idea to put both condition in one
> state.
> 2 min=> The other side search in wikipedia, translate a text, user ask
> back to another user, or whatever, but it's possible that this 2 minutes
> elapse in a "normal" chat.

Perhaps 10 minutes is more appropriate.

> closing the chat window=> The other side have better things to do than
> chat with me any longer
> 
> sorry, but this is not the same, in my opinion.

Yes, you can't really know the intent -- some users might close windows
all the time, but it doesn't really mean that they're gone.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/d2cbbbea/attachment.bin 

From stpeter at stpeter.im  Sun Apr  5 17:24:33 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 16:24:33 -0600
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
 XEP-0136 ?
In-Reply-To: <49404294.7070105@eaktion.com>
References: <49404294.7070105@eaktion.com>
Message-ID: <49D92FA1.1030408@stpeter.im>

On 12/10/08 3:28 PM, Paolo Nesti Poggi wrote:
> Hi,
> 
> writing about XEP-0136.
> 
> I't  seems to me that there is an inconsistency between section 7.2
> http://xmpp.org/extensions/xep-0136.html#manage-retrieve
> 
> "To request a page of messages from a collection the client sends a
> <retrieve/> element. The 'with' and 'start' attributes specify the
> participating full JID and the start time (see XEP-0082). Both
> attributes MUST be included to uniquely identify a collection."
> 
> That is, "the participating full JID" is stated here,
> 
> and section 10.2
> http://xmpp.org/extensions/xep-0136.html#impl-exactmatch
> that is referred to by the previous section:
> 
> "When the 'exactmatch' attribute is set to "true" or "1" on an element
> of <item/>, <list/>, <remove/>, or <retrieve/>, a 'with' value such as
> "example.com" matches that exact JID only rather than <*@example.com>,
> <*@example.com>, or <example.com/*>"
> 
> where including the element <retrieve/> among those with wich the
> exactmatch attribute can be used seems to imply that a collection can be
> retrieved using only a part of the JID.

You are right -- the words "participating full JID" in the first
paragraph of Section 7.2 unnecessarily and incorrectly limit the
matching for collection retrieval. I've fixed that:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u&%40diffWrap=s&r1=2415&r2=2993&u=3&ignore=&k=

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/2bc44d9a/attachment-0001.bin 

From stpeter at stpeter.im  Sun Apr  5 17:33:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 16:33:22 -0600
Subject: [Standards] Data Forms schema
In-Reply-To: <494FC33A.3010503@yahoo.com>
References: <494FC33A.3010503@yahoo.com>
Message-ID: <49D931B2.4050001@stpeter.im>

On 12/22/08 9:41 AM, Brett Zamir wrote:
> For XEP-0004, in addition to the correction in the schema we discussed
> earlier on loosening element ordering requirements within <field/>, the
> schema dealing with <field/> also ought to be updated to allow for Data
> Forms validation children:
> 
> <xs:any namespace='http://jabber.org/protocol/xdata-validate'/>
> 
> or
> 
> <xs:any namespace='##any'/>
> 
> 
> ....if you want to allow more than just Data Forms Validation children...

Sure, we want to at least allow XEP-0221 data (the media element).

It's the *extensible* messaging and presence protocol. If we put a
notation of <xs:any namespace='##any'/> everywhere that an element could
be extended, our schemas would be extremely long indeed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/e5f7f1b9/attachment.bin 

From stpeter at stpeter.im  Sun Apr  5 17:36:09 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 16:36:09 -0600
Subject: [Standards] roster item exchange
In-Reply-To: <2fd53c3a0812291342q538420ben6280c6c5066e5b46@mail.gmail.com>
References: <2fd53c3a0812291342q538420ben6280c6c5066e5b46@mail.gmail.com>
Message-ID: <49D93259.3010409@stpeter.im>

Ciao Fabio!

On 12/29/08 2:42 PM, Fabio Forno wrote:
> Hi,
> 
> we are writing a facebook gateway and we'd like to use xep-144 for
> pushing roster items to the client. Besides the fact that it seems
> implemented by few clients, I've found another problem. With xep 144
> the gateway has no means for knowing whether the user has accepted the
> presence subscription or not, just that the client has processed it
> (the result iq is sent as soon as the roster offer has been received).
> This leads to two unpleasant case:
> - if the gateway assumes that the items have been accepted and the
> user does some mistakes (or the client dies), he won't be able to see
> the contacts any more
> - if the gateway always sends the roster push we have either
> unnecessary traffic and the user may be bothered with subscriptions he
> doesn't want to accept
> 
> The problem is that I don't see any workaround but extending the xep
> notifying the gateway which contacts have been accepted and which not

I haven't looked at XEP-0144 in a long time, but IMHO it would be fairly
straightforward to add this kind of optional notification. I'd be happy
to work with you on that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/a6083640/attachment.bin 

From stpeter at stpeter.im  Sun Apr  5 17:42:06 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 16:42:06 -0600
Subject: [Standards] Data Forms and empty fields
In-Reply-To: <494FB20F.9020600@yahoo.com>
References: <494F9509.4020109@yahoo.com>	<18831.1229956672.885200@peirce.dave.cridland.net>
	<494FB20F.9020600@yahoo.com>
Message-ID: <49D933BE.6020607@stpeter.im>

On 12/22/08 8:28 AM, Brett Zamir wrote:
> On 12/22/2008 10:37 PM, Dave Cridland wrote:
>> On Mon Dec 22 13:24:25 2008, Brett Zamir wrote:
>>> In the Data Forms spec XEP-0004, what is an implementation to do for
>>> each type if there are empty fields?
>>>
>>> Send an empty<value/>  or an empty<field/>?
>>>
>>> An empty field would seem to make sense for lists at least, but I
>>> wasn't clear on what it should be for say, text-single.
>>
>> <value/> is semantically equivalent to <value></value>, and therefore
>> suggests an actual value of a zero-length string, rather than no value
>> at all.
>>
>> Which doesn't answer your question, of course, but it suggests that
>> the answer might depend on what you mean by "empty fields".
> Yeah. Or what the spec using Data Forms means (in whether to allow a
> distinction between the two). I think perhaps the specs using Data Forms
> should specify this. For example, in Pubsub, where it is used to send in
> configuration items, perhaps it wouldn't be a bad idea to require
> <value/> to indicate that the sender didn't mistakenly leave out the field.

As Dave said, <value></value> means the empty string (which in pubsub
configuration forms might mean the root collection node).

IMHO if the sender mistakenly leaves out a field, that is the sender's
problem. The recipient's behavior should be to leave the existing values
alone (if any).

> Otherwise, it is possible one server-side implementation will reject
> data that doesn't at least possess a <value/> child and spit out errors,
> while another may treat an empty <field/> and <field><value/></field> as
> the same, and yet another might spit out errors if there is a <value/>
> child, so I really think this should be specified in the specs using
> Data Forms, if not also mentioned in Data Forms.

I admit that error handling related to data forms is less than perfect.
However, for pubsub at least I will try to clarify this in the next
revision of the spec.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/02884cba/attachment-0001.bin 

From stpeter at stpeter.im  Sun Apr  5 18:08:12 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 17:08:12 -0600
Subject: [Standards] Data Forms Validation
In-Reply-To: <4951F516.4060609@yahoo.com>
References: <4951F516.4060609@yahoo.com>
Message-ID: <49D939DC.4060208@stpeter.im>

On 12/24/08 1:38 AM, Brett Zamir wrote:
> Hi,
> 
> I love the Data Forms spec and the Data Forms Validation spec, but I
> have a number of questions and thoughts relating to Data Forms
> Validation, XEP-0122.
> 
> 1) If Data Forms validation is approved, list-multi and list-single
> would need to changed as it says in section 3.3 of XEP-0004, that they
> "MUST NOT insert new options".

This means that if you receive, say, a list-multi field with 5 options,
when you return the form you can't include the same list-multi field
with 6 options (thus adding an option that was not included in the field
you received). Does XEP-0122 suggest that you can do that? I suppose it
is implied by the following text in Section 3.2:

   For "list-single" or "list-multi", to indicate that the user
   may enter a custom value (matching the datatype constraints)
   or choose from the predefined values, the <validate/> element
   shall contain an <open/> child element.

I'll need to think about that a bit. It would help here (and elsewhere
throughout XEP-0122) if we had more examples.

> 2) In 3.2, it states "Any validation method applied to a field of type
> "list-multi", "list-single", or "text-multi" (other than <basic/>) MUST
> imply the same behavior as <open/>, with the additional constraints
> defined by that method." What does this mean exactly? Why should the
> other methods require behavior like <open/> which allows open-ended
> choices for lists?

I don't know what that means. I'll need to ask the XEP author about it.

> 3) What should one do if one wants an open-ended list of JIDs? If
> <open/> validation should be used with jid-multi/jid-single (as
> expressly allowed in Table 1 of Data Forms Validation), what if one also
> or instead wants a jid-multi to be validated separately as with
> text-multi? Should there instead be a JID datatype, so a
> list-multi/list-single could be used in contrast to say text-multi which
> didn't arrange (or for submissions, require) the items in a constrained
> list?

Could you provide an example?

> 4) If list-multi can become open-ended, why are range and regex
> validation discouraged for it in Table 1 in DFV? And what's wrong with
> jid-multi being validated against regex if they could be made to
> validate separately (as would seem to make sense). And shouldn't
> "jid-single" be listed as being not allowable under "range"?

Regex matching for JIDs makes some sense to me, but range matching does not.

> 5) Under "range" in Table 1, it states that "'For text-single', allow
> user to increment/decrement through possible values". What about decimal
> types? These can fall in a range, but not really be incrementable. I
> think discussion of increment/decrement (and about discussion of display
> issues in general) is a helpful one but might as a result of this be
> more suited under a discussion of data types and display. This would
> also allow mention, for example, that a date or time type could be
> presented with a calendar/clock selection or display, an integer could
> present an incrementing text box, a decimal type could be presented as a
> slider, etc. (or a progress meter in the case of results).

I agree that it would be good to specify range validation more carefully.

> 6) Shouldn't "fixed" be a type not allowed for "open" validation in
> Table 1?

Yes.

To your other points...

http://mail.jabber.org/pipermail/standards/2008-December/020827.html

   Also, as for Table 1, as note 10 states, "If a particular field
   type is not listed, the display MAY include validation support,
   but is not expected to do so", although it is pretty obvious, I
   think the "boolean" type should be added to the chart to forbid
   it for each type of validation (as with "hidden").

Agreed.

http://mail.jabber.org/pipermail/standards/2008-December/020828.html

   Also on Data Forms Validation, why are jid-multi and jid-single
   discouraged for use with Basic validation, or even 'hidden' for
   that matter, if results ca be verified?

I'm not sure. It seems that you could at least match the datatype.

I think this spec needs to be revised to clarify these points. It would
also benefit from lots more examples. Brett, do you have examples to
share, or shall I work with Matt Miller on that?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/c760c1ed/attachment.bin 

From stpeter at stpeter.im  Sun Apr  5 18:39:53 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 17:39:53 -0600
Subject: [Standards] Notification about subscription request declination
In-Reply-To: <e962983d0901171321s7b65dce2jeca9a46273da4522@mail.gmail.com>
References: <e962983d0901171321s7b65dce2jeca9a46273da4522@mail.gmail.com>
Message-ID: <49D94149.4030308@stpeter.im>

On 1/17/09 2:21 PM, Ji?? Z?rev?ck? wrote:
> Hello,
> 
> I'm implementing a new XMPP client with it's own library and I've come
> across a problem.
> When a client declines some contact's subscription request, the server
> doesn't notify any other resources about it in any way. Therefore, it
> is impossible to track, whether the contacts request still apply.
> That's a bit of a problem, as you don't know the exact state of the
> subscription. Perhaps I have missed something and there is a way to
> get this information, but I haven't found it in the current rfc3921bis
> draft. So in case I'm not mistaken and this problem really exists, it
> would be nice to add such notification to the protocol, wouldn't it?
> Any ideas?

I see what you mean. I'll think about that a bit for rfc3921bis...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/0cce18fd/attachment.bin 

From fabio.forno at gmail.com  Sun Apr  5 18:52:54 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Mon, 6 Apr 2009 01:52:54 +0200
Subject: [Standards] roster item exchange
In-Reply-To: <49D93259.3010409@stpeter.im>
References: <2fd53c3a0812291342q538420ben6280c6c5066e5b46@mail.gmail.com>
	<49D93259.3010409@stpeter.im>
Message-ID: <2fd53c3a0904051652r2daf7832vac2cb8e4b94558a4@mail.gmail.com>

On Mon, Apr 6, 2009 at 12:36 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> I haven't looked at XEP-0144 in a long time, but IMHO it would be fairly
> straightforward to add this kind of optional notification. I'd be happy
> to work with you on that.

Great! we have just implemented in a facebook gateway and in Lampiro a
great deal of xep 144 and pep for avatars and we found few quirks and
possible optimizations that will improve user experience. I know that
we shouldn't encourage too much transports (they must be painful! :D),
but the ability of manipulating from another entity the roster is
terrific for automatically adding/changing services accordingly to the
user context. Tomorrow or in the next days we can catchup via jabber
for exchanging ideas. Now it's 2am here, better go to bed ;)

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From stpeter at stpeter.im  Sun Apr  5 21:28:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 05 Apr 2009 20:28:31 -0600
Subject: [Standards] Question about XEP-191: Simple Communications
	Blocking
In-Reply-To: <952A4B1F81123B479292D4B5FDC00D85EEEC1F@SRV-EXSC03.webex.local>
References: <952A4B1F81123B479292D4B5FDC00D85EEEC1F@SRV-EXSC03.webex.local>
Message-ID: <49D968CF.7020703@stpeter.im>

On 1/9/09 12:02 PM, Ben Schumacher wrote:
> Peter, et al-
> 
> I have a quick query about XEP-191. 

Quick question, slow reply. :P

> In Section 3, Relationship to
> Privacy Lists, the XEP states that the new protocol is intended to be a
> user-friendly front-end to the privacy lists protocol. While I have some
> personal issues with this stated goal (in particular I don?t think that
> XEP-16?s requirement for in-order processing is particularly useful), I
> do have a specific question about implementation.

I think the point was that if you (the server / service provider)
already have XEP-0016 support in place, you could use the same backend
data store for XEP-0191 support. I don't know how important that really
is, though...

> First, should there be some ?standard? name for a list that is generated
> by this protocol if it is retrieved via the XEP-16 protocol? Using the
> URI of the blocking protocol would probably be sufficient (and could
> provide a hint to sophisticated clients that this list was generated
> using the simple protocol), but I am curious if there is guidance from
> the standards body.

No guidance yet, no. It's not clear to me how we would handle "lists"
that are created via XEP-0191 but then migrate back to XEP-0016, for
instance.

> Additionally, the implications listed in Section 3 state:
> 
> If all of a user's clients always use simple communications blocking,
> then the default privacy list will be equivalent to the blocklist and
> the default privacy list will be a kind of "virtual list" (in the sense
> that it is never modified directly by any of the clients).
> 
> This rule implies to me that there should be some interaction with
> entity capabilities such that the server knows if the clients support
> this protocol or not. This would, of course, require that the client
> publish proper caps in its initial presence and the server will have to
> defer this decision (i.e. should I be using the Simple Blocking list vs.
> the list defined as ?default? in XEP-16) until the capabilities
> information has been cached by the server.

That seems quite reasonable. Naturally the server could also figure this
out via a disco#info request.

> Finally, the 5^th implication in this section states:
> 
> If one of a user's clients makes active something other than the default
> privacy list, the user may receive communications from contacts who are
> blocked in the default list.
> 
> Is there an expectation here that a connect client that?s using the
> simple blocking protocol would get the push notifications of the updated
> blocklist? That question applies to the wider context of the usage of
> this protocol ? should privacy list modification cause simple blocking
> protocol pushes and vice versa?

I hadn't considered that before, but I think the answer is "yes".

> Thanks for your time.

Thanks for your patience. :)

If you're still interested in this topic, it might be worth putting some
effort into more clearly defining the relationship between XEP-0016 and
XEP-0191.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090405/af130a19/attachment-0001.bin 

From lists at ndl.kiev.ua  Mon Apr  6 01:28:54 2009
From: lists at ndl.kiev.ua (Alexander Tsvyashchenko)
Date: Mon, 06 Apr 2009 09:28:54 +0300
Subject: [Standards]
 =?utf-8?q?inconsistency_between_section_7=2E2_-_10=2E?=
 =?utf-8?q?2_in_XEP-0136_=3F?=
In-Reply-To: <49D92FA1.1030408@stpeter.im>
References: <49404294.7070105@eaktion.com> <49D92FA1.1030408@stpeter.im>
Message-ID: <706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>


Hello Peter,

On Sun, 05 Apr 2009 16:24:33 -0600, Peter Saint-Andre <stpeter at stpeter.im>
wrote:

> You are right -- the words "participating full JID" in the first
> paragraph of Section 7.2 unnecessarily and incorrectly limit the
> matching for collection retrieval. I've fixed that:
> 
>
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u&%40diffWrap=s&r1=2415&r2=2993&u=3&ignore=&k=

... in fact it seems I've managed to convince several people in the
opposite already (including topic-starter) based on current XEP-136 wording
;-) See discussion starting from this comment:
https://www.ndl.kiev.ua/content/modarchiveodbc-release#comment-117

Based on the diff I'm not really sure anymore what "retrieve" is supposed
to do now:

1) Allowing non-full JID means "retrieve" may match several collections.
2) Phrase "Both attributes MUST be included to uniquely identify a
collection" indicates it may not.

The following arguments imply that phrase about "unique collection
identification" is removed to bring it back to consistent state (and, thus,
allow several collections to be matched by "retrieve").

I'm not really sure that allowing to select several collections in
"retrieve" is such a good idea for the reasons mentioned in discussion at
the link above - to rephrase it shortly here, in my opinion "list" gets the
list of all collections matching some criteria, while "retrieve" gets all
messages _within specified collection_ matching some criteria.

Such change means that "retrieve" starts partially overlap with "list", and
this extension is not very natural:

1) "retrieve" still cannot be used to perform the same functionality as
"list": it does not support "end" attribute and gives different meaning to
"start" attribute thus not allowing queries within given time range, and it
already uses RSM to limit messages retrieved, so RSM cannot be used to
limit collections matched.

2) How RSM limiting of messages should work across several different
collections matched in single "retrieve" command? If it should treat all
messages as "linear" list, so that RSM-limited "retrieve" over several
different collections is a kind of sliding window, then we're back at our
argument about using change notifications in RSM, as then individual
collections versioning does not really help us anymore to detect changed
collections if change happened between two successive RSM queries.

I see two possible solutions:

1) Keep things like they were before, so that "retrieve" may return
messages from one collection only. Requires rollback of the last change to
XEP and removing "exactmatch" support by "retrieve" from 10.1 and from XML
Schema.

2) If support for several collections in "retrieve" is really required,
then some work should be done to bring all other dependent things to
consistent state: extend "retrieve" to support all the same attributes as
"list" does, allow two different RSMs (for collections and messages) in
"retrieve", specify the way RSM for messages works when multiple
collections are matched, and also I think that adding "changes
notifications" to RSM is inevitable then.

-- 
Good luck!                                     Alexander

From js-xmpp-standards at webkeks.org  Mon Apr  6 02:44:41 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Mon, 6 Apr 2009 09:44:41 +0200
Subject: [Standards] Section 2.3 of XEP-0107
In-Reply-To: <49D8FB10.3020209@stpeter.im>
References: <097CDEF2-1521-4311-960C-0D0277DDAD8B@webkeks.org>	<4993365C.3010105@ralphm.ik.nu>
	<C5A64ECC-AF7D-4098-9390-A60C131D8C9E@webkeks.org>
	<49D8FB10.3020209@stpeter.im>
Message-ID: <F540C68A-F80B-4727-BAE3-ECFA7F70220A@webkeks.org>

Am 05.04.2009 um 20:40 schrieb Peter Saint-Andre:

> Clarified:
>
> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0107.xml?%40diffMode=u&%40diffWrap=s&r1=2467&r2=2990&u=3&ignore=&k=


Sounds good :).

--
Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 801 bytes
Desc: Signierter Teil der Nachricht
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/80512cb3/attachment.pgp 

From dave at cridland.net  Mon Apr  6 05:49:52 2009
From: dave at cridland.net (Dave Cridland)
Date: Mon, 06 Apr 2009 11:49:52 +0100
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <49D8F613.1010903@stpeter.im>
References: <30276.1226523901.569488@peirce.dave.cridland.net>
	<49D8F613.1010903@stpeter.im>
Message-ID: <19257.1239014992.504500@puncture>

On Sun Apr  5 19:18:59 2009, Peter Saint-Andre wrote:
> I'm open to doing this if someone wants to help with the CSS/XSL.
> 
> 
Didn't I send you some already?

> > And this can be accomplished reasonably easily with a minor XSL  
> and CSS
> > tweak, which I've attached in patch form.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Mon Apr  6 07:19:44 2009
From: dave at cridland.net (Dave Cridland)
Date: Mon, 06 Apr 2009 13:19:44 +0100
Subject: [Standards] Presence distribution
In-Reply-To: <20090402005435.GA31322@elmex2>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>
	<49D21F25.8050009@stpeter.im>
	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>
	<13438.1238517419.538659@puncture> <20090402005435.GA31322@elmex2>
Message-ID: <19257.1239020384.317796@puncture>

On Thu Apr  2 01:54:35 2009, Robin Redeker wrote:
> If the server does route the wrong information to the wrong people  
> it's buggy.

Well... Possibly. Or it might be lacking sufficient information to  
route correctly - that part we simply don't see today.


> With a reverse roster lookup on a corrupted database anything might  
> happen. 

Hmmmm - I'm not talking about a corrupted database, I'm talking about  
a roster which has missed an unsubscribed or two.

> I
> don't get why this would justify the horrible amount of redundant  
> information
> that is sent. 

If privacy isn't important to you, go use MSN. ;-)

> I want to tell my 10 contacts on jabber.org that I am online. So
> sending 1 stanza will be 10 times less parsing, less bandwith, less  
> CPU cost
> for compression, than sending 10.
> 
> 
Do you have any figures? I'd be curious to know whether it's really  
linear. It could be, of course, but given the nature of the  
operations, I'd have thought it might be a bit less. Certainly the  
encryption wouldn't scale linearly, of course.


> That factor scales with the number of contacts on a roster, which  
> is linear,
> which is incredibly bad for something that can be accomplished with  
> O(1)
> complexity.
> 
> 
Well, that's the issue, you're not accomplishing the same result.

Even if you were, it's important to review what those O() things  
mean, because they can be a little deceptive.

You're suggesting the proposal is O(1), which is "Amortized Constant  
Time", or:

C = k

Which isn't really the case.

O(n) is what you say we currently use - that's:

C' = k'.n

I'll show later that your proposed solution is *also* O(n), at least  
considered as a whole.

Also getting a brief mention later on is O(log(n)), as performed by  
binary search trees:

C'' = k''.log(n)

Important to note is that C, C', and C'' depend on both quantity and  
the various constants - red-black trees, while O(log(n)), have quite  
a high k'', typically, and so are often avoided in favour of simpler  
linear algorithms which are faster for small values of n.


> If the problem is synchronization of subscription states, well,  
> then fix
> the problem with synchronization of subscription states.
> 
> 
Or avoid it, which we're doing perfectly well right now.


> > sender doesn't want you to, which is substantially worse, and  
> without
> > any bad actor involved. (I could be wrong here, please check  
> this.)
> 
> So we argue to "optimize" the protocol for this case? "Hmm, the  
> other
> side might get information I didn't want to tell him, well, lets  
> send it
> 10 times instead of once. I guess that will 'fix' the problem."
> 
> 
I'm certainly arguing that there's insufficient reason to break the  
protocol to save a few stanzas.


> I understand what you mean: Going from 10 to 1 message will indeed
> be a privacy problem in case of lost 'unsubscribed' stanzas. But the
> solution is to ask why the unsubscribed stanza was lost. XEP-0198  
> will
> address at least parts of this problem.
> 
> 
It will reduce, but not eliminate, a problem which we do not  
currently suffer as much from as we could.

> Oh yay, let's burn some more CPU cycles, energy is sooo cheap.  
> Everytime you
> send out 10 instead of 1 presence stanzas an additional amount of  
> warmth is added
> to the global warming.
> 
> 
You know XEP-0263 is a joke, right?


> Compression is a good optimization if you don't have anything else  
> to save
> anymore and really want to pay for the CPU time. But in this case,  
> wouldn't be
> preventing the redundancy in the first place be more beneficial in  
> the overall
> performance?
> 
> 
Yes. But not at the cost of making the protocol worse. By the way,  
the "compression costs" argument can be somewhat misleading in some  
cases - not this particular case - but in general, with TLS on the  
stream, compression will reduce the cost. Besides, deflate is really  
very cheap in any case.

> Everytime you compress a redundant presence stanza a tree dies.  
> Please
> think of the trees.

I really worry that this entire note is actually a excellent example  
of sarcasm, based on this, but I'll take it seriously as the safer  
option.

I could probably extract the actual energy involved in processing a  
presence stanza, but we're talking in terms of nanoseconds of CPU  
time - this doesn't, obviously, cost a tree, but over time it will  
add up.

Let's review what happens currently, assuming an initiating contact  
with n availableremote contacts across d domains, each of which has y  
resources connected - y being different in each instance obviously:

1) Client sends home server a broadcast presence. Cost E1, O(1).

2) Home server, which (almost certainly) has client's roster  
in-memory, iterates through and emits one presence stanza per remote  
subscribed contact known to be available. Cost E2, O(n). (Iterating  
through a list of known available contacts).

3) Home server encodes and transmits N stanzas, remote server decodes  
and transmits N stanzas. Cost E3, O(n). (One stanza per contact -  
arguably this is O(d) to open the stream, and O(y) to send the  
stanzas - you pick).

4) Remote server receives one or more fully-addressed stanzas, and  
broadcasts them to all resources. Cost E4, O(y). (Iterating through a  
list of resources of the recipient).

This gives E, as O(n) + O(y), a linear complexity algorithm.

You want to replace 2-4 with:

2') Home server collates roster by remote domain and emits one  
presence stanza per remote domain which has a subscribed contacts  
known to be available. This is, I'll accept, likely to be close to  
the energy cost of 2, although due to the fluctuating nature of  the  
final clause that collation has to be done each time, so it'll be a  
little above. Cost E2' is, therefore > E2. O(n) + O(d) - I have a  
feeling this can be reduced to O(n).

3') encode/transmit/decode 1 stanza per remote domain. This is  
certainly an energy/cpu/cost saving compared to the 3 above, no  
argument from me here. Cost E3' is < E3. O(d) (One stanza per domain.  
Still linear, of course).

4') Lookup sender against all rosters in the system, and detirmine  
which of the resulting potential recipients is online and available  
to the sender. It seems reasonable that it would be possible to limit  
the lookup to only contacts who are online and available - assuming  
we ignore privacy lists - but you're still adding a lookup and the  
associating lookup mechanics (like a hash table or something) which  
must be maintained in-memory. I strongly suspect that this much, much  
more costly to use, build, and maintain than 4 above, hence E4' >>  
E4. I believe this to be possible to implement as O(log(y)), but I  
also suspect it's overwhemlingly more likely that it's O(y) (as  
derived from a reverse roster lookup O(log(y)) combined with a  
resource-broadcast lookup O(y)).

This give E' as O(n) + O(d) + O(y), a linear compexity algorithm.  
Poof goes your argument above about linear complexity versus constant  
amortized time.

I can't see (E3' - E3) < ((E4' - E4) + (E2' - E2)) as being at all  
likely, so I continue to maintain that this is a false optimization.  
(I also continue to maintain that this is an arse-clenchingly more  
complex solution to the problem of getting presence from one contact  
to another, but I hope nobody's arguing against me, there).

Now, as always, I encourage you to change my mind with suitably  
backed factual evidence.

Oh, and I would add that this does, of course, change dramatically if  
we introduce a non-meshed routing architecture between servers -  
since that reassociates responsibility anyway, it's not a problem  
there. (FWIW, I would note that this already occurs between client  
and home server).

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Mon Apr  6 07:26:17 2009
From: dave at cridland.net (Dave Cridland)
Date: Mon, 06 Apr 2009 13:26:17 +0100
Subject: [Standards] Presence distribution
In-Reply-To: <49D28442.90909@goodadvice.pages.de>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>
	<49D21F25.8050009@stpeter.im>
	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>
	<13438.1238517419.538659@puncture> <49D28442.90909@goodadvice.pages.de>
Message-ID: <19257.1239020777.714589@puncture>

On Tue Mar 31 21:59:46 2009, Philipp Hancke wrote:
> Dave Cridland wrote:
> [snip]
>> But then there's responsibility - right now, it's inarguably your  
>> local server which enforces who gets your presence,
> 
> From a different point of view:
> It is your server which controls that I get presence from you.
> This makes it necessary for my server to check that you are  
> authorized
> to send me presence - per stanza.
> 
> Offloading the distribution to my server enables my server to  
> determine
> if I am really interested in your presence - once per session for  
> any
> mcast stanza. And if you want to spam me, you have make my server
> believe that I am interested in you.
> 
> 
I think directed presence breaks your assumption, there. Your client  
has to decide whether an unsolicited presence is worth displaying or  
not, surely?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Mon Apr  6 08:22:01 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 07:22:01 -0600
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <19257.1239014992.504500@puncture>
References: <30276.1226523901.569488@peirce.dave.cridland.net>	<49D8F613.1010903@stpeter.im>
	<19257.1239014992.504500@puncture>
Message-ID: <49DA01F9.70407@stpeter.im>

On 4/6/09 4:49 AM, Dave Cridland wrote:
> On Sun Apr  5 19:18:59 2009, Peter Saint-Andre wrote:
>> I'm open to doing this if someone wants to help with the CSS/XSL.
>>
>>
> Didn't I send you some already?

Ah, well you sent some RGB codes. I need a way to place a vertical
stripe down the side of the page (100% of the height), which seems to be
rather difficult in CSS (although possibly it will be part of CSS3).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/78f7af75/attachment-0001.bin 

From zarevucky.jiri at gmail.com  Mon Apr  6 08:28:16 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Mon, 6 Apr 2009 15:28:16 +0200
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <49DA01F9.70407@stpeter.im>
References: <30276.1226523901.569488@peirce.dave.cridland.net>
	<49D8F613.1010903@stpeter.im> <19257.1239014992.504500@puncture>
	<49DA01F9.70407@stpeter.im>
Message-ID: <e962983d0904060628w4f7e9dabud84865d1905aab97@mail.gmail.com>

2009/4/6 Peter Saint-Andre <stpeter at stpeter.im>:
>
> Ah, well you sent some RGB codes. I need a way to place a vertical
> stripe down the side of the page (100% of the height), which seems to be
> rather difficult in CSS (although possibly it will be part of CSS3).
>
> Peter
>

This should be quite easy, unless you want it to have a vertical text included.
The simplest way I can think about is adding a background image. :)

From machekku at uaznia.net  Mon Apr  6 08:32:04 2009
From: machekku at uaznia.net (Maciek Niedzielski)
Date: Mon, 06 Apr 2009 15:32:04 +0200
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <49DA01F9.70407@stpeter.im>
References: <30276.1226523901.569488@peirce.dave.cridland.net>	<49D8F613.1010903@stpeter.im>	<19257.1239014992.504500@puncture>
	<49DA01F9.70407@stpeter.im>
Message-ID: <49DA0454.6010909@uaznia.net>

Peter Saint-Andre wrote:
> On 4/6/09 4:49 AM, Dave Cridland wrote:
>> On Sun Apr  5 19:18:59 2009, Peter Saint-Andre wrote:
>>> I'm open to doing this if someone wants to help with the CSS/XSL.
>> Didn't I send you some already?
> Ah, well you sent some RGB codes. I need a way to place a vertical
> stripe down the side of the page (100% of the height), which seems to be
> rather difficult in CSS (although possibly it will be part of CSS3).
You could do it this way: http://www.w3.org/TR/CSS21/
(no, don't read the text - just see how they did this "W3C Candidate 
Recommendation" blue bar)

-- 
Maciek
  xmpp:machekku at uaznia.net

From tmarkmann at googlemail.com  Mon Apr  6 09:17:27 2009
From: tmarkmann at googlemail.com (Tobias Markmann)
Date: Mon, 6 Apr 2009 16:17:27 +0200
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <49DA01F9.70407@stpeter.im>
References: <30276.1226523901.569488@peirce.dave.cridland.net>
	<49D8F613.1010903@stpeter.im> <19257.1239014992.504500@puncture>
	<49DA01F9.70407@stpeter.im>
Message-ID: <5cfc0a8e0904060717w1e0a9fb0k638f5a35d4d39a5d@mail.gmail.com>

On Mon, Apr 6, 2009 at 3:22 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:

> On 4/6/09 4:49 AM, Dave Cridland wrote:
> > On Sun Apr  5 19:18:59 2009, Peter Saint-Andre wrote:
> >> I'm open to doing this if someone wants to help with the CSS/XSL.
> >>
> >>
> > Didn't I send you some already?
>
> Ah, well you sent some RGB codes. I need a way to place a vertical
> stripe down the side of the page (100% of the height), which seems to be
> rather difficult in CSS (although possibly it will be part of CSS3).
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
Well, he did send you a diff which you can use to patch the files used to
generate the HTML XEP files. Look at Dave's first mail, he attached it.

Cheers,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090406/8abdf979/attachment.htm 

From stpeter at stpeter.im  Mon Apr  6 09:28:37 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 08:28:37 -0600
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <5cfc0a8e0904060717w1e0a9fb0k638f5a35d4d39a5d@mail.gmail.com>
References: <30276.1226523901.569488@peirce.dave.cridland.net>	<49D8F613.1010903@stpeter.im>
	<19257.1239014992.504500@puncture>	<49DA01F9.70407@stpeter.im>
	<5cfc0a8e0904060717w1e0a9fb0k638f5a35d4d39a5d@mail.gmail.com>
Message-ID: <49DA1195.20401@stpeter.im>

On 4/6/09 8:17 AM, Tobias Markmann wrote:
> On Mon, Apr 6, 2009 at 3:22 PM, Peter Saint-Andre <stpeter at stpeter.im
> <mailto:stpeter at stpeter.im>> wrote:
> 
>     On 4/6/09 4:49 AM, Dave Cridland wrote:
>     > On Sun Apr  5 19:18:59 2009, Peter Saint-Andre wrote:
>     >> I'm open to doing this if someone wants to help with the CSS/XSL.
>     >>
>     >>
>     > Didn't I send you some already?
> 
>     Ah, well you sent some RGB codes. I need a way to place a vertical
>     stripe down the side of the page (100% of the height), which seems to be
>     rather difficult in CSS (although possibly it will be part of CSS3).
> 
>     Peter
> 
>     --
>     Peter Saint-Andre
>     https://stpeter.im/
> 
> Well, he did send you a diff which you can use to patch the files used
> to generate the HTML XEP files. Look at Dave's first mail, he attached it. 

You're right, I'll check it over.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/7dbd5693/attachment.bin 

From stpeter at stpeter.im  Mon Apr  6 09:29:20 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 08:29:20 -0600
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <e962983d0904060628w4f7e9dabud84865d1905aab97@mail.gmail.com>
References: <30276.1226523901.569488@peirce.dave.cridland.net>	<49D8F613.1010903@stpeter.im>
	<19257.1239014992.504500@puncture>	<49DA01F9.70407@stpeter.im>
	<e962983d0904060628w4f7e9dabud84865d1905aab97@mail.gmail.com>
Message-ID: <49DA11C0.2000704@stpeter.im>

On 4/6/09 7:28 AM, Ji?? Z?rev?ck? wrote:
> 2009/4/6 Peter Saint-Andre <stpeter at stpeter.im>:
>> Ah, well you sent some RGB codes. I need a way to place a vertical
>> stripe down the side of the page (100% of the height), which seems to be
>> rather difficult in CSS (although possibly it will be part of CSS3).
>>
>> Peter
>>
> 
> This should be quite easy, unless you want it to have a vertical text included.
> The simplest way I can think about is adding a background image. :)

I was hoping to avoid image loads for our spec files. But I'll look into
it. I think we've wasted enough list bandwidth on this now. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/c8eb4a02/attachment-0001.bin 

From zarevucky.jiri at gmail.com  Mon Apr  6 11:01:30 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Mon, 6 Apr 2009 18:01:30 +0200
Subject: [Standards] XEPs in Pretty Colours.
In-Reply-To: <49DA11C0.2000704@stpeter.im>
References: <30276.1226523901.569488@peirce.dave.cridland.net>
	<49D8F613.1010903@stpeter.im> <19257.1239014992.504500@puncture>
	<49DA01F9.70407@stpeter.im>
	<e962983d0904060628w4f7e9dabud84865d1905aab97@mail.gmail.com>
	<49DA11C0.2000704@stpeter.im>
Message-ID: <e962983d0904060901p33bd16beob5d7be931b304c8f@mail.gmail.com>

2009/4/6 Peter Saint-Andre <stpeter at stpeter.im>:
> On 4/6/09 7:28 AM, Ji?? Z?rev?ck? wrote:
>>
>> This should be quite easy, unless you want it to have a vertical text included.
>> The simplest way I can think about is adding a background image. :)
>
> I was hoping to avoid image loads for our spec files. But I'll look into
> it. I think we've wasted enough list bandwidth on this now. :)
>

If you want just a vertical stripe over the whole page, a single pixel
line is all it takes. That should fit within a few hundred bytes,
including the http request. :)

If you decide an explanatory text is to be included in it (like on the
W3C specs), the image is probably the only possibility anyway.

From waqas20 at gmail.com  Mon Apr  6 11:21:18 2009
From: waqas20 at gmail.com (Waqas Hussain)
Date: Mon, 6 Apr 2009 21:21:18 +0500
Subject: [Standards] Presence distribution
In-Reply-To: <19257.1239020384.317796@puncture>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>
	<49D21F25.8050009@stpeter.im>
	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>
	<13438.1238517419.538659@puncture> <20090402005435.GA31322@elmex2>
	<19257.1239020384.317796@puncture>
Message-ID: <7fc4fa880904060921h51a407a5l463decc962f8522e@mail.gmail.com>

What follows might just be nonsense, but I'm still speaking out. For
the trees, you understand.

On Mon, Apr 6, 2009 at 5:19 PM, Dave Cridland <dave at cridland.net> wrote:
[snip]
> You want to replace 2-4 with:
>
> 2') Home server collates roster by remote domain and emits one presence
> stanza per remote domain which has a subscribed contacts known to be
> available. This is, I'll accept, likely to be close to the energy cost of 2,
> although due to the fluctuating nature of ?the final clause that collation
> has to be done each time, so it'll be a little above. Cost E2' is, therefore > E2.
> O(n) + O(d) - I have a feeling this can be reduced to O(n).
>

Keep a list of domains (affectively a cache) to send to along with the
roster object (possibly even storing it on disk along with the
roster), and E2' becomes less than E2.

> 3') encode/transmit/decode 1 stanza per remote domain. This is certainly an
> energy/cpu/cost saving compared to the 3 above, no argument from me here.
> Cost E3' is < E3. O(d) (One stanza per domain. Still linear, of course).
>
> 4') Lookup sender against all rosters in the system, and detirmine which of
> the resulting potential recipients is online and available to the sender. It
> seems reasonable that it would be possible to limit the lookup to only
> contacts who are online and available - assuming we ignore privacy lists -
> but you're still adding a lookup and the associating lookup mechanics (like
> a hash table or something) which must be maintained in-memory. I strongly
> suspect that this much, much more costly to use, build, and maintain than 4
> above, hence E4' >> E4. I believe this to be possible to implement as
> O(log(y)), but I also suspect it's overwhemlingly more likely that it's O(y)
> (as derived from a reverse roster lookup O(log(y)) combined with a
> resource-broadcast lookup O(y)).
>
I don't think E4' >> E4. I think E4' < E4. "you're still adding a
lookup" you say. No, this replaces y hashtable lookups with one
lookup. Think about it. While yes, a hashtable would indeed need to be
maintained, the resource usage wouldn't be significant. The additional
memory cost would be an order of magnitude less than what in-memory
rosters already use. The hashtable update/remove cost would only apply
when local resources become unavailable/available, which tends to
happen only once for most c2s sessions. Presence broadcast on the
other hand tends to happen more than once (at least that's what it
looks like for my contacts). Simply stated, writes would be (much?)
rarer than reads, and read cost would be reduced by a reverse
hashtable (think of database indexes).

> This give E' as O(n) + O(d) + O(y), a linear compexity algorithm. Poof goes
> your argument above about linear complexity versus constant amortized time.
>
The Big-O notation is about complexity, not cost. While two different
algorithms may both have the same complexity, that does not imply that
the resource cost is the same, or even close. Several optimizations
reduce cost, but not complexity (making certain boolean checks
unnecessary, for example).

And since the topic is trees, the resources being consumed by the
intermediate nodes (routers, etc), should be added to the equation.

> I can't see (E3' - E3) < ((E4' - E4) + (E2' - E2)) as being at all likely,
> so I continue to maintain that this is a false optimization. (I also
> continue to maintain that this is an arse-clenchingly more complex solution
> to the problem of getting presence from one contact to another, but I hope
> nobody's arguing against me, there).
>
> Now, as always, I encourage you to change my mind with suitably backed
> factual evidence.
>
I suspect the CPU cost would be lower with this proposal. Saved
bandwidth was more appealing to me than saved CPU time, but the
missing unsubscribed issue makes this optimization invalid, so no
point in attempting tests.

> Oh, and I would add that this does, of course, change dramatically if we
> introduce a non-meshed routing architecture between servers - since that
> reassociates responsibility anyway, it's not a problem there. (FWIW, I would
> note that this already occurs between client and home server).
>
> Dave.
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
> ?- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> ?- http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>

--
Waqas Hussain

From fippo at goodadvice.pages.de  Mon Apr  6 11:54:16 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Mon, 06 Apr 2009 18:54:16 +0200
Subject: [Standards] Presence distribution
In-Reply-To: <19257.1239020384.317796@puncture>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>	<49D21F25.8050009@stpeter.im>	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>	<13438.1238517419.538659@puncture>
	<20090402005435.GA31322@elmex2> <19257.1239020384.317796@puncture>
Message-ID: <49DA33B8.8090301@goodadvice.pages.de>

Dave Cridland wrote:
[snip]
>> > sender doesn't want you to, which is substantially worse, and without
>> > any bad actor involved. (I could be wrong here, please check this.)
>>
>> So we argue to "optimize" the protocol for this case? "Hmm, the other
>> side might get information I didn't want to tell him, well, lets send it
>> 10 times instead of once. I guess that will 'fix' the problem."
>>
>>
> I'm certainly arguing that there's insufficient reason to break the 
> protocol to save a few stanzas.

Ok. Let's wait for rogue s2s floodbots to bring down servers because
currently there is no effective s2s (or c2s) flood control.

Actually, the current model enables a single client to bring down
a server by making the server broadcast large presence stanzas at
a high rate. Simplistic bandwidth control mechanisms such as "karma"
account traffic per socket, and do not throttle the client when it
generates excessive amounts of s2s traffic.

This is still possible with view sharing, but the attack scales
with d instead of n.

> Yes. But not at the cost of making the protocol worse. By the way, the 

It is not "worse", just different.

> Let's review what happens currently, assuming an initiating contact with 
> n availableremote contacts across d domains, each of which has y 
> resources connected - y being different in each instance obviously:

"available remote contacts" is those bis optimizations?
Actually, were those discussed before they were introduced?
What is their impact on presence reliability?

> 1) Client sends home server a broadcast presence. Cost E1, O(1).

Why not shift the responsibility for distribution to the client?
This would make E1=O(n) and E2=O(1) (simple message routing).
Afaics, your argument applies for that as well.

> 2) Home server, which (almost certainly) has client's roster in-memory, 
> iterates through and emits one presence stanza per remote subscribed 
> contact known to be available. Cost E2, O(n). (Iterating through a list 
> of known available contacts).

Actually, why don't you send the presence stanza to each connected
resource of each available contact here - iterating through a list of
known avaible contact resources)?

> 3) Home server encodes and transmits N stanzas, remote server decodes 
> and transmits N stanzas. Cost E3, O(n). (One stanza per contact - 
> arguably this is O(d) to open the stream, and O(y) to send the stanzas - 
> you pick).

O(y) should be O(n) here?

> 4) Remote server receives one or more fully-addressed stanzas, and 
> broadcasts them to all resources. Cost E4, O(y). (Iterating through a 
> list of resources of the recipient).

This is done n times. And you are neglecting costs for privacy list
checks (I will call that O(p), different for each instance and
quite costly imo).
Hence E4 = O(n) + n*(O(p) + O(y))

> This gives E, as O(n) + O(y), a linear complexity algorithm.

O(n) + n*(O(p) + O(y)).

> You want to replace 2-4 with:
> 
> 2') Home server collates roster by remote domain and emits one presence 
> stanza per remote domain which has a subscribed contacts known to be 
> available. This is, I'll accept, likely to be close to the energy cost 
> of 2, although due to the fluctuating nature of  the final clause that 
> collation has to be done each time, so it'll be a little above. Cost E2' 
> is, therefore > E2. O(n) + O(d) - I have a feeling this can be reduced 
> to O(n).
> 
> 3') encode/transmit/decode 1 stanza per remote domain. This is certainly 
> an energy/cpu/cost saving compared to the 3 above, no argument from me 
> here. Cost E3' is < E3. O(d) (One stanza per domain. Still linear, of 
> course).

Linear with d. Assuming that people 'cluster', d << n is reasonable.

> 4') Lookup sender against all rosters in the system, and detirmine which 
> of the resulting potential recipients is online and available to the 
> sender. It seems reasonable that it would be possible to limit the 
> lookup to only contacts who are online and available - assuming we 
> ignore privacy lists - but you're still adding a lookup and the 

This depends on how you do the lookup imo.

> associating lookup mechanics (like a hash table or something) which must 
> be maintained in-memory. I strongly suspect that this much, much more 
> costly to use, build, and maintain than 4 above, hence E4' >> E4. I 

If you are neglecting privacy lists above certainly.

I think you can reduce this to E4' = n*O(y).

> believe this to be possible to implement as O(log(y)), but I also 
> suspect it's overwhemlingly more likely that it's O(y) (as derived from 
> a reverse roster lookup O(log(y)) combined with a resource-broadcast 
> lookup O(y)).
> 
> This give E' as O(n) + O(d) + O(y), a linear compexity algorithm. Poof 
> goes your argument above about linear complexity versus constant 
> amortized time.
> 
> I can't see (E3' - E3) < ((E4' - E4) + (E2' - E2)) as being at all 
> likely, so I continue to maintain that this is a false optimization. 

I disagree. But at least your argument is technically founded and better
than what I have heard from the council in 2006 (and I had to gather
that from the chatroom).

I care about effective flood control mechanisms. This is about moving
cost where they are affordable.

> (I also continue to maintain that this is an arse-clenchingly more complex 
> solution to the problem of getting presence from one contact to another, 
> but I hope nobody's arguing against me, there).

It is a different solution. One that has been used for years on IRC.

p

p.s.: I still want a review for that 220-rewrite from you.

From fippo at goodadvice.pages.de  Mon Apr  6 11:58:49 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Mon, 06 Apr 2009 18:58:49 +0200
Subject: [Standards] Presence distribution
In-Reply-To: <7fc4fa880904060921h51a407a5l463decc962f8522e@mail.gmail.com>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>	<49D21F25.8050009@stpeter.im>	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>	<13438.1238517419.538659@puncture>
	<20090402005435.GA31322@elmex2>	<19257.1239020384.317796@puncture>
	<7fc4fa880904060921h51a407a5l463decc962f8522e@mail.gmail.com>
Message-ID: <49DA34C9.6070607@goodadvice.pages.de>

Waqas Hussain wrote:
> I suspect the CPU cost would be lower with this proposal. Saved
> bandwidth was more appealing to me than saved CPU time, but the
> missing unsubscribed issue makes this optimization invalid, so no
> point in attempting tests.

hashes or counters make it possible to check for missing unsubscribed.
I've already proposed how to modify repeaters so that they maintain the
sleek, uncomplicated protocol and additionally check consistence through
hashes. But I guess in this community one has to formally submit
such a proposal to editor at .

From dave at cridland.net  Mon Apr  6 12:40:37 2009
From: dave at cridland.net (Dave Cridland)
Date: Mon, 06 Apr 2009 18:40:37 +0100
Subject: [Standards] Presence distribution
In-Reply-To: <49DA33B8.8090301@goodadvice.pages.de>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>
	<49D21F25.8050009@stpeter.im>
	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>
	<13438.1238517419.538659@puncture> <20090402005435.GA31322@elmex2>
	<19257.1239020384.317796@puncture>
	<49DA33B8.8090301@goodadvice.pages.de>
Message-ID: <19257.1239039637.273069@puncture>

On Mon Apr  6 17:54:16 2009, Philipp Hancke wrote:
> Actually, the current model enables a single client to bring down
> a server by making the server broadcast large presence stanzas at
> a high rate. Simplistic bandwidth control mechanisms such as "karma"
> account traffic per socket, and do not throttle the client when it
> generates excessive amounts of s2s traffic.
> 
> 
How does the client force the subscription?

>> Yes. But not at the cost of making the protocol worse. By the way,  
>> the 
> 
> It is not "worse", just different.

No, it is worse, the failure case of the missing unsubscribed is a  
privacy leak.

>> Let's review what happens currently, assuming an initiating  
>> contact with n availableremote contacts across d domains, each of  
>> which has y resources connected - y being different in each  
>> instance obviously:
> 
> "available remote contacts" is those bis optimizations?
> Actually, were those discussed before they were introduced?
> What is their impact on presence reliability?
> 
> 
Yes, and they're not mandated.


>> 1) Client sends home server a broadcast presence. Cost E1, O(1).
> 
> Why not shift the responsibility for distribution to the client?
> This would make E1=O(n) and E2=O(1) (simple message routing).
> Afaics, your argument applies for that as well.
> 
> 
Ah, but the server has responsibility anyway, so it's a reasonable  
optimization there.


>> 2) Home server, which (almost certainly) has client's roster  
>> in-memory, iterates through and emits one presence stanza per  
>> remote subscribed contact known to be available. Cost E2, O(n).  
>> (Iterating through a list of known available contacts).
> 
> Actually, why don't you send the presence stanza to each connected
> resource of each available contact here - iterating through a list  
> of
> known avaible contact resources)?
> 
> 
It's not that server's responsibility to maintain that definitive  
list, though.

>> 3) Home server encodes and transmits N stanzas, remote server  
>> decodes and transmits N stanzas. Cost E3, O(n). (One stanza per  
>> contact - arguably this is O(d) to open the stream, and O(y) to  
>> send the stanzas - you pick).
> 
> O(y) should be O(n) here?
> 
> 
No, it's d*O(y), but that's equivalent to O(y). I don't think it  
makes a huge difference whether it's O(y) + O(d) or O(n), though.


>> 4) Remote server receives one or more fully-addressed stanzas, and  
>> broadcasts them to all resources. Cost E4, O(y). (Iterating  
>> through a list of resources of the recipient).
> 
> This is done n times. And you are neglecting costs for privacy list
> checks (I will call that O(p), different for each instance and
> quite costly imo).
> Hence E4 = O(n) + n*(O(p) + O(y))
> 
> 
Well, the 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 collate a per-domain list of contacts. I've not  
considered this, because of the risks of such lists being lost, or  
out of sync themselves, and the problems that having arbitrary  
servers able to command resources on your server.


>> This gives E, as O(n) + O(y), a linear complexity algorithm.
> 
> O(n) + n*(O(p) + O(y)).
> 
> 
That's O(n + np + ny), I think.


>> You want to replace 2-4 with:
>> 
>> 2') Home server collates roster by remote domain and emits one  
>> presence stanza per remote domain which has a subscribed contacts  
>> known to be available. This is, I'll accept, likely to be close to  
>> the energy cost of 2, although due to the fluctuating nature of   
>> the final clause that collation has to be done each time, so it'll  
>> be a little above. Cost E2' is, therefore > E2. O(n) + O(d) - I  
>> have a feeling this can be reduced to O(n).
>> 
>> 3') encode/transmit/decode 1 stanza per remote domain. This is  
>> certainly an energy/cpu/cost saving compared to the 3 above, no  
>> argument from me here. Cost E3' is < E3. O(d) (One stanza per  
>> domain. Still linear, of course).
> 
> Linear with d. Assuming that people 'cluster', d << n is reasonable.
> 
> 
Sure, but I'm astonishingly unconvinced that the O(y) term in E3 is  
significant - I suspect the maintainence of the domain XMLstreams is  
by far the bigger cost, here - in fact, I personally think it's  
entirely reasonable to suggest that for all practical purposes, E3 ==  
E3' == O(d), although in practise E3' will be slightly smaller, and  
in the case where y is particularly big, that difference will of  
course become significant.

But for the vast majority of cases, y == 1 - in my roster, it's a  
maximum of 12 (for jabber.org), the next highest is 6 or so (for  
gmail.com), and the remaining levels or 2 or 1, across quite a few  
domains. I don't think under these cases that - unless the constant  
involved is massive - O(y) is going to be a substantial factor.


>> 4') Lookup sender against all rosters in the system, and detirmine  
>> which of the resulting potential recipients is online and  
>> available to the sender. It seems reasonable that it would be  
>> possible to limit the lookup to only contacts who are online and  
>> available - assuming we ignore privacy lists - but you're still  
>> adding a lookup and the 
> 
> This depends on how you do the lookup imo.
> 
> 
Yes, Waqas argues that it might be replacement rather than addition.


>> associating lookup mechanics (like a hash table or something)  
>> which must be maintained in-memory. I strongly suspect that this  
>> much, much more costly to use, build, and maintain than 4 above,  
>> hence E4' >> E4. I 
> 
> If you are neglecting privacy lists above certainly.
> 
> I think you can reduce this to E4' = n*O(y).
> 
> 
n cannot possibly occur in this - n is a figure local to the  
initiating server. It might happen d times, though, on different  
servers.


>> believe this to be possible to implement as O(log(y)), but I also  
>> suspect it's overwhemlingly more likely that it's O(y) (as derived  
>> from a reverse roster lookup O(log(y)) combined with a  
>> resource-broadcast lookup O(y)).
>> 
>> This give E' as O(n) + O(d) + O(y), a linear compexity algorithm.  
>> Poof goes your argument above about linear complexity versus  
>> constant amortized time.
>> 
>> I can't see (E3' - E3) < ((E4' - E4) + (E2' - E2)) as being at all  
>> likely, so I continue to maintain that this is a false  
>> optimization. 
> 
> I disagree. But at least your argument is technically founded and  
> better
> than what I have heard from the council in 2006 (and I had to gather
> that from the chatroom).
> 
> 
Waqas points out some potential flaws - I'm still not convinced that  
it represents a cost-saving for either end, but the difference might  
well be smaller than I thought. In particular, he suggests that E4  
might be implemented as a single multivalued hashtable, thus reducing  
that lookup to O(1).

We had a very interesting conversation about the relative costs of  
string internalization and all sorts.


> I care about effective flood control mechanisms. This is about  
> moving
> cost where they are affordable.
> 
>> (I also continue to maintain that this is an arse-clenchingly more  
>> complex solution to the problem of getting presence from one  
>> contact to another, but I hope nobody's arguing against me, there).
> 
> It is a different solution. One that has been used for years on IRC.

IRC has a different structure, and uniform view throughout the  
network - indeed, one server is specifically designed to be  
indistinguishable from any other. That's not the case in XMPP, and  
means different approaches and considerations. IRC behaves like a  
single XMPP cluster, in that respect, where all these optimizations  
are entirely possible.

> p.s.: I still want a review for that 220-rewrite from you.

Pester me next week?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From gnauck at ag-software.de  Mon Apr  6 14:10:58 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Mon, 06 Apr 2009 21:10:58 +0200
Subject: [Standards] XSF membership application period Q2/2009
Message-ID: <49DA53C2.90006@ag-software.de>

The XMPP Standards Foundation (XSF) is currently holding its quarterly 
membership application period:
http://wiki.xmpp.org/web/Membership_Applications_April_2009

Applications are encouraged from developers and others who are actively 
involved in the Jabber/XMPP community. To apply, create a page about 
yourself on the wiki.

If you don't have a wiki account, send your name, preferred nickname and
email address to me or one of the other Sysops:
http://wiki.xmpp.org/index.php/Sysops

The application period ends on 22th April 2009 23:59h UTC, so apply today!

Regards,
Alex
--
Alexander Gnauck
xmpp:gnauck at jabber.org

From fippo at goodadvice.pages.de  Mon Apr  6 15:05:31 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Mon, 06 Apr 2009 22:05:31 +0200
Subject: [Standards] Presence distribution
In-Reply-To: <19257.1239039637.273069@puncture>
References: <938857BD-1290-4957-B659-78E03CC5F9DD@simplicidade.org>	<49D21F25.8050009@stpeter.im>	<344C5074-B217-4AF3-9A0A-1E473872EF18@simplicidade.org>	<13438.1238517419.538659@puncture>
	<20090402005435.GA31322@elmex2>	<19257.1239020384.317796@puncture>	<49DA33B8.8090301@goodadvice.pages.de>
	<19257.1239039637.273069@puncture>
Message-ID: <49DA608B.9040003@goodadvice.pages.de>

Dave Cridland wrote:
> On Mon Apr  6 17:54:16 2009, Philipp Hancke wrote:
>> Actually, the current model enables a single client to bring down
>> a server by making the server broadcast large presence stanzas at
>> a high rate. Simplistic bandwidth control mechanisms such as "karma"
>> account traffic per socket, and do not throttle the client when it
>> generates excessive amounts of s2s traffic.
>>
>>
> How does the client force the subscription?

It does not need to force them. It uses the usual subscription process
with online remote clients. Once the subscription is established, the
remote clients can go offline (or use a weird privacy list to block all
incoming presence). The bis optimizations make that more costly for the
attacker btw.

>>> Yes. But not at the cost of making the protocol worse. By the way, the
>>
>> It is not "worse", just different.
> 
> No, it is worse, the failure case of the missing unsubscribed is a 
> privacy leak.

If unsubscribed is missed - in a detectable way - why would you not
resend that once the connectivity for the responsible domain is
reestablished? (there are some (implementations) bugs related to
detecting that, but I will post that to another thread)

version 0.1 of stanza repeaters (does anyone still have a digital copy
btw) was using hashes to workaround this.

>>> Let's review what happens currently, assuming an initiating contact 
>>> with n availableremote contacts across d domains, each of which has y 
>>> resources connected - y being different in each instance obviously:
>>
>> "available remote contacts" is those bis optimizations?
>> Actually, were those discussed before they were introduced?
>> What is their impact on presence reliability?
>>
>>
> Yes, and they're not mandated.
> 
> 
>>> 1) Client sends home server a broadcast presence. Cost E1, O(1).
>>
>> Why not shift the responsibility for distribution to the client?
>> This would make E1=O(n) and E2=O(1) (simple message routing).
>> Afaics, your argument applies for that as well.
>>
>>
> Ah, but the server has responsibility anyway, so it's a reasonable 
> optimization there.

I would argue that the remote server has a similar responsibility :-)

>>> 2) Home server, which (almost certainly) has client's roster 
>>> in-memory, iterates through and emits one presence stanza per remote 
>>> subscribed contact known to be available. Cost E2, O(n). (Iterating 
>>> through a list of known available contacts).
>>
>> Actually, why don't you send the presence stanza to each connected
>> resource of each available contact here - iterating through a list of
>> known avaible contact resources)?
>>
>>
> It's not that server's responsibility to maintain that definitive list, 
> though.

Sure. It means that a part of the distribution load is already done on
the remote server. The privacy considerations are less tricky of course.

>>> 3) Home server encodes and transmits N stanzas, remote server decodes 
>>> and transmits N stanzas. Cost E3, O(n). (One stanza per contact - 
>>> arguably this is O(d) to open the stream, and O(y) to send the 
>>> stanzas - you pick).
>>
>> O(y) should be O(n) here?
>>
>>
> No, it's d*O(y), but that's equivalent to O(y). I don't think it makes a 
> huge difference whether it's O(y) + O(d) or O(n), though.

Ah. I probably mis-read your y as 'each remote contact has y resources
(clients) connected' - which is how you are using it in E4.
What you mean here is not y, but the number of remote contacts in
each domain - n/d?

>>> 4) Remote server receives one or more fully-addressed stanzas, and 
>>> broadcasts them to all resources. Cost E4, O(y). (Iterating through a 
>>> list of resources of the recipient).
>>
>> This is done n times. And you are neglecting costs for privacy list
>> checks (I will call that O(p), different for each instance and
>> quite costly imo).
>> Hence E4 = O(n) + n*(O(p) + O(y))
>>
>>
> Well, the 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, 

Well... I don't think a "reverse roster lookup" is really the way to
go. The SIMPLE people seem to use a rather explicit list, but I do not
see how they solve a potential desync.

> which means evaluating the privacy list locally n times, in order to 
> collate a per-domain list of contacts. I've not considered this, because 
> of the risks of such lists being lost, or out of sync themselves, and 

I am arguing that you do not need to do this per stanza in the mcast
case, but once per session.

> the problems that having arbitrary servers able to command resources on 
> your server.

They command those resources because users on your server want them to
do so. Allowing arbitrary servers to command your resources is not
a good idea (-:

>>> This gives E, as O(n) + O(y), a linear complexity algorithm.
>>
>> O(n) + n*(O(p) + O(y)).
>>
>>
> That's O(n + np + ny), I think.

ay.

>>> You want to replace 2-4 with:
>>>
>>> 2') Home server collates roster by remote domain and emits one 
>>> presence stanza per remote domain which has a subscribed contacts 
>>> known to be available. This is, I'll accept, likely to be close to 
>>> the energy cost of 2, although due to the fluctuating nature of  the 
>>> final clause that collation has to be done each time, so it'll be a 
>>> little above. Cost E2' is, therefore > E2. O(n) + O(d) - I have a 
>>> feeling this can be reduced to O(n).
>>>
>>> 3') encode/transmit/decode 1 stanza per remote domain. This is 
>>> certainly an energy/cpu/cost saving compared to the 3 above, no 
>>> argument from me here. Cost E3' is < E3. O(d) (One stanza per domain. 
>>> Still linear, of course).
>>
>> Linear with d. Assuming that people 'cluster', d << n is reasonable.
>>
>>
> Sure, but I'm astonishingly unconvinced that the O(y) term in E3 is 
> significant - I suspect the maintainence of the domain XMLstreams is by 
> far the bigger cost, here - in fact, I personally think it's entirely 
> reasonable to suggest that for all practical purposes, E3 == E3' == 
> O(d), although in practise E3' will be slightly smaller, and in the case 
> where y is particularly big, that difference will of course become 
> significant.
> 
> But for the vast majority of cases, y == 1 - in my roster, it's a 
> maximum of 12 (for jabber.org), the next highest is 6 or so (for 
> gmail.com), and the remaining levels or 2 or 1, across quite a few 

see above for y.

> domains. I don't think under these cases that - unless the constant 
> involved is massive - O(y) is going to be a substantial factor.

This O(whatever) is multiplied by number P of presence changes per hour.
3 is a reasonal assumption for normal usage, but I've seen 15-20 from
some contacts.

>>> 4') Lookup sender against all rosters in the system, and detirmine 
>>> which of the resulting potential recipients is online and available 
>>> to the sender. It seems reasonable that it would be possible to limit 
>>> the lookup to only contacts who are online and available - assuming 
>>> we ignore privacy lists - but you're still adding a lookup and the
>>
>> This depends on how you do the lookup imo.
>>
>>
> Yes, Waqas argues that it might be replacement rather than addition.
> 
> 
>>> associating lookup mechanics (like a hash table or something) which 
>>> must be maintained in-memory. I strongly suspect that this much, much 
>>> more costly to use, build, and maintain than 4 above, hence E4' >> E4. I
>>
>> If you are neglecting privacy lists above certainly.
>>
>> I think you can reduce this to E4' = n*O(y).
>>
>>
> n cannot possibly occur in this - n is a figure local to the initiating 
> server. It might happen d times, though, on different servers.

On each server it is approximately (n/d)*O(y), which sums up to n*O(y).

>>> believe this to be possible to implement as O(log(y)), but I also 
>>> suspect it's overwhemlingly more likely that it's O(y) (as derived 
>>> from a reverse roster lookup O(log(y)) combined with a 
>>> resource-broadcast lookup O(y)).
>>>
>>> This give E' as O(n) + O(d) + O(y), a linear compexity algorithm. 
>>> Poof goes your argument above about linear complexity versus constant 
>>> amortized time.
>>>
>>> I can't see (E3' - E3) < ((E4' - E4) + (E2' - E2)) as being at all 
>>> likely, so I continue to maintain that this is a false optimization.
>>
>> I disagree. But at least your argument is technically founded and better
>> than what I have heard from the council in 2006 (and I had to gather
>> that from the chatroom).
>>
>>
> Waqas points out some potential flaws - I'm still not convinced that it 
> represents a cost-saving for either end, but the difference might well 

Above you mention "the problems that having arbitrary servers able to
command resources on your server".
This is exactly what a remote entity makes your server do for every
stanza it sends to you. Your server has to consult the privacy list
for inbound stanzas to make a routing decision.

For your 12 contacts on jabber.org, this means that jabber.org
has to load 12 privacy lists and check those. Some of those
contacts might be offline and - if your server does not keep all user
data in memory all the time - the lookup might become even more
expensive.

I think waqas already describes the per-source hashtable necessary for
mcast. When distributing to users in that table, it is not necessary to
check individual privacy lists again, because they would not be
contained in the list if they were not interested in stanzas from that
particular source. Making sure that this table never contains users
which the source would not want to be there is the hard part.

> be smaller than I thought. In particular, he suggests that E4 might be 
> implemented as a single multivalued hashtable, thus reducing that lookup 
> to O(1). 

He argues for E4', not E4? We need better symbols obviously.

> We had a very interesting conversation about the relative costs of 
> string internalization and all sorts.

mh... we could extend that to discussing that optimization on
highly parallel vector computers (-:

>> I care about effective flood control mechanisms. This is about moving
>> cost where they are affordable.
>>
>>> (I also continue to maintain that this is an arse-clenchingly more 
>>> complex solution to the problem of getting presence from one contact 
>>> to another, but I hope nobody's arguing against me, there).
>>
>> It is a different solution. One that has been used for years on IRC.
> 
> IRC has a different structure, and uniform view throughout the network - 
> indeed, one server is specifically designed to be indistinguishable from 
> any other. That's not the case in XMPP, and means different approaches 

Which is a design flaw in IRC that WiZ himself exploited in killer.c

> and considerations. IRC behaves like a single XMPP cluster, in that 
> respect, where all these optimizations are entirely possible.

IRC uses those optimizations on a highly trusted network. XMPP does not
have this advantage. I still wonder why there are no flood bots in XMPP.

philipp

From editor at xmpp.org  Mon Apr  6 19:39:59 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Mon, 06 Apr 2009 19:39:59 -0500
Subject: [Standards] UPDATED: XEP-0264 (File Transfer Thumbnails)
Message-ID: <E1LqzM7-0003fS-00@apollo>

Version 0.2 of XEP-0264 (File Transfer Thumbnails) has been released.

Abstract: This specification defines a way for a client supply a preview image for a file transfer.

Changelog: Add paragraph in security section about protecting agains malicious thumbnail dimensions in offer. Fixed a typo. (ml)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0264.xml?%40diffMode=u&%40diffWrap=s&r1=2962&r2=3000&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0264.html


From stpeter at stpeter.im  Mon Apr  6 20:05:05 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 19:05:05 -0600
Subject: [Standards] UPDATED: XEP-0198 (Stream Management)
In-Reply-To: <2fd53c3a0903310507t40fc6a32k6d27a4292865329f@mail.gmail.com>
References: <E1LoSha-0003wC-00@apollo>
	<2fd53c3a0903310507t40fc6a32k6d27a4292865329f@mail.gmail.com>
Message-ID: <49DAA6C1.8010008@stpeter.im>

On 3/31/09 6:07 AM, Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 3:23 AM, XMPP Extensions Editor <editor at xmpp.org> wrote:
>> Version 0.7 of XEP-0198 (Stream Management) has been released.
>>
>> Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption.
>>
>> Changelog: Removed pings (use XEP-0199, whitespace pings, or TCP keepalives instead); removed section on throttling, since it is unworkable. (jjh/psa)
> 
> Imho some throttling "notification" is feasible only in one way: it's
> up to the  server send unsolicited throttling notifications when it
> knows it is throttling voluntary the stream (this means that if
> packets are stuck in a TCP buffer it's likely that even the server
> doesn't know that the stream is being throttled). Anything triggered
> by a stanza sent by the client is unworkable since that stanza cannot
> have higher priority and pass ahead the others.
> As optional I'd put a stanza for this purpose:
> 
> S: <t xmlns='urn:xmpp:sm:1' max="n"/>
> 
> It isn't perfect but it can work for most of the cases.

Agreed. But what is the purpose of max="n" here?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/37be0f66/attachment.bin 

From stpeter at stpeter.im  Mon Apr  6 21:28:25 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 20:28:25 -0600
Subject: [Standards] User *
In-Reply-To: <6e2f977f0903040743le921478i9e22c87b8b8cecb4@mail.gmail.com>
References: <6e2f977f0903040743le921478i9e22c87b8b8cecb4@mail.gmail.com>
Message-ID: <49DABA49.5060109@stpeter.im>

On 3/4/09 8:43 AM, Nicolas V?rit? wrote:
> Hi all,
> 
> I was wondering if these few PEP-based "User *" XEPs ideas were relevant:
> 
> * User Friends or Relationships
> Using XFN and/or FOAF to describe relationships
> http://gmpg.org/xfn/
> http://www.foaf-project.org/
> 
> * User Project
> Using DOAP
> http://trac.usefulinc.com/doap
> 
> * User Carrier
> Using DOAC or hResume
> http://ramonantonio.net/doac/
> http://microformats.org/wiki/hresume

How often does this information change? I think that the User* specs are
for things that change somewhat frequently (e.g., your mood might change
daily or more often, whereas the projects you work on might change
monthly or yearly).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/7aadd582/attachment.bin 

From registrar at xmpp.org  Mon Apr  6 22:33:10 2009
From: registrar at xmpp.org (XMPP Registrar)
Date: Mon, 06 Apr 2009 22:33:10 -0500
Subject: [Standards] UPDATED REGISTRY: FORM_TYPEs for Data Forms
Message-ID: <E1Lr23i-0005Fu-00@apollo>

The FORM_TYPEs for Data Forms registry has been updated.

Version: 0.9

Changelog: Added missing jabber:iq:register:cancel and jabber:iq:register:changepassword FORM_TYPEs from XEP-0077. (psa)

URL: http://www.xmpp.org/registrar/formtypes.html

From stpeter at stpeter.im  Mon Apr  6 23:01:09 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:01:09 -0600
Subject: [Standards] UPDATED: XEP-0255 (Location Query)
In-Reply-To: <B99A6B98-5C8C-4343-AEB8-48E20617A9BD@gmail.com>
References: <E1LiJvr-0005Wc-00@apollo>	<49BB1C65.6080200@stpeter.im>	<49BB86C1.7000501@buddycloud.com>	<49BE7ABD.9000904@stpeter.im>	<49C336DD.6080302@buddycloud.com>	<2E1BE33B-B082-449F-86C0-4E15DEE788B3@gmail.com>	<49C4B5C5.2070007@buddycloud.com>
	<B99A6B98-5C8C-4343-AEB8-48E20617A9BD@gmail.com>
Message-ID: <49DAD005.8050503@stpeter.im>

On 3/22/09 7:00 PM, Joe Hildebrand wrote:
> 
> On Mar 21, 2009, at 2:39 AM, Helge Timenes wrote:
>>> I agree that "mac" is more general-purpose.
>> Well "mac" is maybe also too general?
> 
> Agree.  Either "nic" or "ethernet" are fine with me.
> 
>> Would "nic" be appropriate? In any case a bit of prose would be needed
>> to explain its usage
> 
> That's fine.  How about:
> 
> The "nic" type is an indication to the location server of the link layer
> (Media Access Control) address of one of the Network Interface
> Controllers (NICs) associated with the client sending the request.  Most
> commonly, this will take the form of a 48-bit ethernet address formatted
> in six colon-separated groups of two hexadecimal digits, in transmission
> order.   Some location servers may be able to use this information to
> query network elements through which the client is connected in order to
> deduce location data.

WFM.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/af436334/attachment-0001.bin 

From stpeter at stpeter.im  Mon Apr  6 23:02:18 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:02:18 -0600
Subject: [Standards] UPDATED: XEP-0255 (Location Query)
In-Reply-To: <49C336DD.6080302@buddycloud.com>
References: <E1LiJvr-0005Wc-00@apollo>	<49BB1C65.6080200@stpeter.im>	<49BB86C1.7000501@buddycloud.com>	<49BE7ABD.9000904@stpeter.im>
	<49C336DD.6080302@buddycloud.com>
Message-ID: <49DAD04A.5040105@stpeter.im>

On 3/20/09 12:25 AM, Helge Timenes wrote:
> Firstly, I appologise for sluggish response. I ran into another
> space-time continuum singularity...

It happens. :)

> Secondly, see inline.
> 
> 
> Peter Saint-Andre wrote:
>> On 3/14/09 4:28 AM, Helge Timenes wrote:
>>   
>>> Peter Saint-Andre wrote:
>>>     
>>>> On 3/13/09 8:49 PM, XMPP Extensions Editor wrote:
>>>>
>>>>   
>>>>       
>>>>> URL: http://www.xmpp.org/extensions/xep-0255.html
>>>>>     
>>>>>         
>>>> I notice that the suggested / allowable values of the 'type' attribute
>>>> are "cell", "wifi", "bluetooth", "wimax", "rfid", "ip", "other". I see
>>>> three ways to handle these:
>>>>
>>>> 1. Restrictive: lock down these values in the schema
>>>>
>>>> 2. Permissive: allow applications to include any value they choose
>>>>
>>>> 3. Extensible: set up a registry so that we don't need to update the
>>>> spec every time we add a new value while still providing guidance to
>>>> implementors
>>>>
>>>> I lean toward #3.
>>>>   
>>>>       
>>> That seems sensible, though i suspect the reference types will change
>>> frequently while the XEP is young, but at some point settle down as the
>>> spec catches up with all the possibilities out there (sure new ones will
>>> be invented, but not at a pace that is hard to keep up with I'd guess)
>>>     
>>
>> If we have a registry, we don't need to update the spec all the time.
>> Perhaps it's not a big deal.
>>
>>   
>>> How would such a registry work? Are there examples of such from other XEPs?
>>>     
>>
>> I've defined all the registries so far since I'm the XMPP Registrar. :)
>> It's easy enough for me to add this to the spec.
>>
>>   
> Register at will :-)

I'd be happy to define the necessary registry bits in the XEP before we
publish the next version.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/3e4eab1e/attachment.bin 

From stpeter at stpeter.im  Mon Apr  6 23:13:56 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:13:56 -0600
Subject: [Standards] User Profile/Relationship/Project/Resume (was: MUC
 avatar/logo)
In-Reply-To: <6e2f977f0903180730g24363918j705c0034f4a4edfe@mail.gmail.com>
References: <6e2f977f0903180730g24363918j705c0034f4a4edfe@mail.gmail.com>
Message-ID: <49DAD304.20707@stpeter.im>

On 3/18/09 8:30 AM, Nicolas V?rit? wrote:
> 2009/3/18 Remko Tron?on <remko at el-tramo.be>:
>>> I think a VCard is exactly what you mean, or what do you mean by User
>>> Profile?
>> He means XEP-154, but that one is dying anyway.
> 
> [Yes, I meant that, answered offlist not to pollute]
> 
> OK, I learn that  XEP-0154 is being abandoned, so what about cutting
> and restrcturing all the info in User Profile in different PEP stuff?
> Like the user's relationships, projects, resume...

I don't think we've made a decision to abandon XEP-0154, although I do
think it would be good for us to look closely at the work happening in
the IETF to update vCard and define an XML representation:

http://www.ietf.org/html.charters/vcarddav-charter.html

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-06

http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-00

The XML representation is not currently an official WG item, but there's
pretty strong consensus to pursue that work, see the thread starting here:

http://www.ietf.org/mail-archive/web/vcarddav/current/msg00899.html

So I think that we could work within that framework to define everything
we need in an interoperable way (not some XMPP-specific stuff). And we
could finally deprecate vcard-temp (which has been "temp" since ~2000!).

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/9f93735e/attachment.bin 

From stpeter at stpeter.im  Mon Apr  6 23:38:29 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:38:29 -0600
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
 XEP-0136 ?
In-Reply-To: <706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>
References: <49404294.7070105@eaktion.com> <49D92FA1.1030408@stpeter.im>
	<706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>
Message-ID: <49DAD8C5.8030100@stpeter.im>

On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote:
> Hello Peter,
> 
> On Sun, 05 Apr 2009 16:24:33 -0600, Peter Saint-Andre <stpeter at stpeter.im>
> wrote:
> 
>> You are right -- the words "participating full JID" in the first
>> paragraph of Section 7.2 unnecessarily and incorrectly limit the
>> matching for collection retrieval. I've fixed that:
>>
>>
> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u&%40diffWrap=s&r1=2415&r2=2993&u=3&ignore=&k=
> 
> ... in fact it seems I've managed to convince several people in the
> opposite already (including topic-starter) based on current XEP-136 wording
> ;-) See discussion starting from this comment:
> https://www.ndl.kiev.ua/content/modarchiveodbc-release#comment-117

Oops.

The original poster was right that the following text is confusing:

***

To request a page of messages from a collection the client sends a
<retrieve/> element. The 'with' and 'start' attributes specify the
participating full JID and the start time (see XEP-0082). Both
attributes MUST be included to uniquely identify a collection.

In addition, the client MAY match an exact bare JID
(<localpart at domain.tld> or <domain.tld>) by setting the boolean
'exactmatch' attribute to a value of "true" or "1" [14] -- for details,
refer to the Exact JID Matching section of this document.

***

There is no need for 'exactmatch' if you can specify only a full JID.

I'll look at this more tomorrow...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/5e8430b3/attachment-0001.bin 

From stpeter at stpeter.im  Mon Apr  6 23:45:19 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:45:19 -0600
Subject: [Standards] Multiple binds in XMPP-CORE
In-Reply-To: <87fxhx8lwc.fsf@phex.sachmittel.de>
References: <m23ae1dw03.fsf@new-host-2.livebox.home>	<m2ab86mz3p.fsf@new-host.my-domain>	<A9BCCA44-1BF9-4DEA-9E69-8A952AD0A66C@mumbo.ca>	<200902281149.51547.justin-keyword-jabber.093179@affinix.com>	<18794.1235900347.426571@invsysm1>
	<87ljrp8tlj.fsf@phex.sachmittel.de>	<22869.1235909012.330449@invsysm1>
	<87fxhx8lwc.fsf@phex.sachmittel.de>
Message-ID: <49DADA5F.4080402@stpeter.im>

On 3/1/09 5:31 AM, Dirk Meyer wrote:
> Dave Cridland wrote:
>> On Sun Mar  1 09:45:12 2009, Dirk Meyer wrote:
>>> I'm thinking of maybe having a proxy in the home network. All local
>>> devices connect to the proxy and the proxy relays everything to the
>>> server. In that case the proxy registers all resources from its
>>> clients
>>> to the server. Maybe it is a stupid idea, maybe not.
>> Okay, so I look forward to your document explaining the security
>> implications of deliberately introducing a man in the middle. ;-)
>>
>> Seriously, what does such an architecture gain you?
> 
> It was just an idea. But reading all the answers here, I guess I do not
> need it. So ignore my last mail. :)

I'd be OK with removing this.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090406/169b4539/attachment.bin 

From mridulm80 at yahoo.com  Tue Apr  7 00:41:54 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Tue, 7 Apr 2009 11:11:54 +0530 (IST)
Subject: [Standards] Presence distribution
Message-ID: <797692.33902.qm@web95413.mail.in2.yahoo.com>




--- On Mon, 6/4/09, Dave Cridland <dave at cridland.net> wrote:

> From: Dave Cridland <dave at cridland.net>
> Subject: Re: [Standards] Presence distribution
> To: "XMPP Standards" <standards at xmpp.org>
> Date: Monday, 6 April, 2009, 11:10 PM
> On Mon Apr? 6 17:54:16 2009,
> Philipp Hancke wrote:
> > Actually, the current model enables a single client to
> bring down
> > a server by making the server broadcast large presence
> stanzas at
> > a high rate. Simplistic bandwidth control mechanisms
> such as "karma"
> > account traffic per socket, and do not throttle the
> client when it
> > generates excessive amounts of s2s traffic.
> > 
> > 
> How does the client force the subscription?
> 
> >> Yes.. But not at the cost of making the protocol
> worse. By the way, the
> > 
> > It is not "worse", just different.
> 
> No, it is worse, the failure case of the missing
> unsubscribed is a privacy leak.
> 
> >> Let's review what happens currently, assuming an
> initiating contact with n availableremote contacts across d
> domains, each of which has y resources connected - y being
> different in each instance obviously:
> > 
> > "available remote contacts" is those bis
> optimizations?
> > Actually, were those discussed before they were
> introduced?
> > What is their impact on presence reliability?
> > 
> > 
> Yes, and they're not mandated.
> 
> 
> >> 1) Client sends home server a broadcast presence.
> Cost E1, O(1).
> > 
> > Why not shift the responsibility for distribution to
> the client?
> > This would make E1=O(n) and E2=O(1) (simple message
> routing).
> > Afaics, your argument applies for that as well.
> > 
> > 
> Ah, but the server has responsibility anyway, so it's a
> reasonable optimization there.
> 
> 
> >> 2) Home server, which (almost certainly) has
> client's roster in-memory, iterates through and emits one
> presence stanza per remote subscribed contact known to be
> available. Cost E2, O(n). (Iterating through a list of known
> available contacts).
> > 
> > Actually, why don't you send the presence stanza to
> each connected
> > resource of each available contact here - iterating
> through a list of
> > known avaible contact resources)?
> > 
> > 
> It's not that server's responsibility to maintain that
> definitive list, though.
> 
> >> 3) Home server encodes and transmits N stanzas,
> remote server decodes and transmits N stanzas. Cost E3,
> O(n). (One stanza per contact - arguably this is O(d) to
> open the stream, and O(y) to send the stanzas - you pick).
> > 
> > O(y) should be O(n) here?
> > 
> > 
> No, it's d*O(y), but that's equivalent to O(y). I don't
> think it makes a huge difference whether it's O(y) + O(d) or
> O(n), though.
> 
> 
> >> 4) Remote server receives one or more
> fully-addressed stanzas, and broadcasts them to all
> resources. Cost E4, O(y). (Iterating through a list of
> resources of the recipient).
> > 
> > This is done n times. And you are neglecting costs for
> privacy list
> > checks (I will call that O(p), different for each
> instance and
> > quite costly imo).
> > Hence E4 = O(n) + n*(O(p) + O(y))
> > 
> > 
> Well, the 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
> collate a per-domain list of contacts. I've not considered
> this, because of the risks of such lists being lost, or out
> of sync themselves, and the problems that having arbitrary
> servers able to command resources on your server.



This was discussed and proposed a while back, and iirc there was a prototype ... not sure where it went though : but the saving were interestingly high.

http://blogs.sun.com/mridul/entry/minimising_s2s_traffic
http://blogs.sun.com/mridul/entry/minimising_s2s_traffic_in_xmpp

are some rough notes/thoughts which could be bashed into shape, if required.

- Mridul


> 
> 
> >> This gives E, as O(n) + O(y), a linear complexity
> algorithm.
> > 
> > O(n) + n*(O(p) + O(y)).
> > 
> > 
> That's O(n + np + ny), I think.
> 
> 
> >> You want to replace 2-4 with:
> >> 
> >> 2') Home server collates roster by remote domain
> and emits one presence stanza per remote domain which has a
> subscribed contacts known to be available. This is, I'll
> accept, likely to be close to the energy cost of 2, although
> due to the fluctuating nature of? the final clause that
> collation has to be done each time, so it'll be a little
> above. Cost E2' is, therefore > E2. O(n) + O(d) - I have
> a feeling this can be reduced to O(n).
> >> 
> >> 3') encode/transmit/decode 1 stanza per remote
> domain.. This is certainly an energy/cpu/cost saving compared
> to the 3 above, no argument from me here. Cost E3' is <
> E3. O(d) (One stanza per domain.. Still linear, of course).
> > 
> > Linear with d. Assuming that people 'cluster', d
> << n is reasonable.
> > 
> > 
> Sure, but I'm astonishingly unconvinced that the O(y) term
> in E3 is significant - I suspect the maintainence of the
> domain XMLstreams is by far the bigger cost, here - in fact,
> I personally think it's entirely reasonable to suggest that
> for all practical purposes, E3 == E3' == O(d), although in
> practise E3' will be slightly smaller, and in the case where
> y is particularly big, that difference will of course become
> significant.
> 
> But for the vast majority of cases, y == 1 - in my roster,
> it's a maximum of 12 (for jabber.org), the next highest is 6
> or so (for gmail.com), and the remaining levels or 2 or 1,
> across quite a few domains. I don't think under these cases
> that - unless the constant involved is massive - O(y) is
> going to be a substantial factor.
> 
> 
> >> 4') Lookup sender against all rosters in the
> system, and detirmine which of the resulting potential
> recipients is online and available to the sender. It seems
> reasonable that it would be possible to limit the lookup to
> only contacts who are online and available - assuming we
> ignore privacy lists - but you're still adding a lookup and
> the
> > 
> > This depends on how you do the lookup imo.
> > 
> > 
> Yes, Waqas argues that it might be replacement rather than
> addition.
> 
> 
> >> associating lookup mechanics (like a hash table or
> something) which must be maintained in-memory. I strongly
> suspect that this much, much more costly to use, build, and
> maintain than 4 above, hence E4' >> E4. I
> > 
> > If you are neglecting privacy lists above certainly..
> > 
> > I think you can reduce this to E4' = n*O(y).
> > 
> > 
> n cannot possibly occur in this - n is a figure local to
> the initiating server. It might happen d times, though, on
> different servers.
> 
> 
> >> believe this to be possible to implement as
> O(log(y)), but I also suspect it's overwhemlingly more
> likely that it's O(y) (as derived from a reverse roster
> lookup O(log(y)) combined with a resource-broadcast lookup
> O(y)).
> >> 
> >> This give E' as O(n) + O(d) + O(y), a linear
> compexity algorithm. Poof goes your argument above about
> linear complexity versus constant amortized time.
> >> 
> >> I can't see (E3' - E3) < ((E4' - E4) + (E2' -
> E2)) as being at all likely, so I continue to maintain that
> this is a false optimization.
> > 
> > I disagree. But at least your argument is technically
> founded and better
> > than what I have heard from the council in 2006 (and I
> had to gather
> > that from the chatroom).
> > 
> > 
> Waqas points out some potential flaws - I'm still not
> convinced that it represents a cost-saving for either end,
> but the difference might well be smaller than I thought. In
> particular, he suggests that E4 might be implemented as a
> single multivalued hashtable, thus reducing that lookup to
> O(1).
> 
> We had a very interesting conversation about the relative
> costs of string internalization and all sorts.
> 
> 
> > I care about effective flood control mechanisms. This
> is about moving
> > cost where they are affordable.
> > 
> >> (I also continue to maintain that this is an
> arse-clenchingly more complex solution to the problem of
> getting presence from one contact to another, but I hope
> nobody's arguing against me, there).
> > 
> > It is a different solution. One that has been used for
> years on IRC.
> 
> IRC has a different structure, and uniform view throughout
> the network - indeed, one server is specifically designed to
> be indistinguishable from any other. That's not the case in
> XMPP, and means different approaches and considerations. IRC
> behaves like a single XMPP cluster, in that respect, where
> all these optimizations are entirely possible.
> 
> > p.s.: I still want a review for that 220-rewrite from
> you.
> 
> Pester me next week?
> 
> Dave.
> --Dave Cridland - mailto:dave at cridland.net
> - xmpp:dwd at dave.cridland.net
>  -
> acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From fabio.forno at gmail.com  Tue Apr  7 01:03:45 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Tue, 7 Apr 2009 08:03:45 +0200
Subject: [Standards] UPDATED: XEP-0198 (Stream Management)
In-Reply-To: <49DAA6C1.8010008@stpeter.im>
References: <E1LoSha-0003wC-00@apollo>
	<2fd53c3a0903310507t40fc6a32k6d27a4292865329f@mail.gmail.com>
	<49DAA6C1.8010008@stpeter.im>
Message-ID: <2fd53c3a0904062303l3c54bce5mc48cfd0a33d949@mail.gmail.com>

On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:

>>
>> S: <t xmlns='urn:xmpp:sm:1' max="n"/>
>>
>> It isn't perfect but it can work for most of the cases.
>
> Agreed. But what is the purpose of max="n" here?

It could be used to adjust the number of maximun number of outstanding
packets (When throttling it makes sense to reduce it)

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From sachin at geodesic.com  Tue Apr  7 01:20:04 2009
From: sachin at geodesic.com (Sachin Khandelwal)
Date: Tue, 7 Apr 2009 11:50:04 +0530
Subject: [Standards] XEP-0136 - Message Archiving Preferences doubt
In-Reply-To: <edab29795f6f40dda93fc695d9ed8124@ndl.kiev.ua>
References: <200904021106.09674.sachin@geodesic.com>
	<edab29795f6f40dda93fc695d9ed8124@ndl.kiev.ua>
Message-ID: <200904071150.04826.sachin@geodesic.com>

Hi,

Thanks for the reply. It has cleared lots of confusions.

Only in case of otr ssn negotiation, its fine that its clients responsibility 
to make sure that server acts according to the agreement that clients reached.

But say if any client has not set the proper preference of user and contact in 
case of otr as I mentioned in the previous earlier then what is expected from 
server when both users are having auto=true but otr as require and forbid.

One possible solution I think of is : the server can archive the messages for 
the one having otr as forbid and will not archive for one having otr as 
require.

Regards,

Sachin Khandelwal
Sr. Software Engineer | Mundu Sever
Geodesic Limited | www.geodesic.com
Tel: +91 22 4031 5815

On Thursday 02 April 2009 17:38:20 Alexander Tsvyashchenko wrote:
> Hello Sachin,
>
> I cannot give the "authoritative" answers to your questions, but I'll try
> to answer based on my understanding of XEP and experience from its
> implementation, and it's up to you to decide whether these answers make
> sense or not ;-)
>
> On Thu, 2 Apr 2009 11:06:09 +0530, Sachin Khandelwal <sachin at geodesic.com>
> wrote:
>
> [skipped]
>
> > whenever
> > the user logs in, as per his saved preference the server will decide
> > whether
> > to archive messages or not.
>
> From this statement, as well as your questions, I think you expect slightly
> too much from the server: it's my understanding that XEP-136 specifies
> server role to be more like "storage back-end" driven by clients rather
> than some independent entity that performs all archiving operations
> decisions on its own.
>
> > But there are some confusions :
> >  1) statement from Sec 2.1 (third para) -
> > However, a client MAY maintain a set of preferences in a local file which
> > takes
> > precedence over the preferences stored on the server for both local
> > archiving
> > and server-side archiving.
> >
> > DOUBT:  in case of auto archiving how the server will come to know about
> > the
> > client's local file (say the local file and server stored preference is
> > different). So even if in local file the auto archiving is disabled, the
> > server
> > will archive messages in its enabled in server stored preference of user.
>
> It doesn't need to: it's client role to bring server configuration up to
> client expectations.
>
> Moreover, note that auto-archiving might be slightly confusing in XEP-136:
> in the normal (non-enforced) auto-archiving mode the auto-archiving state
> of all new streams does not depend on preferences for auto-archiving, see
> 6: "Automatic archiving MUST default to disabled when each stream is
> opened."
>
> The normal/enforced auto-archiving mode is specified via some external
> means not related to XEP-136 (such as server configuration) and is not
> influenced by archiving preferences.
>
> Therefore for normal auto-archiving mode it's just the opposite case that
> you should worry about: if local client settings specify that
> auto-archiving should be on by default, then when opening new stream the
> client should tell the server to enable auto-archiving, see example 29 in
> XEP-136.
>
> To be true, while I can understand the reasoning behind such scheme, in my
> implementation I've added also the intermediate mode (which can be set in
> server configuration) which turns on auto-archiving by default for all
> streams (unlike in "normal" mode), but allows clients to turn it off
> (unlike in "enforced" mode). This settings has proven to be useful for me,
> though strictly speaking it violates XEP-136.
>
> Also note that not all preferences are meant to be interpreted by the
> server at all: for example "method" preferences are in fact for client
> interpretation only, so that client can request these methods from server
> and based on this decide how to proceed.
>
> > 2) statement from Sec 2.2 (4th point) -
> > MUST include at least three <method/> elements, differentiated by the
>
> value
>
> > of
> > the 'type' attribute (i.e., at least one <method/> element each for
>
> "auto",
>
> > "local", and "manual").
> >
> > DOUBT:  But as per sec. 2.2.4.1, type attribute can only have values
>
> (auto,
>
> > local, manual). So my understanding is that there can be at most 3
>
> methods
>
> > instead of at least three as specified in the above statement. If I'm
>
> wrong
>
> > then please provide an example of more then three methods.
>
> There's no word "only" there ;-) It's just the minimal set of values that
> MUST be supported, but as far as I understand the meaning of this
> parameter, if client decides that it should provide an additional method -
> say, "local-floppy-5.25" to indicate that local archiving of all messages
> to 5.25 floppies is requested - it may use this method value to store this
> setting on server and later, after getting it back on subsequent sessions,
> act accordingly.
>
> I agree though that the meaning of "method" element and extensibility of
> its values could be explained slightly more verbosely in spec ;-)
>
> > 3) regarding sec "3.1 OTR Negotiation " -
> >
> > DOUBT : My understanding is that the SSN negotiation is in between the
> > clients. So how the server will come to know about the final result of
> > negotiation. Say the otr mode stored in server for user and contact is
> > require
> > and forbid respectively. Now after SSN negotiation contact agrees for otr
> > (SSN
> > negotiation is successful ) then how the server will come to know about
>
> it.
>
> > And in another case say they have haven't done the SSN negotiation then
> > with
> > the above otr mode, what is expected from server, whether to archive the
> > message or not.
>
> Again, see above - server doesn't care, it's only client responsibility to
> make sure that server acts accordingly to the agreement that clients
> reached.


From fippo at goodadvice.pages.de  Tue Apr  7 01:45:28 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Tue, 07 Apr 2009 08:45:28 +0200
Subject: [Standards] Inconsistent Subscriptions in XMPP
In-Reply-To: <20090224014950.0b613c9f@tiger>
References: <20090224014950.0b613c9f@tiger>
Message-ID: <49DAF688.9090805@goodadvice.pages.de>

hijacking the thread... two concrete examples where error handling
is needed:

subscription state is "none" initially:
SENT: <presence to="foo at bar" id="jcl_37" type='subscribe'/>
RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='push' 
type='set'><query xmlns='jabber:iq:roster'><item ask='subscribe' 
subscription='none' jid='foo at bar'/></query></iq>
RECV: <presence from='foo at bar' to='me at local/Exodus' type='error' 
id='jcl_37'><error code='404' type='cancel'><remote-server-not-found 
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence>

after relogin and roster fetch:
RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='jcl_40' 
type='result'><query xmlns='jabber:iq:roster'><item ask='subscribe' 
subscription='none' jid='foo at bar'/>

The presence error (which, as can be by looking at the id attribute,
is a reply to the initial subscribe) does not affect the subscription
state.


subscription state is "both" initially:
SENT: <iq id="jcl_50" type="set"><query xmlns="jabber:iq:roster"><item 
jid="some at jid" subscription="remove"/></query></iq>
RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='push' 
type='set'><query xmlns='jabber:iq:roster'><item subscription='remove' 
jid='some at jid'/></query></iq>
RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='jcl_50' 
type='result'/>
RECV: <presence from='some at jid' to='me at local/Exodus' type='error'><error 
code='404' type='cancel'><remote-server-not-found 
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence>
RECV: <presence from='some at jid' to='me at local/Exodus' type='error'><error 
code='404' type='cancel'><remote-server-not-found 
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence>

The subscription state is "none" afterwards - which is the users intention.
The presence errors are replies to unsubscribe/unsubscribed stanzas
generated by the server and should imo never have been sent to the
client.

The question is: how do error replies to presence subscription
stanzas affect the subscription state?

philipp

From lists at ndl.kiev.ua  Tue Apr  7 03:42:24 2009
From: lists at ndl.kiev.ua (Alexander Tsvyashchenko)
Date: Tue, 07 Apr 2009 11:42:24 +0300
Subject: [Standards] XEP-0136 - Message Archiving Preferences doubt
In-Reply-To: <200904071150.04826.sachin@geodesic.com>
References: <200904021106.09674.sachin@geodesic.com>
	<edab29795f6f40dda93fc695d9ed8124@ndl.kiev.ua>
	<200904071150.04826.sachin@geodesic.com>
Message-ID: <24ed641ac4ce315f4cc067fee70df40f@ndl.kiev.ua>


Hello Sachin,

On Tue, 7 Apr 2009 11:50:04 +0530, Sachin Khandelwal <sachin at geodesic.com>
wrote:

> Only in case of otr ssn negotiation, its fine that its clients
> responsibility 
> to make sure that server acts according to the agreement that clients
> reached.
> 
> But say if any client has not set the proper preference of user and
contact
> in 
> case of otr as I mentioned in the previous earlier then what is expected
> from 
> server when both users are having auto=true but otr as require and
forbid.

... and if client records messages locally contrary to what OTR/preferences
suggest, should the server brute-force user's PC account and, if
successful, scan HDD and remove all messages recorded not in accordance to
preferences stored on server? ;-)

Talking seriously, server does not take any part nor in OTR negotiation,
neither in analysis of OTR preferences stored on server. These preferences
are for client only: it takes it as starting values and based on that
starts OTR negotiation. 

When OTR negotiation finishes, client may need to configure its server
accordingly to the agreement achieved - such as enable auto-archiving for
current stream, if OTR negotiation resulted in "allow archive" agreement
and client prefers auto-archiving rather than manual one, or adjust
item[@save] attribute to 'false' value for particular JID if OTR
negotiation resulted in "do not archive" agreement but client still wants
to keep auto-archive enabled for all other conversations, or whatever.

Once again: the server is just "storage back-end", and it does only what
client told it to do. If client told the server "enable auto-archiving" -
so be it, it's client responsibility to ensure that this command didn't
violate OTR negotiation results or whatever else part of XEP-136. There's
no point in server knowing about OTR and trying to enforce it when clients
may easily violate it by local messages recording.

2Peter: in fact XEP-136 might be slightly confusing in its current form
regarding preferences interpretation in auto-archiving mode - probably, it
might be a good idea to list explicitly which preferences server takes into
account when auto-archiving is enabled. I believe these are "auto" (per
stream), "default[@expire, @save]" and "item[@expire, @jid, @save]" in
"normal" auto-archiving mode and no preferences are taken into account in
"forced" auto-archiving mode.

It also might be useful to explicitly state that all other preferences are
for clients interpretation only.

-- 
Good luck!                                     Alexander

From stpeter at stpeter.im  Tue Apr  7 08:52:12 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 07 Apr 2009 07:52:12 -0600
Subject: [Standards] UPDATED: XEP-0198 (Stream Management)
In-Reply-To: <2fd53c3a0904062303l3c54bce5mc48cfd0a33d949@mail.gmail.com>
References: <E1LoSha-0003wC-00@apollo>	<2fd53c3a0903310507t40fc6a32k6d27a4292865329f@mail.gmail.com>	<49DAA6C1.8010008@stpeter.im>
	<2fd53c3a0904062303l3c54bce5mc48cfd0a33d949@mail.gmail.com>
Message-ID: <49DB5A8C.7090402@stpeter.im>

On 4/7/09 12:03 AM, Fabio Forno wrote:
> On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 
>>> S: <t xmlns='urn:xmpp:sm:1' max="n"/>
>>>
>>> It isn't perfect but it can work for most of the cases.
>> Agreed. But what is the purpose of max="n" here?
> 
> It could be used to adjust the number of maximun number of outstanding
> packets (When throttling it makes sense to reduce it)

Ah, I think that needs to be a 'stanzas' attribute. The 'max' attribute
specifies the longest allowable time period for session resumption and
the 'stanzas' attribute indicates the server's preferred maximum number
of received stanzas between acks.

So:

<t xmlns='urn:xmpp:sm:1' stanzas="n"/>

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090407/f03230f1/attachment.bin 

From stpeter at stpeter.im  Tue Apr  7 11:31:20 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 07 Apr 2009 10:31:20 -0600
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
 XEP-0136 ?
In-Reply-To: <706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>
References: <49404294.7070105@eaktion.com> <49D92FA1.1030408@stpeter.im>
	<706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>
Message-ID: <49DB7FD8.9040306@stpeter.im>

On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote:

> I see two possible solutions:
> 
> 1) Keep things like they were before, so that "retrieve" may return
> messages from one collection only. Requires rollback of the last change to
> XEP and removing "exactmatch" support by "retrieve" from 10.1 and from XML
> Schema.

I now think that is the right approach.

Alexander, what do you think?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090407/76af4dd7/attachment.bin 

From Dean at cognation.net  Tue Apr  7 16:00:42 2009
From: Dean at cognation.net (Dean Collins)
Date: Tue, 7 Apr 2009 17:00:42 -0400
Subject: [Standards] XMPP example site - www.LiveBaseballChat.com
In-Reply-To: <49DAD304.20707@stpeter.im>
References: <6e2f977f0903180730g24363918j705c0034f4a4edfe@mail.gmail.com>
	<49DAD304.20707@stpeter.im>
Message-ID: <3685A8FD247FA94C957C4304AB386A0427CC8F@cognationsvr1.Cognation.local>

I'm not sure if this is crossing the lines and if it is feel free to
delete this email.

But we are always talking about XMPP on this mailing list but I rarely
see anyone talking about sites that have implemented solutions and apart
from the well known public IM facing sites and sites like Chesspark etc
I couldn't name more than 4 or 5 I've seen mentioned.

Anyway so I thought I would let you know about a small site we just
launched this week called www.LiveBaseballChat.com 

Basically it is an ajax/xmpp site with 2430 chat rooms set up over the
next 6 months for people to talk about specific Baseball games.

It has Facebook, twitter and email integration.

There are still a number of tweaks to implement over the next few days
but thought it might interest some of you to go and check it out
(obviously best in the USA afternoon when games are on so you can see
how it works fully).

Like I said not sure if this is breaching etiquette if it is feel free
to delete.

 

 

Regards,

Dean Collins
Live Chat Concepts Inc
dean at livechatconcepts.com 
+1-212-203-4357   New York
+61-2-9016-5642   (Sydney in-dial).
+44-20-3129-6001 (London in-dial).





From stpeter at stpeter.im  Tue Apr  7 16:15:01 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 07 Apr 2009 15:15:01 -0600
Subject: [Standards] XMPP example site - www.LiveBaseballChat.com
In-Reply-To: <3685A8FD247FA94C957C4304AB386A0427CC8F@cognationsvr1.Cognation.local>
References: <6e2f977f0903180730g24363918j705c0034f4a4edfe@mail.gmail.com>	<49DAD304.20707@stpeter.im>
	<3685A8FD247FA94C957C4304AB386A0427CC8F@cognationsvr1.Cognation.local>
Message-ID: <49DBC255.6080207@stpeter.im>

On 4/7/09 3:00 PM, Dean Collins wrote:
> I'm not sure if this is crossing the lines and if it is feel free to
> delete this email.

Nope, it's always good to hear about applications. Usually we learn of
such things through blog posts, microblogging mentions, or posts to the
jdev at jabber.org list. It's all a bit informal. :)

> But we are always talking about XMPP on this mailing list but I rarely
> see anyone talking about sites that have implemented solutions and apart
> from the well known public IM facing sites and sites like Chesspark etc
> I couldn't name more than 4 or 5 I've seen mentioned.
> 
> Anyway so I thought I would let you know about a small site we just
> launched this week called www.LiveBaseballChat.com 
> 
> Basically it is an ajax/xmpp site with 2430 chat rooms set up over the
> next 6 months for people to talk about specific Baseball games.

Sweet. And just in time for baseball season! :)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090407/2e1607eb/attachment.bin 

From lists at ndl.kiev.ua  Tue Apr  7 16:32:46 2009
From: lists at ndl.kiev.ua (Alexander Tsvyashchenko)
Date: Wed, 08 Apr 2009 00:32:46 +0300
Subject: [Standards]
 =?utf-8?q?inconsistency_between_section_7=2E2_-_10=2E?=
 =?utf-8?q?2_in_XEP-0136_=3F?=
In-Reply-To: <49DB7FD8.9040306@stpeter.im>
References: <49404294.7070105@eaktion.com> <49D92FA1.1030408@stpeter.im>
	<706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>
	<49DB7FD8.9040306@stpeter.im>
Message-ID: <a8df98985ab82d5519f4b3f32a8db9f6@ndl.kiev.ua>


Peter,

On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre <stpeter at stpeter.im>
wrote:

> On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote:
> 
>> I see two possible solutions:
>> 
>> 1) Keep things like they were before, so that "retrieve" may return
>> messages from one collection only. Requires rollback of the last change
>> to
>> XEP and removing "exactmatch" support by "retrieve" from 10.1 and from
>> XML
>> Schema.
> 
> I now think that is the right approach.
> 
> Alexander, what do you think?

I think that would be both the best and the easiest solution (the rare case
when these qualities do not interfere ;-)

-- 
Good luck!                                     Alexander

From stpeter at stpeter.im  Tue Apr  7 16:44:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 07 Apr 2009 15:44:22 -0600
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
 XEP-0136 ?
In-Reply-To: <a8df98985ab82d5519f4b3f32a8db9f6@ndl.kiev.ua>
References: <49404294.7070105@eaktion.com>
	<49D92FA1.1030408@stpeter.im>	<706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>	<49DB7FD8.9040306@stpeter.im>
	<a8df98985ab82d5519f4b3f32a8db9f6@ndl.kiev.ua>
Message-ID: <49DBC936.2000505@stpeter.im>

On 4/7/09 3:32 PM, Alexander Tsvyashchenko wrote:
> Peter,
> 
> On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre <stpeter at stpeter.im>
> wrote:
> 
>> On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote:
>>
>>> I see two possible solutions:
>>>
>>> 1) Keep things like they were before, so that "retrieve" may return
>>> messages from one collection only. Requires rollback of the last change
>>> to
>>> XEP and removing "exactmatch" support by "retrieve" from 10.1 and from
>>> XML
>>> Schema.
>> I now think that is the right approach.
>>
>> Alexander, what do you think?
> 
> I think that would be both the best and the easiest solution (the rare case
> when these qualities do not interfere ;-)

OK, good. I will update XEP-0136 accordingly and then the Council can
decide whether to approve the changes.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090407/eb101639/attachment-0001.bin 

From stpeter at stpeter.im  Tue Apr  7 16:55:24 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 07 Apr 2009 15:55:24 -0600
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
 XEP-0136 ?
In-Reply-To: <49DBC936.2000505@stpeter.im>
References: <49404294.7070105@eaktion.com>	<49D92FA1.1030408@stpeter.im>	<706eb2d679003008edaf7d90ddccfe3a@ndl.kiev.ua>	<49DB7FD8.9040306@stpeter.im>	<a8df98985ab82d5519f4b3f32a8db9f6@ndl.kiev.ua>
	<49DBC936.2000505@stpeter.im>
Message-ID: <49DBCBCC.3090500@stpeter.im>

On 4/7/09 3:44 PM, Peter Saint-Andre wrote:
> On 4/7/09 3:32 PM, Alexander Tsvyashchenko wrote:
>> Peter,
>>
>> On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre <stpeter at stpeter.im>
>> wrote:
>>
>>> On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote:
>>>
>>>> I see two possible solutions:
>>>>
>>>> 1) Keep things like they were before, so that "retrieve" may return
>>>> messages from one collection only. Requires rollback of the last change
>>>> to
>>>> XEP and removing "exactmatch" support by "retrieve" from 10.1 and from
>>>> XML
>>>> Schema.
>>> I now think that is the right approach.
>>>
>>> Alexander, what do you think?
>> I think that would be both the best and the easiest solution (the rare case
>> when these qualities do not interfere ;-)
> 
> OK, good. I will update XEP-0136 accordingly

Done:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u&%40diffWrap=s&r1=2993&r2=3008&u=3&ignore=&k=

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090407/cac60942/attachment.bin 

From sachin at geodesic.com  Wed Apr  8 03:00:58 2009
From: sachin at geodesic.com (Sachin Khandelwal)
Date: Wed, 8 Apr 2009 13:30:58 +0530
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
	XEP-0136 ?
In-Reply-To: <49DBCBCC.3090500@stpeter.im>
References: <49404294.7070105@eaktion.com> <49DBC936.2000505@stpeter.im>
	<49DBCBCC.3090500@stpeter.im>
Message-ID: <200904081330.58424.sachin@geodesic.com>

Hi,

I feel it'll create inconsistency due to changes in section "7.1 and 7.2" . As 
per section sec 4.5 the with attribute can be JID (not only full jid). so due 
to this change, it'll not be possible retrieve the collections having with 
attribute as bare JID. 

One solution I think of is to keep sec "7.1 Retrieving a List of Collections" 
as it is and for sec. "7.2 Retrieving a Collection", remove the 'exactmatch' 
attribute and the value of with attribute should always be exactly matched by 
default.

Regards,

Sachin Khandelwal
Sr. Software Engineer | Mundu Sever
Geodesic Limited | www.geodesic.com
Tel: +91 22 4031 5815

On Wednesday 08 April 2009 03:25:24 Peter Saint-Andre wrote:
> On 4/7/09 3:44 PM, Peter Saint-Andre wrote:
> > On 4/7/09 3:32 PM, Alexander Tsvyashchenko wrote:
> >> Peter,
> >>
> >> On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre
> >> <stpeter at stpeter.im>
> >>
> >> wrote:
> >>> On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote:
> >>>> I see two possible solutions:
> >>>>
> >>>> 1) Keep things like they were before, so that "retrieve" may return
> >>>> messages from one collection only. Requires rollback of the last
> >>>> change to
> >>>> XEP and removing "exactmatch" support by "retrieve" from 10.1 and from
> >>>> XML
> >>>> Schema.
> >>>
> >>> I now think that is the right approach.
> >>>
> >>> Alexander, what do you think?
> >>
> >> I think that would be both the best and the easiest solution (the rare
> >> case when these qualities do not interfere ;-)
> >
> > OK, good. I will update XEP-0136 accordingly
>
> Done:
>
> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diff
>Mode=u&%40diffWrap=s&r1=2993&r2=3008&u=3&ignore=&k=
>
> Peter


From sachin at geodesic.com  Wed Apr  8 03:47:29 2009
From: sachin at geodesic.com (Sachin Khandelwal)
Date: Wed, 8 Apr 2009 14:17:29 +0530
Subject: [Standards] Corrections in XEP-0136
Message-ID: <200904081417.29710.sachin@geodesic.com>

Hi,

Suggesting two minor corrections in XEP-0136 :

1) In sec "10.1 Exact JID Matching" : 
In sentence 
a 'with' value such as "example.com" matches that exact JID only rather than 
<*@example.com>, <*@example.com>, or <example.com/*> 

the first two expression are same ( i.e. <*@example.com> ) . I guess
one of them should be <*@example.com/*>.


2) In the XML Schema, the definition of 'item' element states that all the 
three attributes - 'jid', 'otr', and 'save' are required. And the same 'item' 
is referred from 'itemremove' element which, as per Example 11, will only have 
jid attribute. So we need to define a saperate 'item' inside 'itemremove' which 
will only have 'jid' attribute, instead of referring the existing one.

Regards,

Sachin Khandelwal


From lists at ndl.kiev.ua  Wed Apr  8 04:10:24 2009
From: lists at ndl.kiev.ua (Alexander Tsvyashchenko)
Date: Wed, 08 Apr 2009 12:10:24 +0300
Subject: [Standards]
 =?utf-8?q?inconsistency_between_section_7=2E2_-_10=2E?=
 =?utf-8?q?2_in_XEP-0136_=3F?=
In-Reply-To: <200904081330.58424.sachin@geodesic.com>
References: <49404294.7070105@eaktion.com> <49DBC936.2000505@stpeter.im>
	<49DBCBCC.3090500@stpeter.im>
	<200904081330.58424.sachin@geodesic.com>
Message-ID: <6ee81fd0600900ac97d36cf497a6beff@ndl.kiev.ua>


Hello Sachin,

On Wed, 8 Apr 2009 13:30:58 +0530, Sachin Khandelwal <sachin at geodesic.com>
wrote:

> I feel it'll create inconsistency due to changes in section "7.1 and 7.2"
.
> As per section sec 4.5 the with attribute can be JID (not only full jid).
so
> due to this change, it'll not be possible retrieve the collections having
with 
> attribute as bare JID.

Not directly related to this particular change, but looks like you're right
that section 4.5 is a bit strange: it describes chat[@with], but talks
about "matching" - I believe it does not make sense in this context.

2Peter: does it make sense to remove "If the JID is of the form
<localpart at domain.tld>, any resource matches; if the JID is of the form
<domain.tld>, any node matches" paragraph from 4.5, as it describes 'with'
attribute of 'chat' element, not 'with' attribute of any command, so
there's no "matching" to talk about?

This paragraph might be moved to 10.1 section, for example: probably it
might be renamed from "Exact JID Matching" to "JID Matching" then and in
2.2.3.2, 7.1 and 7.3 all info about 'jid'/'with' meaning might be removed
and the link to "JID Matching" might be just given instead (yes, I'm a real
fan of DRY principle ;-) ) 7.2 will have slightly different wording
(discussed below) and 2.2.3.2 (or 2.2.3?) additionally might mention that
more specific JIDs settings override less specific ones.

As for the inconsistency: yes, recent change might introduce some
inconsistency, see below.

> One solution I think of is to keep sec "7.1 Retrieving a List of
Collections" 
> as it is and for sec. "7.2 Retrieving a Collection", remove the
'exactmatch' 
> attribute and the value of with attribute should always be exactly
matched
> by default.

Yes, I believe 'exactmatch' in '7.2' was left just by the accident and I
agree the wording should be slightly adjusted also.

2Peter: I would suggest the following further changes (that's basically
what Sachin says, I believe, just slightly more expanded):

 1. Remove 'In addition, the client MAY match an exact bare JID &BAREJID;
by setting the boolean 'exactmatch' attribute to a value of "true" or "1"
&BOOLEANNOTE; -- for details, refer to the <link
url='#impl-exactmatch'>Exact JID Matching</link> section of this document.'
paragraph from 7.2

 2. Move "Note: Collections are retrieved only based on the full JID ..."
from 7.1 to 7.2 (as it belongs there, not to the "retrieving a list of
collections") and rephrase it like "Note: the &lt;retrieve/&gt; shall not
possess the 'exactmatch' attribute, as exact JID matching (see the <link
url='#impl-exactmatch'>Exact JID Matching</link> section of this document)
is always implied for this command. This is done to prevent returning
multiple collections from the &lt;retrieve/&gt; command", as current
wording implies that only "full JIDs" might be specified, but in fact we
should enforce not "full JIDs" but "exact matching".

If you agree on changing 10.1 to become "JID Matching" instead of "Exact
JID Matching" the link and wording around it would be slightly different in
(2), but the idea is the same.

2Sachin: does it correspond to your suggestions?

-- 
Good luck!                                     Alexander

From sachin at geodesic.com  Wed Apr  8 04:52:43 2009
From: sachin at geodesic.com (Sachin Khandelwal)
Date: Wed, 8 Apr 2009 15:22:43 +0530
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
	XEP-0136 ?
In-Reply-To: <6ee81fd0600900ac97d36cf497a6beff@ndl.kiev.ua>
References: <49404294.7070105@eaktion.com>
	<200904081330.58424.sachin@geodesic.com>
	<6ee81fd0600900ac97d36cf497a6beff@ndl.kiev.ua>
Message-ID: <200904081522.43346.sachin@geodesic.com>

Hi,

> 2Sachin: does it correspond to your suggestions?
yeah, I also feel its better to have JID Matching section.

Regards,

Sachin Khandelwal

On Wednesday 08 April 2009 14:40:24 Alexander Tsvyashchenko wrote:
> Hello Sachin,
>
> On Wed, 8 Apr 2009 13:30:58 +0530, Sachin Khandelwal <sachin at geodesic.com>
>
> wrote:
> > I feel it'll create inconsistency due to changes in section "7.1 and 7.2"
>
> .
>
> > As per section sec 4.5 the with attribute can be JID (not only full jid).
>
> so
>
> > due to this change, it'll not be possible retrieve the collections having
>
> with
>
> > attribute as bare JID.
>
> Not directly related to this particular change, but looks like you're right
> that section 4.5 is a bit strange: it describes chat[@with], but talks
> about "matching" - I believe it does not make sense in this context.
>
> 2Peter: does it make sense to remove "If the JID is of the form
> <localpart at domain.tld>, any resource matches; if the JID is of the form
> <domain.tld>, any node matches" paragraph from 4.5, as it describes 'with'
> attribute of 'chat' element, not 'with' attribute of any command, so
> there's no "matching" to talk about?
>
> This paragraph might be moved to 10.1 section, for example: probably it
> might be renamed from "Exact JID Matching" to "JID Matching" then and in
> 2.2.3.2, 7.1 and 7.3 all info about 'jid'/'with' meaning might be removed
> and the link to "JID Matching" might be just given instead (yes, I'm a real
> fan of DRY principle ;-) ) 7.2 will have slightly different wording
> (discussed below) and 2.2.3.2 (or 2.2.3?) additionally might mention that
> more specific JIDs settings override less specific ones.
>
> As for the inconsistency: yes, recent change might introduce some
> inconsistency, see below.
>
> > One solution I think of is to keep sec "7.1 Retrieving a List of
>
> Collections"
>
> > as it is and for sec. "7.2 Retrieving a Collection", remove the
>
> 'exactmatch'
>
> > attribute and the value of with attribute should always be exactly
>
> matched
>
> > by default.
>
> Yes, I believe 'exactmatch' in '7.2' was left just by the accident and I
> agree the wording should be slightly adjusted also.
>
> 2Peter: I would suggest the following further changes (that's basically
> what Sachin says, I believe, just slightly more expanded):
>
>  1. Remove 'In addition, the client MAY match an exact bare JID &BAREJID;
> by setting the boolean 'exactmatch' attribute to a value of "true" or "1"
> &BOOLEANNOTE; -- for details, refer to the <link
> url='#impl-exactmatch'>Exact JID Matching</link> section of this document.'
> paragraph from 7.2
>
>  2. Move "Note: Collections are retrieved only based on the full JID ..."
> from 7.1 to 7.2 (as it belongs there, not to the "retrieving a list of
> collections") and rephrase it like "Note: the &lt;retrieve/&gt; shall not
> possess the 'exactmatch' attribute, as exact JID matching (see the <link
> url='#impl-exactmatch'>Exact JID Matching</link> section of this document)
> is always implied for this command. This is done to prevent returning
> multiple collections from the &lt;retrieve/&gt; command", as current
> wording implies that only "full JIDs" might be specified, but in fact we
> should enforce not "full JIDs" but "exact matching".
>
> If you agree on changing 10.1 to become "JID Matching" instead of "Exact
> JID Matching" the link and wording around it would be slightly different in
> (2), but the idea is the same.
>
> 2Sachin: does it correspond to your suggestions?


From xramtsov at gmail.com  Wed Apr  8 04:56:48 2009
From: xramtsov at gmail.com (Evgeniy Khramtsov)
Date: Wed, 08 Apr 2009 19:56:48 +1000
Subject: [Standards] UPDATED: XEP-0264 (File Transfer Thumbnails)
In-Reply-To: <E1LqzM7-0003fS-00@apollo>
References: <E1LqzM7-0003fS-00@apollo>
Message-ID: <49DC74E0.5030704@gmail.com>

XMPP Extensions Editor wrote:
> Version 0.2 of XEP-0264 (File Transfer Thumbnails) has been released.
>
> Abstract: This specification defines a way for a client supply a preview image for a file transfer.
>
> Changelog: Add paragraph in security section about protecting agains malicious thumbnail dimensions in offer. Fixed a typo. (ml)
>
> Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0264.xml?%40diffMode=u&%40diffWrap=s&r1=2962&r2=3000&u=3&ignore=&k=
>
> URL: http://xmpp.org/extensions/xep-0264.html
>   

Useful XEP. I believe it will not be retracted. I really need to 
implement it.

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.


From elmex at x-paste.de  Wed Apr  8 05:21:51 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Wed, 8 Apr 2009 12:21:51 +0200
Subject: [Standards] unavailable presence from bare JID
Message-ID: <20090408102151.GA4212@elmex2>

Hi!

I've recently stumbled across unavailable presence stanzas on s2s connections
as replies to probes:

   <presence from="bare at jid" to="..." type="unavailable" />

RFC 3921 (bis) doesn't explicitly disallow this, and jabberd2 seems to generate
these unavailable presences. How is a client supposed to handle it in case
it has received available presence from some resources before, eg. like this:

   <presence from="test at example.net/bla" type="available" />
   <presence from="test at example.net/foo" type="available" />

And then receives:

   <presence from="test at example.net" type="unavailable" />

Should the client assume that the resources 'bla' and 'foo' are offline now?


Greetings,
   Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

From stpeter at stpeter.im  Wed Apr  8 06:54:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 05:54:55 -0600
Subject: [Standards] UPDATED: XEP-0264 (File Transfer Thumbnails)
In-Reply-To: <49DC74E0.5030704@gmail.com>
References: <E1LqzM7-0003fS-00@apollo> <49DC74E0.5030704@gmail.com>
Message-ID: <49DC908F.8050302@stpeter.im>

On 4/8/09 3:56 AM, Evgeniy Khramtsov wrote:
> XMPP Extensions Editor wrote:
>> Version 0.2 of XEP-0264 (File Transfer Thumbnails) has been released.
>>
>> Abstract: This specification defines a way for a client supply a
>> preview image for a file transfer.
>>
>> Changelog: Add paragraph in security section about protecting agains
>> malicious thumbnail dimensions in offer. Fixed a typo. (ml)
>>
>> Diff:
>> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0264.xml?%40diffMode=u&%40diffWrap=s&r1=2962&r2=3000&u=3&ignore=&k=
>>
>>
>> URL: http://xmpp.org/extensions/xep-0264.html
>>   
> 
> Useful XEP. I believe it will not be retracted. I really need to
> implement it.
> 

Kopete does something very similar using an older namespace (not bits of
binary). It would be cool for someone to update that. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/26bd7060/attachment.bin 

From stpeter at stpeter.im  Wed Apr  8 06:58:32 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 05:58:32 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <20090408102151.GA4212@elmex2>
References: <20090408102151.GA4212@elmex2>
Message-ID: <49DC9168.7010506@stpeter.im>

On 4/8/09 4:21 AM, Robin Redeker wrote:
> Hi!
> 
> I've recently stumbled across unavailable presence stanzas on s2s connections
> as replies to probes:
> 
>    <presence from="bare at jid" to="..." type="unavailable" />
> 
> RFC 3921 (bis) doesn't explicitly disallow this, and jabberd2 seems to generate
> these unavailable presences. How is a client supposed to handle it in case
> it has received available presence from some resources before, eg. like this:
> 
>    <presence from="test at example.net/bla" type="available" />
>    <presence from="test at example.net/foo" type="available" />
> 
> And then receives:
> 
>    <presence from="test at example.net" type="unavailable" />
> 
> Should the client assume that the resources 'bla' and 'foo' are offline now?

I think that presence about a bare JID is meaningless.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/9a47ad0b/attachment.bin 

From js-xmpp-standards at webkeks.org  Wed Apr  8 07:00:56 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Wed, 8 Apr 2009 14:00:56 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DC9168.7010506@stpeter.im>
References: <20090408102151.GA4212@elmex2>
	<49DC9168.7010506@stpeter.im>
Message-ID: <20090408140056.69154906@webkeks.org>

Peter Saint-Andre <stpeter at stpeter.im> wrote:

> I think that presence about a bare JID is meaningless.

It's useful when you know you missed some presences due to s2s being
broken. You can send a presence probe and if you got an unavailable
presence, you know that all resources are offline now. But that won't
help: It's not standarized, so you can't rely on that. The only thing
you can do is show all resources as offline, send a presence probe and
show them as online again once you got a reply.

-- 
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/dccd9c8c/attachment.pgp 

From dave at cridland.net  Wed Apr  8 07:36:23 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 08 Apr 2009 13:36:23 +0100
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <20090408102151.GA4212@elmex2>
References: <20090408102151.GA4212@elmex2>
Message-ID: <30209.1239194183.231538@puncture>

On Wed Apr  8 11:21:51 2009, Robin Redeker wrote:
> Hi!
> 
> I've recently stumbled across unavailable presence stanzas on s2s  
> connections
> as replies to probes:
> 
>    <presence from="bare at jid" to="..." type="unavailable" />
> 
> 
Right, we hand those out too, whenever users are known to be offline.  
We'll also timestamp them, and include <status/>, if we have that  
information.

> RFC 3921 (bis) doesn't explicitly disallow this, and jabberd2 seems  
> to generate
> these unavailable presences. How is a client supposed to handle it  
> in case
> it has received available presence from some resources before, eg.  
> like this:
> 
>    <presence from="test at example.net/bla" type="available" />
>    <presence from="test at example.net/foo" type="available" />
> 
> And then receives:
> 
>    <presence from="test at example.net" type="unavailable" />
> 
> Should the client assume that the resources 'bla' and 'foo' are  
> offline now?

Interesting... Yes, probably...

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From ml at update.uu.se  Wed Apr  8 07:54:48 2009
From: ml at update.uu.se (Marcus Lundblad)
Date: Wed, 08 Apr 2009 14:54:48 +0200
Subject: [Standards] UPDATED: XEP-0264 (File Transfer Thumbnails)
In-Reply-To: <49DC908F.8050302@stpeter.im>
References: <E1LqzM7-0003fS-00@apollo> <49DC74E0.5030704@gmail.com>
	<49DC908F.8050302@stpeter.im>
Message-ID: <1239195288.4560.15.camel@localhost>

ons 2009-04-08 klockan 05:54 -0600 skrev Peter Saint-Andre:
> On 4/8/09 3:56 AM, Evgeniy Khramtsov wrote:
> > XMPP Extensions Editor wrote:
> >> Version 0.2 of XEP-0264 (File Transfer Thumbnails) has been released.
> >>
> >> Abstract: This specification defines a way for a client supply a
> >> preview image for a file transfer.
> >>
> >> Changelog: Add paragraph in security section about protecting agains
> >> malicious thumbnail dimensions in offer. Fixed a typo. (ml)
> >>
> >> Diff:
> >> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0264.xml?%40diffMode=u&%40diffWrap=s&r1=2962&r2=3000&u=3&ignore=&k=
> >>
> >>
> >> URL: http://xmpp.org/extensions/xep-0264.html
> >>   
> > 
> > Useful XEP. I believe it will not be retracted. I really need to
> > implement it.
> > 
> 
> Kopete does something very similar using an older namespace (not bits of
> binary). It would be cool for someone to update that. :)
> 
Yes, the difference is that Kopete's method works by checking for a
capability that the receiving client only advertises when willing to
receive a thumbnail. If it does, then the initiator includes the
Base64-encoded data directly in the file transfer offer, instead of as
proposed in this protocol, including a reference that is requested by
the receiver (if it wishes to) by means of BoB.

//Marcus

> Peter
> 



From fabio.forno at gmail.com  Wed Apr  8 09:15:41 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Wed, 8 Apr 2009 16:15:41 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DC9168.7010506@stpeter.im>
References: <20090408102151.GA4212@elmex2> <49DC9168.7010506@stpeter.im>
Message-ID: <2fd53c3a0904080715g727e89e6y6b5cc9cc3dca1be7@mail.gmail.com>

On Wed, Apr 8, 2009 at 1:58 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:

>> Should the client assume that the resources 'bla' and 'foo' are offline now?
>
> I think that presence about a bare JID is meaningless.
>

Many components send presence from [name@]component.domain without
resources. I've always interpreted that as the null resource (while
just "/" should be the resource with length zero) and treated it as if
it were a XMPP entity.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From stpeter at stpeter.im  Wed Apr  8 10:01:43 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 09:01:43 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <2fd53c3a0904080715g727e89e6y6b5cc9cc3dca1be7@mail.gmail.com>
References: <20090408102151.GA4212@elmex2> <49DC9168.7010506@stpeter.im>
	<2fd53c3a0904080715g727e89e6y6b5cc9cc3dca1be7@mail.gmail.com>
Message-ID: <49DCBC57.2010303@stpeter.im>

On 4/8/09 8:15 AM, Fabio Forno wrote:
> On Wed, Apr 8, 2009 at 1:58 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 
>>> Should the client assume that the resources 'bla' and 'foo' are offline now?
>> I think that presence about a bare JID is meaningless.
>>
> 
> Many components send presence from [name@]component.domain without
> resources. I've always interpreted that as the null resource (while
> just "/" should be the resource with length zero) and treated it as if
> it were a XMPP entity.
> 

I mean that concept of presence in relation to an entity whose service
discovery identity is "account/registered" doesn't tell you anything.
For (user) accounts, presence matters for connected resources, not the
bare account itself.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/cd021912/attachment.bin 

From stpeter at stpeter.im  Wed Apr  8 10:05:46 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 09:05:46 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <30209.1239194183.231538@puncture>
References: <20090408102151.GA4212@elmex2> <30209.1239194183.231538@puncture>
Message-ID: <49DCBD4A.3020901@stpeter.im>

On 4/8/09 6:36 AM, Dave Cridland wrote:
> On Wed Apr  8 11:21:51 2009, Robin Redeker wrote:
>> Hi!
>>
>> I've recently stumbled across unavailable presence stanzas on s2s
>> connections
>> as replies to probes:
>>
>>    <presence from="bare at jid" to="..." type="unavailable" />
>>
>>
> Right, we hand those out too, whenever users are known to be offline.
> We'll also timestamp them, and include <status/>, if we have that
> information.

Hmm, is this in response to a probe? That might make some sense, then.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/b9107271/attachment.bin 

From dave at cridland.net  Wed Apr  8 10:09:43 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 08 Apr 2009 16:09:43 +0100
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DCBD4A.3020901@stpeter.im>
References: <20090408102151.GA4212@elmex2>
	<30209.1239194183.231538@puncture> <49DCBD4A.3020901@stpeter.im>
Message-ID: <1093.1239203383.595726@puncture>

On Wed Apr  8 16:05:46 2009, Peter Saint-Andre wrote:
> Hmm, is this in response to a probe? That might make some sense,  
> then.

Yes, it's in response to a probe.

RFC 3920, 5.1.3, para 3, option (1).

Actually, we synthesize an empty type='unavailable' if we haven't got  
a "real" one stored, but that's a small point.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Wed Apr  8 10:30:28 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 09:30:28 -0600
Subject: [Standards] UPDATED: XEP-0198 (Stream Management)
In-Reply-To: <49DB5A8C.7090402@stpeter.im>
References: <E1LoSha-0003wC-00@apollo>	<2fd53c3a0903310507t40fc6a32k6d27a4292865329f@mail.gmail.com>	<49DAA6C1.8010008@stpeter.im>	<2fd53c3a0904062303l3c54bce5mc48cfd0a33d949@mail.gmail.com>
	<49DB5A8C.7090402@stpeter.im>
Message-ID: <49DCC314.4030707@stpeter.im>

On 4/7/09 7:52 AM, Peter Saint-Andre wrote:
> On 4/7/09 12:03 AM, Fabio Forno wrote:
>> On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>
>>>> S: <t xmlns='urn:xmpp:sm:1' max="n"/>
>>>>
>>>> It isn't perfect but it can work for most of the cases.
>>> Agreed. But what is the purpose of max="n" here?
>> It could be used to adjust the number of maximun number of outstanding
>> packets (When throttling it makes sense to reduce it)
> 
> Ah, I think that needs to be a 'stanzas' attribute. The 'max' attribute
> specifies the longest allowable time period for session resumption and
> the 'stanzas' attribute indicates the server's preferred maximum number
> of received stanzas between acks.
> 
> So:
> 
> <t xmlns='urn:xmpp:sm:1' stanzas="n"/>

We've concluded that the server can use <t stanzas='n'/> to inform the
client that it is throttled and to adjust the number of stanzas between
acks. While writing up a throttling scenario for the spec, I have
realized that the order of events might be something like this (let's
assume that the early messages are fairly large):

C: <enable/>
S: <enabled stanzas='10'/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
[throttling kicks in]
S: <t stanzas='3'/>
[client adjusts its expectations and requests an ack]
C: <r/>
[client still throttled, server ignores <r/>]
[30 seconds go by]
S: <t/>
C: <message/>
[30 seconds go by]
S: <t/>
C: <message/>
[backlog starts to ease, server adjusts 'stanzas' value???]
S: <t stanzas='5'/>
C: <message/>
C: <message/>
[server has handled the first 10 messages so it finally replies to <r/>]
S: <a h='10'/>

But how can the server inform the client that the 'stanzas' value has
gone back to 10? Perhaps we need to add the 'stanzas' attribute to the
<a/> element, too.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/d3799002/attachment.bin 

From stpeter at stpeter.im  Wed Apr  8 10:32:34 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 09:32:34 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <1093.1239203383.595726@puncture>
References: <20090408102151.GA4212@elmex2>	<30209.1239194183.231538@puncture>
	<49DCBD4A.3020901@stpeter.im> <1093.1239203383.595726@puncture>
Message-ID: <49DCC392.1040303@stpeter.im>

On 4/8/09 9:09 AM, Dave Cridland wrote:
> On Wed Apr  8 16:05:46 2009, Peter Saint-Andre wrote:
>> Hmm, is this in response to a probe? That might make some sense, then.
> 
> Yes, it's in response to a probe.
> 
> RFC 3920, 5.1.3, para 3, option (1).

Sorry, I thought people were talking about available presence from a
bare JID, not unavailable. I need to read more carefully. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/3a4182d9/attachment.bin 

From elmex at x-paste.de  Wed Apr  8 10:36:50 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Wed, 8 Apr 2009 17:36:50 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DCBD4A.3020901@stpeter.im>
References: <20090408102151.GA4212@elmex2> <30209.1239194183.231538@puncture>
	<49DCBD4A.3020901@stpeter.im>
Message-ID: <20090408153650.GA3730@kiste.laendle>

On Wed, Apr 08, 2009 at 09:05:46AM -0600, Peter Saint-Andre wrote:
> On 4/8/09 6:36 AM, Dave Cridland wrote:
> > On Wed Apr  8 11:21:51 2009, Robin Redeker wrote:
> >> Hi!
> >>
> >> I've recently stumbled across unavailable presence stanzas on s2s
> >> connections
> >> as replies to probes:
> >>
> >>    <presence from="bare at jid" to="..." type="unavailable" />
> >>
> >>
> > Right, we hand those out too, whenever users are known to be offline.
> > We'll also timestamp them, and include <status/>, if we have that
> > information.
> 
> Hmm, is this in response to a probe? That might make some sense, then.

It is sent response to a probe in jabberd2. But I'm wondering about the general
semantics of the unavailable presence from a bare JID of a contact (or even a
non-contact).

After thinking a bit more about presences I went into some other issues which I
didn't find explained in the RFC or didn't make sense to me:

1.

I'm also wondering about the general semantics of _available_ presence from a
bare JID, like discussed in another branch of this thread.

Imagine these presence stanzas are received by a client for contact a at b:

   <presence from="a at b/X" to="my at jid/myres"/>

   <presence from="a at b/Y" to="my at jid/myres">
      <priority>10</priority>
      <show>xa</show>
   </presence>

   <presence from="a at b" to="my at jid/myres">
      <show>away</show>
   </presence>

What should I display? Is the last presence from 'the "empty" resource'?  Empty
resources make no sense, as any resource's name must not be empty anyways (see
BNF in RFC 3920). But whats the alternative interpretation of presence from a
bare JID? Does it shadow any other presence? Is it guaranteed that a client will
not receive presence for a bare JID and full JID from the same contact?

If services send presence from bare JIDs, how should those be handled? What is
the meaning of <priority/> elements in those presences?

2.

Another question I got is:

   RFC 3921 bis
   4.5.4.  Client Processing of Inbound Unavailable Presence

   http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#presence-unavailable-client

   1. If the user is in the contact's roster, the client MUST display the
      unavailable presence information in an appropriate roster interface. 

Imagine that some contact was online with 2 resources which become
unavailable and send me their reason for becoming unavailable:

   <presence from="c at d/X" type="unavailable">
     <priority>20</priority>
     <status>Off for vacation.</status>
   </presence>

   <presence from="c at d/Y" type="unavailable">
     <priority>10</priority>
     <status>Off for picking girlfriend up.</status>
   </presence>

Ignore the contradicting offline status for now, but for which' of those should
I display the unavailable information? For both resources?  For the unavailable
presence which has been received most recently? Or for the unavailable presence
with the highest priority?

Lets assume the client should display the unavailable presence for _all_ resources
which went offline. Wouldn't that be inconsistent with presence probes where the
server returns unavailable information for only one resource? For this read:

   4.3.2.  Server Processing of Inbound Presence Probe 

   2. Else, if the contact has no available resources, the server SHOULD reply
   to the presence probe by sending to the user the full XML of the last presence
   stanza of type "unavailable" received by the server from the contact ...

This means a server only remembers the last received unavailable presence, but
a client _must_ display all unavailable presences it receives. That feels a bit
inconsistent to me. Also imagine what happens when people use random resources,
then the list of unavailable presences (which MUST be displayed
"appropriately") will grow indefinitely! Ok, this is maybe no "appropriate",
but what _IS_ actually appropriate in this case?



-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

From stpeter at stpeter.im  Wed Apr  8 10:40:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 09:40:55 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DCC392.1040303@stpeter.im>
References: <20090408102151.GA4212@elmex2>	<30209.1239194183.231538@puncture>	<49DCBD4A.3020901@stpeter.im>
	<1093.1239203383.595726@puncture> <49DCC392.1040303@stpeter.im>
Message-ID: <49DCC587.6090001@stpeter.im>

On 4/8/09 9:32 AM, Peter Saint-Andre wrote:
> On 4/8/09 9:09 AM, Dave Cridland wrote:
>> On Wed Apr  8 16:05:46 2009, Peter Saint-Andre wrote:
>>> Hmm, is this in response to a probe? That might make some sense, then.
>> Yes, it's in response to a probe.
>>
>> RFC 3920, 5.1.3, para 3, option (1).
> 
> Sorry, I thought people were talking about available presence from a
> bare JID, not unavailable. I need to read more carefully. :)

So the question is: now that my local server has received presence
unavailable from the remote server, does it send that information on to
my client? And, if so, what does my client do with that information? I
see no harm in passing it on the client (it is definitive information
about the contact's presence state), and IMHO the best way to process it
is to show this just like you'd show iq:last info.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/0a22d065/attachment.bin 

From fippo at goodadvice.pages.de  Wed Apr  8 11:18:32 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Wed, 08 Apr 2009 18:18:32 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DCC392.1040303@stpeter.im>
References: <20090408102151.GA4212@elmex2>	<30209.1239194183.231538@puncture>	<49DCBD4A.3020901@stpeter.im>
	<1093.1239203383.595726@puncture> <49DCC392.1040303@stpeter.im>
Message-ID: <49DCCE58.3020008@goodadvice.pages.de>

Peter Saint-Andre wrote:
> Sorry, I thought people were talking about available presence from a
> bare JID, not unavailable. I need to read more carefully. :)

And what is the problem with available presence from a bare jid?

From dave at cridland.net  Wed Apr  8 11:20:22 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 08 Apr 2009 17:20:22 +0100
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DCCE58.3020008@goodadvice.pages.de>
References: <20090408102151.GA4212@elmex2>
	<30209.1239194183.231538@puncture> <49DCBD4A.3020901@stpeter.im>
	<1093.1239203383.595726@puncture> <49DCC392.1040303@stpeter.im>
	<49DCCE58.3020008@goodadvice.pages.de>
Message-ID: <1093.1239207622.503660@puncture>

On Wed Apr  8 17:18:32 2009, Philipp Hancke wrote:
> Peter Saint-Andre wrote:
>> Sorry, I thought people were talking about available presence from  
>> a
>> bare JID, not unavailable. I need to read more carefully. :)
> 
> And what is the problem with available presence from a bare jid?

That's bare jid as in "Of a user's account", I suspect, not as in  
"the form node at domain" - any XMPP entity can, of course, have  
available presence, it just doesn't make sense for your account to.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From zarevucky.jiri at gmail.com  Wed Apr  8 11:25:48 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 8 Apr 2009 18:25:48 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <20090408153650.GA3730@kiste.laendle>
References: <20090408102151.GA4212@elmex2> <30209.1239194183.231538@puncture>
	<49DCBD4A.3020901@stpeter.im> <20090408153650.GA3730@kiste.laendle>
Message-ID: <e962983d0904080925k227b9588o54b376d760ff3469@mail.gmail.com>

2009/4/8 Robin Redeker <elmex at x-paste.de>:
> Imagine these presence stanzas are received by a client for contact a at b:
>
> ? <presence from="a at b/X" to="my at jid/myres"/>
>
> ? <presence from="a at b/Y" to="my at jid/myres">
> ? ? ?<priority>10</priority>
> ? ? ?<show>xa</show>
> ? </presence>
>
> ? <presence from="a at b" to="my at jid/myres">
> ? ? ?<show>away</show>
> ? </presence>
>
> What should I display? Is the last presence from 'the "empty" resource'? ?Empty
> resources make no sense, as any resource's name must not be empty anyways (see
> BNF in RFC 3920). But whats the alternative interpretation of presence from a
> bare JID? Does it shadow any other presence? Is it guaranteed that a client will
> not receive presence for a bare JID and full JID from the same contact?
>

Such behavior is clearly not correct. It deserves some clarification I guess.
I would handle it this way:

If it's available presence -> handle it normally as if the resource
was an empty string.
If it's unavailable presence -> consider all resources unavailable.
Handling of error presences is defined in the spec.

It's the best possible handling I think, since any entity sending
presence from full JID does that for the reason that it never needs
more resources.


>
> This means a server only remembers the last received unavailable presence, but
> a client _must_ display all unavailable presences it receives. That feels a bit
> inconsistent to me. Also imagine what happens when people use random resources,
> then the list of unavailable presences (which MUST be displayed
> "appropriately") will grow indefinitely! Ok, this is maybe no "appropriate",
> but what _IS_ actually appropriate in this case?
>
>

Again, that needs to be clarified. Most clients these days (as far as
I know) don't display unavailable presences in the roster, except the
last one. That is, you will display the status message in roster only
if it causes the contact itself to "go offline". Or does anyone handle
it differently?

From fippo at goodadvice.pages.de  Wed Apr  8 11:53:13 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Wed, 08 Apr 2009 18:53:13 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <1093.1239207622.503660@puncture>
References: <20090408102151.GA4212@elmex2>	<30209.1239194183.231538@puncture>
	<49DCBD4A.3020901@stpeter.im>	<1093.1239203383.595726@puncture>
	<49DCC392.1040303@stpeter.im>	<49DCCE58.3020008@goodadvice.pages.de>
	<1093.1239207622.503660@puncture>
Message-ID: <49DCD679.8080106@goodadvice.pages.de>

Dave Cridland wrote:
> On Wed Apr  8 17:18:32 2009, Philipp Hancke wrote:
>> Peter Saint-Andre wrote:
>>> Sorry, I thought people were talking about available presence from a
>>> bare JID, not unavailable. I need to read more carefully. :)
>>
>> And what is the problem with available presence from a bare jid?
> 
> That's bare jid as in "Of a user's account", I suspect, not as in "the 
> form node at domain" - any XMPP entity can, of course, have available 
> presence, it just doesn't make sense for your account to.

I am sending this for half a decade now and never encountered
(presence related) problems. But I never mix bare jid presence and
full jid presence of course.

Sending a random 1023 byte string in that place would be possible,
but I doubt it makes any more sense ;-)

philipp

From justin-keyword-jabber.093179 at affinix.com  Wed Apr  8 12:23:53 2009
From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges)
Date: Wed, 8 Apr 2009 10:23:53 -0700
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <20090408153650.GA3730@kiste.laendle>
References: <20090408102151.GA4212@elmex2> <49DCBD4A.3020901@stpeter.im>
	<20090408153650.GA3730@kiste.laendle>
Message-ID: <200904081023.53460.justin-keyword-jabber.093179@affinix.com>

On Wednesday 08 April 2009 08:36:50 Robin Redeker wrote:
> I'm also wondering about the general semantics of _available_ presence from
> a bare JID, like discussed in another branch of this thread.
>
> Imagine these presence stanzas are received by a client for contact a at b:
>
>    <presence from="a at b/X" to="my at jid/myres"/>
>
>    <presence from="a at b/Y" to="my at jid/myres">
>       <priority>10</priority>
>       <show>xa</show>
>    </presence>
>
>    <presence from="a at b" to="my at jid/myres">
>       <show>away</show>
>    </presence>
>
> What should I display? Is the last presence from 'the "empty" resource'? 
> Empty resources make no sense, as any resource's name must not be empty
> anyways (see BNF in RFC 3920). But whats the alternative interpretation of
> presence from a bare JID? Does it shadow any other presence? Is it
> guaranteed that a client will not receive presence for a bare JID and full
> JID from the same contact?

I don't think this was ever fully specified, but we have a decade of history 
where regular Jabber contacts have been using resources and transport 
contacts have not, and so clients have had to deal with the discrepancy.  
Since about 2002, Psi has supported multiple resources, and presence from a 
JID without a resource is treated as if there is a resource whose value is 
empty.  In the Psi UI, you would see the resources for a at b as "X", "Y", 
and "[blank]".

You might be able to get away with an empty resource overshadowing all 
non-empty ones, and any non-empty one overshadowing an empty one, whichever 
is received most recently, under the assumption that the two approaches would 
never be mixed.  However, I feel being able to support empty and non-empty 
side-by-side for the same bare JID is the safest approach in a client.  For 
better or worse, I think empty resources are a de facto standard we're stuck 
with.

-Justin

From stpeter at stpeter.im  Wed Apr  8 14:54:41 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 13:54:41 -0600
Subject: [Standards] [Fwd: [Council] meeting minutes, 2009-04-08]
Message-ID: <49DD0101.10803@stpeter.im>

FYI.

-------- Original Message --------
Subject: [Council] meeting minutes, 2009-04-08
Date: Wed, 08 Apr 2009 13:53:00 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Council <council at xmpp.org>
To: XMPP Council <council at xmpp.org>

Results of the XMPP Council meeting held 2009-04-08...

Agenda:

http://xmpp.org/council/agendas/2009-04-08.html

Log:

http://logs.jabber.org/council at conference.jabber.org/2009-04-08.html

Scribe: Peter Saint-Andre

0. Roll call

Present: Dave Cridland, Ralph Meijer, Jack Moffitt, Peter Saint-Andre,
Kevin Smith.

Quorum achieved.

1. Agenda bashing

None.

2. Jingle

Consensus to issue a final Last Call regarding XEPs 166, 167, 176, and
177 in order to ensure agreement regarding changes resulting from the
Jingle Thingle.

3. Calendaring Extensions to Publish-Subscribe

Lengthy discussion of the proposal, feedback from Cyrus Daboo, etc.
Consensus that full calendaring is a large, complex topic and probably
outside the XSF's areas of expertise. Cyrus suggested several other
features that could be defined in XMPP and provide assistance to core
calendaring efforts:

- Meeting alarm notifications

- WedDAV change notifications (cf. draft-hildebrand-webdav-notify)

- Calendar synchronization ? la ActiveSync

The Council also discussed the possibility of publishing free/busy
information via PEP.

Rough consensus that it would be productive to work on these topics
(rather than full calendaring over XMPP); proposals are welcome.

4. Roster Versioning

Consensus to issue a Last Call.

5. Codecs for Jingle RTP Sessions

Consensus to publish as a XEP.

6. Other business

None.

7. Next meeting.

April 22, 2009.

/psa




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/809139a7/attachment.bin 

From editor at xmpp.org  Wed Apr  8 15:02:07 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 08 Apr 2009 15:02:07 -0500
Subject: [Standards] NEW: XEP-0266 (Codecs for Jingle RTP Sessions)
Message-ID: <E1LrdyJ-0003xR-00@apollo>

Version 0.1 of XEP-0266 (Codecs for Jingle RTP Sessions) has been released.

Abstract: This document describes implementation considerations related to voice and video codecs for use in Jingle RTP sessions.

Changelog: Initial published version. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0266.html


From editor at xmpp.org  Wed Apr  8 15:04:40 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 08 Apr 2009 15:04:40 -0500
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
Message-ID: <E1Lre0m-0003z0-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0237 (Roster Versioning).

Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not changed, thus saving bandwidth during session establishment.

URL: http://www.xmpp.org/extensions/xep-0237.html

This Last Call begins today and shall end at the close of business on 2009-04-21.

Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

From mridulm80 at yahoo.com  Wed Apr  8 16:30:14 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 03:00:14 +0530 (IST)
Subject: [Standards] unavailable presence from bare JID
Message-ID: <972974.83279.qm@web95401.mail.in2.yahoo.com>




I am not sure what an empty resource means in context of available presence from a user - since you cant bind to an empty resource for a user : so what is the user expectation on seeing something like that in psi ?

Whether server allows a client to send presence with 'from' set to something other than its own full jid - usually a client does not need to set the from in first place : and iirc the server I worked on always used to remove the from and set it appropriately (full jid for presence update/broadcast, bare jid for subscription responses).


The only case 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 <justin-keyword-jabber.093179 at affinix.com> wrote:

> From: Justin Karneges <justin-keyword-jabber.093179 at affinix.com>
> Subject: Re: [Standards] unavailable presence from bare JID
> To: "XMPP Standards" <standards at xmpp.org>
> Date: Wednesday, 8 April, 2009, 10:53 PM
> On Wednesday 08 April 2009 08:36:50
> Robin Redeker wrote:
> > I'm also wondering about the general semantics of
> _available_ presence from
> > a bare JID, like discussed in another branch of this
> thread.
> >
> > Imagine these presence stanzas are received by a
> client for contact a at b:
> >
> >? ? <presence from="a at b/X"
> to="my at jid/myres"/>
> >
> >? ? <presence from="a at b/Y"
> to="my at jid/myres">
> >? ?
> ???<priority>10</priority>
> >? ?
> ???<show>xa</show>
> >? ? </presence>
> >
> >? ? <presence from="a at b"
> to="my at jid/myres">
> >? ?
> ???<show>away</show>
> >? ? </presence>
> >
> > What should I display? Is the last presence from 'the
> "empty" resource'? 
> > Empty resources make no sense, as any resource's name
> must not be empty
> > anyways (see BNF in RFC 3920). But whats the
> alternative interpretation of
> > presence from a bare JID? Does it shadow any other
> presence? Is it
> > guaranteed that a client will not receive presence for
> a bare JID and full
> > JID from the same contact?
> 
> I don't think this was ever fully specified, but we have a
> decade of history 
> where regular Jabber contacts have been using resources and
> transport 
> contacts have not, and so clients have had to deal with the
> discrepancy.? 
> Since about 2002, Psi has supported multiple resources, and
> presence from a 
> JID without a resource is treated as if there is a resource
> whose value is 
> empty.? In the Psi UI, you would see the resources for
> a at b as "X", "Y", 
> and "[blank]".
> 
> You might be able to get away with an empty resource
> overshadowing all 
> non-empty ones, and any non-empty one overshadowing an
> empty one, whichever 
> is received most recently, under the assumption that the
> two approaches would 
> never be mixed.? However, I feel being able to support
> empty and non-empty 
> side-by-side for the same bare JID is the safest approach
> in a client.? For 
> better or worse, I think empty resources are a de facto
> standard we're stuck 
> with.
> 
> -Justin
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From stpeter at stpeter.im  Wed Apr  8 16:47:13 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 15:47:13 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <972974.83279.qm@web95401.mail.in2.yahoo.com>
References: <972974.83279.qm@web95401.mail.in2.yahoo.com>
Message-ID: <49DD1B61.60305@stpeter.im>

On 4/8/09 3:30 PM, Mridul Muralidharan wrote:
> 
> 
> I am not sure what an empty resource means in context of available
> presence from a user - since you cant bind to an empty resource for a
> user : so what is the user expectation on seeing something like that
> in psi ?
> 
> Whether server allows a client to send presence with 'from' set to
> something other than its own full jid - usually a client does not
> need to set the from in first place : and iirc the server I worked on
> always used to remove the from and set it appropriately (full jid for
> presence update/broadcast, bare jid for subscription responses).
> 
> 
> The only case 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.

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/e7c16a21/attachment.bin 

From justin-keyword-jabber.093179 at affinix.com  Wed Apr  8 17:11:12 2009
From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges)
Date: Wed, 8 Apr 2009 15:11:12 -0700
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <972974.83279.qm@web95401.mail.in2.yahoo.com>
References: <972974.83279.qm@web95401.mail.in2.yahoo.com>
Message-ID: <200904081511.12443.justin-keyword-jabber.093179@affinix.com>

On Wednesday 08 April 2009 14:30:14 Mridul Muralidharan wrote:
> I am not sure what an empty resource means in context of available presence
> from a user - since you cant bind to an empty resource for a user : so what
> is the user expectation on seeing something like that in psi ?

No XMPP server would allow you to log in with an empty resource.

However, transport contacts often have no resource.  These are not real logged 
in XMPP clients, but faked contacts from a server component.  You will get 
<presence from='screenname at aim.transport'/> and have to deal with it.

-Justin

From editor at xmpp.org  Wed Apr  8 17:18:07 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 08 Apr 2009 17:18:07 -0500
Subject: [Standards] UPDATED: XEP-0167 (Jingle RTP Sessions)
Message-ID: <E1Lrg5v-0005J1-00@apollo>

Version 0.30 of XEP-0167 (Jingle RTP Sessions) has been released.

Abstract: This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.

Changelog: Further adjusted session flows for two scenarios scenario; added unhold and unmute messages. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0167.xml?%40diffMode=u&%40diffWrap=s&r1=2927&r2=3023&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0167.html


From editor at xmpp.org  Wed Apr  8 17:25:21 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 08 Apr 2009 17:25:21 -0500
Subject: [Standards] LAST CALL: XEP-0166 (Jingle)
Message-ID: <E1LrgCv-0005Nk-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0166 (Jingle).

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 pluggable model that enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat, file transfer) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).

URL: http://www.xmpp.org/extensions/xep-0166.html

This Last Call begins today and shall end at the close of business on 2009-04-30.

Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

From editor at xmpp.org  Wed Apr  8 17:25:27 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 08 Apr 2009 17:25:27 -0500
Subject: [Standards] LAST CALL: XEP-0167 (Jingle RTP Sessions)
Message-ID: <E1LrgD1-0005Nu-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0167 (Jingle RTP Sessions).

Abstract: This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.

URL: http://www.xmpp.org/extensions/xep-0167.html

This Last Call begins today and shall end at the close of business on 2009-04-30.

Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

From editor at xmpp.org  Wed Apr  8 17:25:33 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 08 Apr 2009 17:25:33 -0500
Subject: [Standards] LAST CALL: XEP-0176 (Jingle ICE-UDP Transport Method)
Message-ID: <E1LrgD7-0005O4-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0176 (Jingle ICE-UDP Transport Method).

Abstract: This specification defines a Jingle transport method that results in sending media data using raw datagram associations via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology, which provides robust NAT traversal for media traffic.

URL: http://www.xmpp.org/extensions/xep-0176.html

This Last Call begins today and shall end at the close of business on 2009-04-30.

Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

From editor at xmpp.org  Wed Apr  8 17:25:39 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 08 Apr 2009 17:25:39 -0500
Subject: [Standards] LAST CALL: XEP-0177 (Jingle Raw UDP Transport Method)
Message-ID: <E1LrgDD-0005OE-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0177 (Jingle Raw UDP Transport Method).

Abstract: This specification defines a Jingle transport method that results in sending media data using raw datagram associations via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required.

URL: http://www.xmpp.org/extensions/xep-0177.html

This Last Call begins today and shall end at the close of business on 2009-04-30.

Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

From stpeter at stpeter.im  Wed Apr  8 18:08:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 17:08:22 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <200904081023.53460.justin-keyword-jabber.093179@affinix.com>
References: <20090408102151.GA4212@elmex2>
	<49DCBD4A.3020901@stpeter.im>	<20090408153650.GA3730@kiste.laendle>
	<200904081023.53460.justin-keyword-jabber.093179@affinix.com>
Message-ID: <49DD2E66.4080008@stpeter.im>

On 4/8/09 11:23 AM, Justin Karneges wrote:
> On Wednesday 08 April 2009 08:36:50 Robin Redeker wrote:
>> I'm also wondering about the general semantics of _available_ presence from
>> a bare JID, like discussed in another branch of this thread.
>>
>> Imagine these presence stanzas are received by a client for contact a at b:
>>
>>    <presence from="a at b/X" to="my at jid/myres"/>
>>
>>    <presence from="a at b/Y" to="my at jid/myres">
>>       <priority>10</priority>
>>       <show>xa</show>
>>    </presence>
>>
>>    <presence from="a at b" to="my at jid/myres">
>>       <show>away</show>
>>    </presence>
>>
>> What should I display? Is the last presence from 'the "empty" resource'? 
>> Empty resources make no sense, as any resource's name must not be empty
>> anyways (see BNF in RFC 3920). But whats the alternative interpretation of
>> presence from a bare JID? Does it shadow any other presence? Is it
>> guaranteed that a client will not receive presence for a bare JID and full
>> JID from the same contact?
> 
> I don't think this was ever fully specified, but we have a decade of history 
> where regular Jabber contacts have been using resources and transport 
> contacts have not, and so clients have had to deal with the discrepancy.  
> Since about 2002, Psi has supported multiple resources, and presence from a 
> JID without a resource is treated as if there is a resource whose value is 
> empty.  In the Psi UI, you would see the resources for a at b as "X", "Y", 
> and "[blank]".
> 
> You might be able to get away with an empty resource overshadowing all 
> non-empty ones, and any non-empty one overshadowing an empty one, whichever 
> is received most recently, under the assumption that the two approaches would 
> never be mixed.  However, I feel being able to support empty and non-empty 
> side-by-side for the same bare JID is the safest approach in a client.  For 
> better or worse, I think empty resources are a de facto standard we're stuck 
> with.

I don't like the idea of "overshadowing", but you're right that presence
from a bare JID would indicate some sort of availability. That has no
impact on messaging (no full JID to send to) and I don't know how
clients handle service discovery in this case. In fact I suppose someday
(not anytime soon!) some people might want to get rid of resource
entirely, but that'll happen in XMPP 2.0 after I've retired. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090408/f2cf9752/attachment-0001.bin 

From sachin at geodesic.com  Thu Apr  9 01:54:55 2009
From: sachin at geodesic.com (Sachin Khandelwal)
Date: Thu, 9 Apr 2009 12:24:55 +0530
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <E1Lre0m-0003z0-00@apollo>
References: <E1Lre0m-0003z0-00@apollo>
Message-ID: <200904091224.55856.sachin@geodesic.com>

Hi,

Addition of this feature is highly appreciated.
There is a small issue which will occur in rare scenario : 

In sec 2.4, "Example 4. Roster result with no items"

<iq from='romeo at montague.lit' id='r1' to='romeo at montague.lit/home' 
type='result'>
  <query xmlns='jabber:iq:roster' ver='317'>
</iq>

The above example is for the case when server will send the individual roster 
pushes for the changes rather then sending the complete roster. But the server 
will return the same response (while returning complete roster) when user has 
deleted all the rosteritems present previous version (say 316).

Also a minor correction is the 'query' element in the above example is not 
closed.

Regards,

Sachin Khandelwal


On Thursday 09 April 2009 01:34:40 XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0237
> (Roster Versioning).
>
> Abstract: This specification defines a proposed modification to the XMPP
> roster protocol that enables versioning of rosters such that the server
> will not send the roster to the client if the roster has not changed, thus
> saving bandwidth during session establishment.
>
> URL: http://www.xmpp.org/extensions/xep-0237.html
>
> This Last Call begins today and shall end at the close of business on
> 2009-04-21.
>
> Please consider the following questions during this Last Call and send your
> feedback to the standards at xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or
> to clarify an existing protocol? 2. Does the specification solve the
> problem stated in the introduction and requirements? 3. Do you plan to
> implement this specification in your code? If not, why not? 4. Do you have
> any security concerns related to this specification? 5. Is the
> specification accurate and clearly written?
>
> Your feedback is appreciated!


From fabio.forno at gmail.com  Thu Apr  9 03:46:39 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Thu, 9 Apr 2009 10:46:39 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <49DD2E66.4080008@stpeter.im>
References: <20090408102151.GA4212@elmex2> <49DCBD4A.3020901@stpeter.im>
	<20090408153650.GA3730@kiste.laendle>
	<200904081023.53460.justin-keyword-jabber.093179@affinix.com>
	<49DD2E66.4080008@stpeter.im>
Message-ID: <2fd53c3a0904090146t56b30b77l6e65dd055baac3d1@mail.gmail.com>

On Thu, Apr 9, 2009 at 1:08 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:

In fact I suppose someday
> (not anytime soon!) some people might want to get rid of resource
> entirely, but that'll happen in XMPP 2.0 after I've retired. :)

we are already discouraging them with eco xmpp :D

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From js-xmpp-standards at webkeks.org  Thu Apr  9 04:25:15 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Thu, 9 Apr 2009 11:25:15 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <200904081511.12443.justin-keyword-jabber.093179@affinix.com>
References: <972974.83279.qm@web95401.mail.in2.yahoo.com>
	<200904081511.12443.justin-keyword-jabber.093179@affinix.com>
Message-ID: <71D79F57-D6BF-4E1E-BB27-D1B6D265C0DB@webkeks.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Am 09.04.2009 um 00:11 schrieb Justin Karneges:

> However, transport contacts often have no resource.  These are not  
> real logged
> in XMPP clients, but faked contacts from a server component.  You  
> will get
> <presence from='screenname at aim.transport'/> and have to deal with it.


You usually get presence from screenname at foo.transport/ - so it's not  
a bare JID, but a JID with empty resource. At least, I haven't seen  
getting presence from a bare JID so far.

- --
Jonathan

-----BEGIN PGP SIGNATURE-----

iQIcBAEBAwAGBQJJ3b77AAoJEMtRg9d5cXHkbEgP/RIYaYO1HaP7fzdtHmrHyi96
yKcF41hwEXTUqGYNGILfipRATcPcpJB7hJhQs/oi5dJeh3bEVTrBlan89CTtKhrP
7zauMP72HDUw4PQXtlsZFXgDcD9GfMzIgTVsOk3EgxexefCY8G9MphAUtp16Jusu
rybb6H4Xr2OecdPgDTJTECd59DzTWCGzyujYTSKxKYV7ozRUl/pPKJnBJrXpEppo
hlfSjI97WW3KH9MyK6Jlx6nWnZOtCEg6dXJ0fTIue4K5etKszVqvf9e013upMoxh
JKeNr6C7ZBcaVxVWL6mv97bg55bXOAg/wP3y0lrdC31QQSdTlK2phNDnOdE7B+I4
BZLf/xgF0TGDkGEc/Q9SHH3LFhsyY+CstFatgsoF+TuQJVPYloJqIJ/hzSXO+EFp
G4V1fhCILoHSq1l3D0usoYos7GiVg46l1vp9OFEGHPZYvkCnsZgE+rXOgGbsQe3R
c0jkQ60aSYgELDFdomWTpb9FM1W+bPrq2HUs5vQGEquXKngkqHPt5dFZeoa4uzQ2
HJZkgxwlpMpspVTp/tzpKVf3NOpT6MmeNi9T7dvVomevDiG8vqnmhqmLFO/T5dFU
cTx/xTI4vXmnDPlxbHyLFk/2P8Ffn+H5ABrRd0CaRVmpOUKtPB2eZ8a7xVGDBB9k
fcTpU1sW+1Q4P0lOPWgx
=MbAW
-----END PGP SIGNATURE-----

From elmex at x-paste.de  Thu Apr  9 06:05:28 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Thu, 9 Apr 2009 13:05:28 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <71D79F57-D6BF-4E1E-BB27-D1B6D265C0DB@webkeks.org>
References: <972974.83279.qm@web95401.mail.in2.yahoo.com>
	<200904081511.12443.justin-keyword-jabber.093179@affinix.com>
	<71D79F57-D6BF-4E1E-BB27-D1B6D265C0DB@webkeks.org>
Message-ID: <20090409110528.GA8206@elmex2>

On Thu, Apr 09, 2009 at 11:25:15AM +0200, Jonathan Schleifer wrote:
> Am 09.04.2009 um 00:11 schrieb Justin Karneges:
> 
> > However, transport contacts often have no resource.  These are not  
> > real logged
> > in XMPP clients, but faked contacts from a server component.  You  
> > will get
> > <presence from='screenname at aim.transport'/> and have to deal with it.
> 
> 
> You usually get presence from screenname at foo.transport/ - so it's not  

_that_ would be even worse than a bare JID, as the resource part MUST NOT
be empty. A resource string is always at least 1 character long.

> a bare JID, but a JID with empty resource. At least, I haven't seen  
> getting presence from a bare JID so far.


Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

From js-xmpp-standards at webkeks.org  Thu Apr  9 06:07:41 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Thu, 9 Apr 2009 13:07:41 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <20090409110528.GA8206@elmex2>
References: <972974.83279.qm@web95401.mail.in2.yahoo.com>
	<200904081511.12443.justin-keyword-jabber.093179@affinix.com>
	<71D79F57-D6BF-4E1E-BB27-D1B6D265C0DB@webkeks.org>
	<20090409110528.GA8206@elmex2>
Message-ID: <20090409130741.7afbdf9a@webkeks.org>

Robin Redeker <elmex at x-paste.de> wrote:

> _that_ would be even worse than a bare JID, as the resource part MUST
> NOT be empty. A resource string is always at least 1 character long.

I disagree. Having an empty C string as a resource is most of the time
a smaller issue than having it NULL because it's missing entirely.
And having an available presence from a bare JID is completely
undefined, whereas from a resource is defined. So, this would be only a
violation of the naming policies for resources, but not trigger
undefined behaviour.

-- 
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/905d9307/attachment.pgp 

From mridulm80 at yahoo.com  Thu Apr  9 06:16:32 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 16:46:32 +0530 (IST)
Subject: [Standards] unavailable presence from bare JID
Message-ID: <594682.75698.qm@web95403.mail.in2.yahoo.com>




--- On Thu, 9/4/09, Justin Karneges <justin-keyword-jabber.093179 at affinix.com> wrote:

> From: Justin Karneges <justin-keyword-jabber.093179 at affinix.com>
> Subject: Re: [Standards] unavailable presence from bare JID
> To: "XMPP Standards" <standards at xmpp.org>
> Date: Thursday, 9 April, 2009, 3:41 AM
> On Wednesday 08 April 2009 14:30:14
> Mridul Muralidharan wrote:
> > I am not sure what an empty resource means in context
> of available presence
> > from a user - since you cant bind to an empty resource
> for a user : so what
> > is the user expectation on seeing something like that
> in psi ?
> 
> No XMPP server would allow you to log in with an empty
> resource.
> 
> However, transport contacts often have no resource.?
> These are not real logged 
> in XMPP clients, but faked contacts from a server
> component.? You will get 
> <presence from='screenname at aim.transport'/>
> and have to deal with it.


You are right, you can/will get non-unavailable presence with from as barejid from components (and so I tried to carefully word it as user in my mail :-) ).
That being said, before you receive the presence, the client would know that the bare jid corresponds to a component right ? IIRC the presence received is in response to client action (subsequent to disco, etc) - any time this is not the case ?


So the split is not so much between bare jid and full jid - but between components and users.
Components can have bare jid available presence, while users cant.

Or did I misunderstand something ?

Thanks,
Mridul


> 
> -Justin
> 


      From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/


From mwild1 at gmail.com  Thu Apr  9 07:39:57 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Thu, 9 Apr 2009 13:39:57 +0100
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <200904091224.55856.sachin@geodesic.com>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
Message-ID: <4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>

On Thu, Apr 9, 2009 at 7:54 AM, Sachin Khandelwal <sachin at geodesic.com> wrote:
> Hi,
>
> Addition of this feature is highly appreciated.
> There is a small issue which will occur in rare scenario :
>
> In sec 2.4, "Example 4. Roster result with no items"
>
> <iq from='romeo at montague.lit' id='r1' to='romeo at montague.lit/home'
> type='result'>
> ?<query xmlns='jabber:iq:roster' ver='317'>
> </iq>
>
> The above example is for the case when server will send the individual roster
> pushes for the changes rather then sending the complete roster. But the server
> will return the same response (while returning complete roster) when user has
> deleted all the rosteritems present previous version (say 316).
>

<this-space-intentionally-left-blank/>

I'm not sure that I see this as a problem. If a client requests r317
then it already knows that the contacts have been deleted, there will
be no roster pushes, and there needn't be any. If it requests 316 then
it can be notified of the deletion of the single contact and then
upgraded to 317.

Am I missing something?

Matthew.

From sachin at geodesic.com  Thu Apr  9 08:57:44 2009
From: sachin at geodesic.com (Sachin Khandelwal)
Date: Thu, 9 Apr 2009 19:27:44 +0530
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
Message-ID: <200904091927.45127.sachin@geodesic.com>

Hi,

Let me elaborate this :
Consider user 'xmpp1'  uses two clients to login  (say one from home and one 
from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster 
version is 316. Both the office client and home client are upgraded to version 
316. Now from office client user deletes the contact ( home client is not logged 
in that time). Now when xmpp1 login from home client the response of roster 
retrieval will be same as Example 4. 

Here my concern was how the client will come to know that the response is 
actually a zero rosteritem (empty roster) condition and not that "the roster 
changes will be sent later as interim roster pushes" as mentioned in sec 2.4.

Also consider that the server is implemented to send the complete roster and 
not the interim roster pushes.

Regards,

Sachin Khandelwal

On Thursday 09 April 2009 18:09:57 Matthew Wild wrote:
> On Thu, Apr 9, 2009 at 7:54 AM, Sachin Khandelwal <sachin at geodesic.com> 
wrote:
> > Hi,
> >
> > Addition of this feature is highly appreciated.
> > There is a small issue which will occur in rare scenario :
> >
> > In sec 2.4, "Example 4. Roster result with no items"
> >
> > <iq from='romeo at montague.lit' id='r1' to='romeo at montague.lit/home'
> > type='result'>
> > ?<query xmlns='jabber:iq:roster' ver='317'>
> > </iq>
> >
> > The above example is for the case when server will send the individual
> > roster pushes for the changes rather then sending the complete roster.
> > But the server will return the same response (while returning complete
> > roster) when user has deleted all the rosteritems present previous
> > version (say 316).
>
> <this-space-intentionally-left-blank/>
>
> I'm not sure that I see this as a problem. If a client requests r317
> then it already knows that the contacts have been deleted, there will
> be no roster pushes, and there needn't be any. If it requests 316 then
> it can be notified of the deletion of the single contact and then
> upgraded to 317.
>
> Am I missing something?
>
> Matthew.


From dave at cridland.net  Thu Apr  9 09:21:59 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 09 Apr 2009 15:21:59 +0100
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <200904091927.45127.sachin@geodesic.com>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com>
Message-ID: <28126.1239286919.152779@puncture>

On Thu Apr  9 14:57:44 2009, Sachin Khandelwal wrote:
> Here my concern was how the client will come to know that the  
> response is
> actually a zero rosteritem (empty roster) condition and not that  
> "the roster
> changes will be sent later as interim roster pushes" as mentioned  
> in sec 2.4.

I'm not sure there is a concrete problem here without more thought,  
but assuming there is, I think it can be avoided by including a count  
in the responses, which might well be useful for debugging purposes  
anyway.

I need to think more on this, though - which I'll do after Easter.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From justin-keyword-jabber.093179 at affinix.com  Thu Apr  9 10:00:36 2009
From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges)
Date: Thu, 9 Apr 2009 08:00:36 -0700
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <594682.75698.qm@web95403.mail.in2.yahoo.com>
References: <594682.75698.qm@web95403.mail.in2.yahoo.com>
Message-ID: <200904090800.36087.justin-keyword-jabber.093179@affinix.com>

On Thursday 09 April 2009 04:16:32 Mridul Muralidharan wrote:
> --- On Thu, 9/4/09, Justin Karneges 
<justin-keyword-jabber.093179 at affinix.com> wrote:
> > However, transport contacts often have no resource.?
> > These are not real logged
> > in XMPP clients, but faked contacts from a server
> > component.? You will get
> > <presence from='screenname at aim.transport'/>
> > and have to deal with it.
>
> You are right, you can/will get non-unavailable presence with from as
> barejid from components (and so I tried to carefully word it as user in my
> mail :-) ). That being said, before you receive the presence, the client
> would know that the bare jid corresponds to a component right ? IIRC the
> presence received is in response to client action (subsequent to disco,
> etc) - any time this is not the case ?

No, presence from contacts faked by transports is received automatically, just 
like with regular contacts.  No client action is necessary.

From stpeter at stpeter.im  Thu Apr  9 09:53:54 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 08:53:54 -0600
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <200904091927.45127.sachin@geodesic.com>
References: <E1Lre0m-0003z0-00@apollo>
	<200904091224.55856.sachin@geodesic.com>	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com>
Message-ID: <49DE0C02.5010908@stpeter.im>

On 4/9/09 7:57 AM, Sachin Khandelwal wrote:
> Hi,

Hi. Could you please refrain from top-posting, please? :)

> Let me elaborate this :
> Consider user 'xmpp1'  uses two clients to login  (say one from home and one 
> from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster 
> version is 316. Both the office client and home client are upgraded to version 
> 316. Now from office client user deletes the contact ( home client is not logged 
> in that time). Now when xmpp1 login from home client the response of roster 
> retrieval will be same as Example 4. 
> 
> Here my concern was how the client will come to know that the response is 
> actually a zero rosteritem (empty roster) condition and not that "the roster 
> changes will be sent later as interim roster pushes" as mentioned in sec 2.4.
> 
> Also consider that the server is implemented to send the complete roster and 
> not the interim roster pushes.

That's an interesting edge case. I'm not yet sure how to solve it.
You're right that with roster versioning an empty <query/> element now
can mean two different things. This requires further thought.

Thinking out loud: perhaps if the roster is empty the server must not
include the sequence number? Or some other notation that the roster is
empty?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/29c10a29/attachment.bin 

From mwild1 at gmail.com  Thu Apr  9 10:16:14 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Thu, 9 Apr 2009 16:16:14 +0100
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <49DE0C02.5010908@stpeter.im>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com> <49DE0C02.5010908@stpeter.im>
Message-ID: <4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>

Now I'm being bad and replying to 2 mails at once, sorry :)

On Thu, Apr 9, 2009 at 3:53 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 4/9/09 7:57 AM, Sachin Khandelwal wrote:
>> Let me elaborate this :
>> Consider user 'xmpp1' ?uses two clients to login ?(say one from home and one
>> from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster
>> version is 316. Both the office client and home client are upgraded to version
>> 316. Now from office client user deletes the contact ( home client is not logged
>> in that time). Now when xmpp1 login from home client the response of roster
>> retrieval will be same as Example 4.
>>

No, xmpp1 at home will request the version it knows about... 316. The
server will reply with an empty 317, and also send a roster pushe for
the removal of the 316 contact. No?

>> Here my concern was how the client will come to know that the response is
>> actually a zero rosteritem (empty roster) condition and not that "the roster
>> changes will be sent later as interim roster pushes" as mentioned in sec 2.4.
>>

I don't think it has to know (though see above, since it I believe it
*will* know). It simply presents the roster it knows about, until it
receives further notice from the server (which will be the roster
pushes).

>> Also consider that the server is implemented to send the complete roster and
>> not the interim roster pushes.
>
> That's an interesting edge case. I'm not yet sure how to solve it.
> You're right that with roster versioning an empty <query/> element now
> can mean two different things. This requires further thought.
>

I wouldn't be opposed to making an empty roster explicit, or
preferably a non-empty roster explicit, e.g. some way to say "updates
are coming" or better "X updates are coming".

> Thinking out loud: perhaps if the roster is empty the server must not
> include the sequence number? Or some other notation that the roster is
> empty?
>

I'm not sure I like leaving out the sequence number. An empty roster
still has a version, that version needs to be known to keep track of
item deletions.

Matthew.

From stpeter at stpeter.im  Thu Apr  9 10:57:15 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 09:57:15 -0600
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
References: <E1Lre0m-0003z0-00@apollo>
	<200904091224.55856.sachin@geodesic.com>	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>	<200904091927.45127.sachin@geodesic.com>
	<49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
Message-ID: <49DE1ADB.3020309@stpeter.im>

On 4/9/09 9:16 AM, Matthew Wild wrote:
> Now I'm being bad and replying to 2 mails at once, sorry :)
> 
> On Thu, Apr 9, 2009 at 3:53 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> On 4/9/09 7:57 AM, Sachin Khandelwal wrote:
>>> Let me elaborate this :
>>> Consider user 'xmpp1'  uses two clients to login  (say one from home and one
>>> from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster
>>> version is 316. Both the office client and home client are upgraded to version
>>> 316. Now from office client user deletes the contact ( home client is not logged
>>> in that time). Now when xmpp1 login from home client the response of roster
>>> retrieval will be same as Example 4.
>>>
> 
> No, xmpp1 at home will request the version it knows about... 316. The
> server will reply with an empty 317, and also send a roster pushe for
> the removal of the 316 contact. No?

I think Sachin's point is that if the server is sending complete roster
(not subsequent roster pushes), then the client won't know if the empty
<query/> means (1) here is the complete roster but there's nothing in it
(2) no changes.

But I think that reasoning is not quite right.

1. xmpp1 requests 316 (which had one item in it)
2. server returns 317 with empty query element

So xmpp1 knows that the roster has changed. And the change is, there's
nothing in the roster.

>>> Here my concern was how the client will come to know that the response is
>>> actually a zero rosteritem (empty roster) condition and not that "the roster
>>> changes will be sent later as interim roster pushes" as mentioned in sec 2.4.
>>>
> 
> I don't think it has to know (though see above, since it I believe it
> *will* know). It simply presents the roster it knows about, until it
> receives further notice from the server (which will be the roster
> pushes).
> 
>>> Also consider that the server is implemented to send the complete roster and
>>> not the interim roster pushes.
>> That's an interesting edge case. I'm not yet sure how to solve it.
>> You're right that with roster versioning an empty <query/> element now
>> can mean two different things. This requires further thought.
>>
> 
> I wouldn't be opposed to making an empty roster explicit, or
> preferably a non-empty roster explicit, e.g. some way to say "updates
> are coming" or better "X updates are coming".

I suppose there would be no harm in defining a flag in the roster result
that says "expect roster pushes with the diff". I'm not yet sure that's
needed, though.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/2863a703/attachment-0001.bin 

From mridulm80 at yahoo.com  Thu Apr  9 11:31:09 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 22:01:09 +0530 (IST)
Subject: [Standards] unavailable presence from bare JID
Message-ID: <564341.67135.qm@web95401.mail.in2.yahoo.com>




--- On Thu, 9/4/09, Justin Karneges <justin-keyword-jabber.093179 at affinix.com> wrote:

> From: Justin Karneges <justin-keyword-jabber.093179 at affinix.com>
> Subject: Re: [Standards] unavailable presence from bare JID
> To: "XMPP Standards" <standards at xmpp.org>
> Date: Thursday, 9 April, 2009, 8:30 PM
> On Thursday 09 April 2009 04:16:32
> Mridul Muralidharan wrote:
> > --- On Thu, 9/4/09, Justin Karneges 
> <justin-keyword-jabber.093179 at affinix.com>
> wrote:
> > > However, transport contacts often have no
> resource.?
> > > These are not real logged
> > > in XMPP clients, but faked contacts from a
> server
> > > component.? You will get
> > > <presence from='screenname at aim.transport'/>
> > > and have to deal with it.
> >
> > You are right, you can/will get non-unavailable
> presence with from as
> > barejid from components (and so I tried to carefully
> word it as user in my
> > mail :-) ). That being said, before you receive the
> presence, the client
> > would know that the bare jid corresponds to a
> component right ? IIRC the
> > presence received is in response to client action
> (subsequent to disco,
> > etc) - any time this is not the case ?
> 
> No, presence from contacts faked by transports is received
> automatically, just 
> like with regular contacts.? No client action is
> necessary.

To get it clarified (since I am looking at client libraries right now), that is still within the component's domain right ?
Not outside of it ?


What I mean is :

user disco's/connects to component transport.server.domain
component sends back presence for user1 at transport.server.domain, user2 at transport.server.domain/res , etc

Or do you mean something different ?
So in essence, I am trying to see if a client can infer if the presence from a bare jid is coming from a component (and so handled separately) or from an xmpp user where barejid does not make sense.


Thanks for clarifying.

Regards,
Mridul



> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From stpeter at stpeter.im  Thu Apr  9 11:56:30 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 10:56:30 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <564341.67135.qm@web95401.mail.in2.yahoo.com>
References: <564341.67135.qm@web95401.mail.in2.yahoo.com>
Message-ID: <49DE28BE.6000406@stpeter.im>

On 4/9/09 10:31 AM, Mridul Muralidharan wrote:

> So in essence, I am trying to see if a client can infer if the
> presence from a bare jid is coming from a component (and so handled
> separately) or from an xmpp user where barejid does not make sense.

I don't think you can tell just from the presence. If the presence
includes entity capabilities or you disco the entity then you can find
out what it is. But I don't know how many gateways support disco or
entity capabilities...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/cc3eb0fd/attachment.bin 

From elmex at x-paste.de  Thu Apr  9 12:12:04 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Thu, 9 Apr 2009 19:12:04 +0200
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <564341.67135.qm@web95401.mail.in2.yahoo.com>
References: <564341.67135.qm@web95401.mail.in2.yahoo.com>
Message-ID: <20090409171204.GA8413@elmex2>

On Thu, Apr 09, 2009 at 10:01:09PM +0530, Mridul Muralidharan wrote:
>
[.snip.]
> 
> To get it clarified (since I am looking at client libraries right now), that
> is still within the component's domain right ?  Not outside of it ?
> 
> 
> What I mean is :
> 
> user disco's/connects to component transport.server.domain component sends
> back presence for user1 at transport.server.domain,
> user2 at transport.server.domain/res , etc
> 
> Or do you mean something different ?  So in essence, I am trying to see if a
> client can infer if the presence from a bare jid is coming from a component
> (and so handled separately) or from an xmpp user where barejid does not make
> sense.
> 

If _presence_ semantics don't allow presence from bare JIDs it's wrong for
components to try to fit the presence into them. I certainly don't want to
build disco-hacks into presence handling just for some broken components who
don't know how to gateway presence information in a well defined RFC compliant
way.

IMO either the RFC should specify presence from bare JIDs or components should
introduce 'fake' resources.

For the moment mapping presence from bare JIDs to an empty resource (resource
string with length 0) is probably the best workaround a client (library) can
do. And some special rules in general for bare JIDs (like unavailability from
a bare JID stands for 'no resource online anymore').


Greetings,
   Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

From mridulm80 at yahoo.com  Thu Apr  9 12:26:10 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 22:56:10 +0530 (IST)
Subject: [Standards] unavailable presence from bare JID
Message-ID: <102710.4693.qm@web95401.mail.in2.yahoo.com>



I was trying to understand how current components and clients behave ... particularly since psi and others would have already faced and worked around/solved this issue.

That being said, I completely agree with you - it does not really make much sense for available present from a bare jid as far as I can make out.

Regards,
Mridul



--- On Thu, 9/4/09, Robin Redeker <elmex at x-paste.de> wrote:

> From: Robin Redeker <elmex at x-paste.de>
> Subject: Re: [Standards] unavailable presence from bare JID
> To: standards at xmpp.org
> Date: Thursday, 9 April, 2009, 10:42 PM
> On Thu, Apr 09, 2009 at 10:01:09PM
> +0530, Mridul Muralidharan wrote:
> >
> [.snip.]
> > 
> > To get it clarified (since I am looking at client
> libraries right now), that
> > is still within the component's domain right ??
> Not outside of it ?
> > 
> > 
> > What I mean is :
> > 
> > user disco's/connects to component
> transport.server.domain component sends
> > back presence for user1 at transport.server.domain,
> > user2 at transport.server.domain/res
> , etc
> > 
> > Or do you mean something different ?? So in
> essence, I am trying to see if a
> > client can infer if the presence from a bare jid is
> coming from a component
> > (and so handled separately) or from an xmpp user where
> barejid does not make
> > sense.
> > 
> 
> If _presence_ semantics don't allow presence from bare JIDs
> it's wrong for
> components to try to fit the presence into them. I
> certainly don't want to
> build disco-hacks into presence handling just for some
> broken components who
> don't know how to gateway presence information in a well
> defined RFC compliant
> way.
> 
> IMO either the RFC should specify presence from bare JIDs
> or components should
> introduce 'fake' resources.
> 
> For the moment mapping presence from bare JIDs to an empty
> resource (resource
> string with length 0) is probably the best workaround a
> client (library) can
> do. And some special rules in general for bare JIDs (like
> unavailability from
> a bare JID stands for 'no resource online anymore').
> 
> 
> Greetings,
> ???Robin
> 
> -- 
> Robin Redeker? ? ? ? ? ?
> ? ? ? ? ? ???|
> Deliantra, the free code+content MORPG
> elmex at ta-sa.org /
> r.redeker at gmail.com
> | http://www.deliantra.net
> http://www.ta-sa.org/? ? ? ? ?
> ? ? ???|
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From justin-keyword-jabber.093179 at affinix.com  Thu Apr  9 12:47:59 2009
From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges)
Date: Thu, 9 Apr 2009 10:47:59 -0700
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <102710.4693.qm@web95401.mail.in2.yahoo.com>
References: <102710.4693.qm@web95401.mail.in2.yahoo.com>
Message-ID: <200904091047.59997.justin-keyword-jabber.093179@affinix.com>

On Thursday 09 April 2009 10:26:10 Mridul Muralidharan wrote:
> I was trying to understand how current components and clients behave ...
> particularly since psi and others would have already faced and worked
> around/solved this issue.

Psi doesn't try to detect the type of contact to know if presence without a 
resource could happen.  I'm willing to be no client does that, actually..

Besides, a transport contact could actually send a resource, and probably some 
of them do.  I don't think it's fair to assume a transport would always send 
presence without a resource.  So, a client has to be prepared to accept both.  
I don't see much point in having special handling depending on contact type.

I agree with Robin, that the RFC should at least clarify what it means to have 
presence from no resource.  Probably it should just be treated as a resource 
of 0-length, that does not overshadow other resources from the same bare jid.  
I think this would describe current practice.  The alternative approach of 
changing all existing implementations to never send nor support presence from 
no resource is not practical.  That ship has sailed.

-Justin

From stpeter at stpeter.im  Thu Apr  9 12:51:38 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 11:51:38 -0600
Subject: [Standards] unavailable presence from bare JID
In-Reply-To: <200904091047.59997.justin-keyword-jabber.093179@affinix.com>
References: <102710.4693.qm@web95401.mail.in2.yahoo.com>
	<200904091047.59997.justin-keyword-jabber.093179@affinix.com>
Message-ID: <49DE35AA.8020906@stpeter.im>

On 4/9/09 11:47 AM, Justin Karneges wrote:
> On Thursday 09 April 2009 10:26:10 Mridul Muralidharan wrote:
>> I was trying to understand how current components and clients behave ...
>> particularly since psi and others would have already faced and worked
>> around/solved this issue.
> 
> Psi doesn't try to detect the type of contact to know if presence without a 
> resource could happen.  I'm willing to be no client does that, actually..
> 
> Besides, a transport contact could actually send a resource, and probably some 
> of them do.  I don't think it's fair to assume a transport would always send 
> presence without a resource.  So, a client has to be prepared to accept both.  
> I don't see much point in having special handling depending on contact type.
> 
> I agree with Robin, that the RFC should at least clarify what it means to have 
> presence from no resource.  Probably it should just be treated as a resource 
> of 0-length, that does not overshadow other resources from the same bare jid.  
> I think this would describe current practice.  

+1

> The alternative approach of 
> changing all existing implementations to never send nor support presence from 
> no resource is not practical.  That ship has sailed.

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/6d88d18e/attachment-0001.bin 

From stpeter at stpeter.im  Thu Apr  9 16:16:08 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 15:16:08 -0600
Subject: [Standards] Corrections in XEP-0136
In-Reply-To: <200904081417.29710.sachin@geodesic.com>
References: <200904081417.29710.sachin@geodesic.com>
Message-ID: <49DE6598.8020009@stpeter.im>

On 4/8/09 2:47 AM, Sachin Khandelwal wrote:
> Hi,
> 
> Suggesting two minor corrections in XEP-0136 :
> 
> 1) In sec "10.1 Exact JID Matching" : 
> In sentence 
> a 'with' value such as "example.com" matches that exact JID only rather than 
> <*@example.com>, <*@example.com>, or <example.com/*> 
> 
> the first two expression are same ( i.e. <*@example.com> ) . I guess
> one of them should be <*@example.com/*>.

Right, the second one is supposed to be <*@example.com/*>.

> 2) In the XML Schema, the definition of 'item' element states that all the 
> three attributes - 'jid', 'otr', and 'save' are required. And the same 'item' 
> is referred from 'itemremove' element which, as per Example 11, will only have 
> jid attribute. 

Hmm, that's messy!

> So we need to define a saperate 'item' inside 'itemremove' which 
> will only have 'jid' attribute, instead of referring the existing one.

Or change 'otr' and 'save' to optional. That's what I'll do for now.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/e271a027/attachment.bin 

From stpeter at stpeter.im  Thu Apr  9 16:28:08 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 15:28:08 -0600
Subject: [Standards] inconsistency between section 7.2 - 10.2 in
 XEP-0136 ?
In-Reply-To: <6ee81fd0600900ac97d36cf497a6beff@ndl.kiev.ua>
References: <49404294.7070105@eaktion.com>
	<49DBC936.2000505@stpeter.im>	<49DBCBCC.3090500@stpeter.im>	<200904081330.58424.sachin@geodesic.com>
	<6ee81fd0600900ac97d36cf497a6beff@ndl.kiev.ua>
Message-ID: <49DE6868.2020200@stpeter.im>

On 4/8/09 3:10 AM, Alexander Tsvyashchenko wrote:
> Hello Sachin,
> 
> On Wed, 8 Apr 2009 13:30:58 +0530, Sachin Khandelwal <sachin at geodesic.com>
> wrote:
> 
>> I feel it'll create inconsistency due to changes in section "7.1 and 7.2"
> .
>> As per section sec 4.5 the with attribute can be JID (not only full jid).
> so
>> due to this change, it'll not be possible retrieve the collections having
> with 
>> attribute as bare JID.
> 
> Not directly related to this particular change, but looks like you're right
> that section 4.5 is a bit strange: it describes chat[@with], but talks
> about "matching" - I believe it does not make sense in this context.
> 
> 2Peter: does it make sense to remove "If the JID is of the form
> <localpart at domain.tld>, any resource matches; if the JID is of the form
> <domain.tld>, any node matches" paragraph from 4.5, as it describes 'with'
> attribute of 'chat' element, not 'with' attribute of any command, so
> there's no "matching" to talk about?

I don't think that's right. See these examples:

http://xmpp.org/extensions/xep-0136.html#example-23 (MUC)

http://xmpp.org/extensions/xep-0136.html#example-24

http://xmpp.org/extensions/xep-0136.html#example-25

> This paragraph might be moved to 10.1 section, for example: probably it
> might be renamed from "Exact JID Matching" to "JID Matching" then and in
> 2.2.3.2, 7.1 and 7.3 all info about 'jid'/'with' meaning might be removed
> and the link to "JID Matching" might be just given instead (yes, I'm a real
> fan of DRY principle ;-) ) 7.2 will have slightly different wording
> (discussed below) and 2.2.3.2 (or 2.2.3?) additionally might mention that
> more specific JIDs settings override less specific ones.

Shall I give you SVN access to the XEPs repository so that you can make
proposed changes? That might be productive for all of us. Poke me on IM
if you're interested. :)

> As for the inconsistency: yes, recent change might introduce some
> inconsistency, see below.
> 
>> One solution I think of is to keep sec "7.1 Retrieving a List of
> Collections" 
>> as it is and for sec. "7.2 Retrieving a Collection", remove the
> 'exactmatch' 
>> attribute and the value of with attribute should always be exactly
> matched
>> by default.
> 
> Yes, I believe 'exactmatch' in '7.2' was left just by the accident and I
> agree the wording should be slightly adjusted also.

Now I'm not so sure. See the MUC examples I noted above.

> 2Peter: I would suggest the following further changes (that's basically
> what Sachin says, I believe, just slightly more expanded):
> 
>  1. Remove 'In addition, the client MAY match an exact bare JID &BAREJID;
> by setting the boolean 'exactmatch' attribute to a value of "true" or "1"
> &BOOLEANNOTE; -- for details, refer to the <link
> url='#impl-exactmatch'>Exact JID Matching</link> section of this document.'
> paragraph from 7.2
> 
>  2. Move "Note: Collections are retrieved only based on the full JID ..."
> from 7.1 to 7.2 (as it belongs there, not to the "retrieving a list of
> collections") and rephrase it like "Note: the &lt;retrieve/&gt; shall not
> possess the 'exactmatch' attribute, as exact JID matching (see the <link
> url='#impl-exactmatch'>Exact JID Matching</link> section of this document)
> is always implied for this command. This is done to prevent returning
> multiple collections from the &lt;retrieve/&gt; command", as current
> wording implies that only "full JIDs" might be specified, but in fact we
> should enforce not "full JIDs" but "exact matching".

See above.

> If you agree on changing 10.1 to become "JID Matching" instead of "Exact
> JID Matching" the link and wording around it would be slightly different in
> (2), but the idea is the same.

I'm not sure yet. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/d9c427f5/attachment.bin 

From stpeter at stpeter.im  Thu Apr  9 16:31:24 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 15:31:24 -0600
Subject: [Standards] XEP-0136 - Message Archiving Preferences doubt
In-Reply-To: <24ed641ac4ce315f4cc067fee70df40f@ndl.kiev.ua>
References: <200904021106.09674.sachin@geodesic.com>	<edab29795f6f40dda93fc695d9ed8124@ndl.kiev.ua>	<200904071150.04826.sachin@geodesic.com>
	<24ed641ac4ce315f4cc067fee70df40f@ndl.kiev.ua>
Message-ID: <49DE692C.5060703@stpeter.im>

On 4/7/09 2:42 AM, Alexander Tsvyashchenko wrote:
> 
> On Tue, 7 Apr 2009 11:50:04 +0530, Sachin Khandelwal <sachin at geodesic.com>
> wrote:

<snip/>

> Once again: the server is just "storage back-end", and it does only what
> client told it to do. If client told the server "enable auto-archiving" -
> so be it, it's client responsibility to ensure that this command didn't
> violate OTR negotiation results or whatever else part of XEP-136. There's
> no point in server knowing about OTR and trying to enforce it when clients
> may easily violate it by local messages recording.

Correct.

> 2Peter: in fact XEP-136 might be slightly confusing in its current form
> regarding preferences interpretation in auto-archiving mode - probably, it
> might be a good idea to list explicitly which preferences server takes into
> account when auto-archiving is enabled. I believe these are "auto" (per
> stream), "default[@expire, @save]" and "item[@expire, @jid, @save]" in
> "normal" auto-archiving mode and no preferences are taken into account in
> "forced" auto-archiving mode.
> 
> It also might be useful to explicitly state that all other preferences are
> for clients interpretation only.

That would be helpful, yes.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/d2a28927/attachment-0001.bin 

From editor at xmpp.org  Thu Apr  9 19:19:11 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 09 Apr 2009 19:19:11 -0500
Subject: [Standards] UPDATED: XEP-0198 (Stream Management)
Message-ID: <E1Ls4Sd-0002Xd-00@apollo>

Version 0.8 of XEP-0198 (Stream Management) has been released.

Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption.

Changelog: [See revision history] (ff/jk/jjh/psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u&%40diffWrap=s&r1=2933&r2=3028&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0198.html


From stpeter at stpeter.im  Thu Apr  9 21:07:54 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 20:07:54 -0600
Subject: [Standards] roster partial activation & privacy lists
In-Reply-To: <2fd53c3a0903180719s6dd3d3b8xb018c0aa1b62a302@mail.gmail.com>
References: <2fd53c3a0903180719s6dd3d3b8xb018c0aa1b62a302@mail.gmail.com>
Message-ID: <49DEA9FA.7010503@stpeter.im>

On 3/18/09 8:19 AM, Fabio Forno wrote:
> A quick recap about all the discussions we had since Brussels and some
> new thoughts on roster optimizations
> 
> - Roster sequencing rocks, it should be inserted into rfc3921bis and
> all the world will implement it

Last Call in progress. :)

> - Partial roster retrieval: it's not clear whether  it should be just
> retrieval or something modifying also the behavior of presence
> broadcast. I'd prefer to stick it just retrieval, without affecting
> presence and implement it as an optional xep, letting what I call
> "activation" to a different mechanism. The main reason is that these
> are two different things which can be needed in different situations;
> partial retrieval has sever distinct use cases, which are independent
> from presence delivery:
> - just discover the groups
> - retrieve just a group
> - retrieve accordingly the subscription state (I feel this is pretty
> important since I don't want to retrieve 1000 contacts with
> subscription == none on my mobile, as it can happen if I use the
> roster as address book for contacts I have very infrequent
> communications with)
> - retrieve additional information bound to contacts (certificate, vcard, ...)

That sounds like a reasonable approach.

> - About partial roster activation there are different points of view,
> some say it's not necessary, some is fearing a new monster like
> privacy lists, others say just use privacy lists! The only thing I'm
> sure about it is that we need it, since from few tests when I go
> online with my mobile (compression enabled), I get the following
> figures:
>  - ~ 1.5 KB for logging in with all the stream features and sasl thing
>  - ~ 4-5 KB for a ~ 150 contact roster
>  - ~ 12-14 KB for the inbound presence storm, most of it completely unwanted.
> 
> So we did some internal brainstorming and here is what is our
> implementation plan:
>  - privacy lists have the nice feature of being there and ready, so we
> will use them
>  - we don't implement them, but just use them, that's to say users
> will be not aware of the existence of such a baffling thing like
> privacy lists, we just add a group "VIPs" (an perhaps some other more
> in future) and the the user: if you want to save bits just add there
> all the people you want to see whether they are only or not
>  - If the VIPs group has items we create a privacy list in which all
> incoming presence is blocked but that of VIPs
>  - Before going online we set the VIPs privacy list as the active one
> 
> The only problem is that if we want to probe some contacts not in them
> VIPs group we must either put them temporarily in the VIPs group or
> unset the privacy list, and I don't know if there ar workarounds for
> this (but a service with which we can poke the presence of somebody
> using an <iq/>

Another possible hack is to create a "temp" group and add/subtract
people in that group (leaving VIPs alone).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090409/30f2cd65/attachment.bin 

From editor at xmpp.org  Thu Apr  9 22:10:23 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 09 Apr 2009 22:10:23 -0500
Subject: [Standards] UPDATED: XEP-0255 (Location Query)
Message-ID: <E1Ls78J-00040Q-00@apollo>

Version 0.6 of XEP-0255 (Location Query) has been released.

Abstract: This specification defines an XMPP protocol extension for querying a compliant server or service for information about the geographical or physical location of an entity.

Changelog: Defined registry; added nic type from list discussion. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0255.xml?%40diffMode=u&%40diffWrap=s&r1=2893&r2=3034&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0255.html


From egon.willighagen at gmail.com  Fri Apr 10 01:00:06 2009
From: egon.willighagen at gmail.com (Egon Willighagen)
Date: Fri, 10 Apr 2009 08:00:06 +0200
Subject: [Standards] XMPP example site - www.LiveBaseballChat.com
In-Reply-To: <3685A8FD247FA94C957C4304AB386A0427CC8F@cognationsvr1.Cognation.local>
References: <6e2f977f0903180730g24363918j705c0034f4a4edfe@mail.gmail.com>
	<49DAD304.20707@stpeter.im>
	<3685A8FD247FA94C957C4304AB386A0427CC8F@cognationsvr1.Cognation.local>
Message-ID: <6aeb064b0904092300w75974ef0x887a9660098032fd@mail.gmail.com>

On Tue, Apr 7, 2009 at 11:00 PM, Dean Collins <Dean at cognation.net> wrote:
> Basically it is an ajax/xmpp site with 2430 chat rooms set up over the
> next 6 months for people to talk about specific Baseball games.

Interesting... I have been thinking about making a web front end for
IO-DATA services, assuming there must be web/JavaScript libraries to
talk over the XMPP network...

Can you please elaborate on the libraries used behind your website?

Egon

-- 
Post-doc @ Uppsala University
http://chem-bla-ics.blogspot.com/

From elmex at x-paste.de  Fri Apr 10 02:10:15 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Fri, 10 Apr 2009 09:10:15 +0200
Subject: [Standards] UPDATED: XEP-0198 (Stream Management)
In-Reply-To: <E1Ls4Sd-0002Xd-00@apollo>
References: <E1Ls4Sd-0002Xd-00@apollo>
Message-ID: <20090410071015.GA3802@elmex2>

On Thu, Apr 09, 2009 at 07:19:11PM -0500, XMPP Extensions Editor wrote:
> Version 0.8 of XEP-0198 (Stream Management) has been released.
> 
> Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption.
> 
> Changelog: [See revision history] (ff/jk/jjh/psa)
> 
> Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u&%40diffWrap=s&r1=2933&r2=3028&u=3&ignore=&k=
> 
> URL: http://xmpp.org/extensions/xep-0198.html
> 

Looks fine to me now, just a minor inconsistency (probably from editing):

   4. Acks
   ...
   An <a/> element MUST possess an 'h' attribute.
   An <r/> element SHOULD NOT possess any attributes.

But later it says:

   When an <r/> element ("request") is received, the recipient MUST acknowledge
   it by sending an ack element (either <a/> or <r/>) to the sender.
   ...
   The response MUST contain a value of 'h' that is equal to the number of
   stanzas handled by the recipient of the <r/> element.



Greetings,
   Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

From stpeter at stpeter.im  Fri Apr 10 07:12:04 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 06:12:04 -0600
Subject: [Standards] UPDATED: XEP-0198 (Stream Management)
In-Reply-To: <20090410071015.GA3802@elmex2>
References: <E1Ls4Sd-0002Xd-00@apollo> <20090410071015.GA3802@elmex2>
Message-ID: <49DF3794.6030707@stpeter.im>

On 4/10/09 1:10 AM, Robin Redeker wrote:
> On Thu, Apr 09, 2009 at 07:19:11PM -0500, XMPP Extensions Editor wrote:
>> Version 0.8 of XEP-0198 (Stream Management) has been released.
>>
>> Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption.
>>
>> Changelog: [See revision history] (ff/jk/jjh/psa)
>>
>> Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u&%40diffWrap=s&r1=2933&r2=3028&u=3&ignore=&k=
>>
>> URL: http://xmpp.org/extensions/xep-0198.html
>>
> 
> Looks fine to me now, just a minor inconsistency (probably from editing):
> 
>    4. Acks
>    ...
>    An <a/> element MUST possess an 'h' attribute.
>    An <r/> element SHOULD NOT possess any attributes.
> 
> But later it says:
> 
>    When an <r/> element ("request") is received, the recipient MUST acknowledge
>    it by sending an ack element (either <a/> or <r/>) to the sender.
>    ...
>    The response MUST contain a value of 'h' that is equal to the number of
>    stanzas handled by the recipient of the <r/> element.

Thanks, I'll fix that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/0285c553/attachment-0001.bin 

From stpeter at stpeter.im  Fri Apr 10 10:59:41 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 09:59:41 -0600
Subject: [Standards] Forwarding Delivery Draft
In-Reply-To: <49BFCD18.8080209@stpeter.im>
References: <cone.1237306249.139539.6979.1000@pier42.zeropage.net>
	<49BFCD18.8080209@stpeter.im>
Message-ID: <49DF6CED.9080302@stpeter.im>

On 3/17/09 10:17 AM, Peter Saint-Andre wrote:
> On 3/17/09 10:10 AM, Michael Grigutsch wrote:
>> Hi!
> 
> Hi MiGri!
> 
>> In 2006 Peter Saint-Andre wrote a Draft for a JEP which would fill an
>> important gap: It is about forwarding stanzas.
>> You can find the document at
>> http://xmpp.org/extensions/inbox/forwarding-delivery.html
> 
> There was some controversy about forwarding when the XMPP Council last
> discussed it:
> 
> http://logs.jabber.org/council at conference.jabber.org/2006-02-09.html
> 
> http://logs.jabber.org/council at conference.jabber.org/2006-03-23.html
> 
> Perhaps you could read those logs and summarize the objections? I can't
> remember what the issues were at this point. :)
> 
>> I would love to see the XSF publish this as an official XEP and I
>> volunteer to help work on the spec so that we can complete this work.
> 
> That's great, thanks! It seems that I no longer have the original .xml
> file for that proposal, so I'll need to reconstruct it from the HTML
> output. I'll do that soon and send you the file.

Done:

http://xmpp.org/extensions/inbox/forwarding-delivery.xml

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/7772d20b/attachment.bin 

From editor at xmpp.org  Fri Apr 10 15:12:26 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Fri, 10 Apr 2009 15:12:26 -0500
Subject: [Standards] Proposed XMPP Extension: Instant Gaming
Message-ID: <E1LsN5O-0004AB-00@apollo>

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Instant Gaming

Abstract: This document defines an XMPP protocol extension for serverless instant gaming in a one-to-one context.

URL: http://www.xmpp.org/extensions/inbox/instant-gaming.html

The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.


From editor at xmpp.org  Fri Apr 10 15:12:37 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Fri, 10 Apr 2009 15:12:37 -0500
Subject: [Standards] Proposed XMPP Extension: Multi-User Gaming
Message-ID: <E1LsN5Z-0004AK-00@apollo>

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Multi-User Gaming

Abstract: This document defines an XMPP protocol extension for multi-user gaming.

URL: http://www.xmpp.org/extensions/inbox/multi-user_gaming.html

The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.


From editor at xmpp.org  Fri Apr 10 15:12:48 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Fri, 10 Apr 2009 15:12:48 -0500
Subject: [Standards] Proposed XMPP Extension: Tic-tac-toe
Message-ID: <E1LsN5k-0004AU-00@apollo>

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Tic-tac-toe

Abstract: This document defines how to play a Tic-tac-toe game over XMPP

URL: http://www.xmpp.org/extensions/inbox/tictactoe.html

The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.


From editor at xmpp.org  Fri Apr 10 15:13:00 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Fri, 10 Apr 2009 15:13:00 -0500
Subject: [Standards] Proposed XMPP Extension: Server-based Tic-tac-toe
Message-ID: <E1LsN5w-0004Ai-00@apollo>

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Server-based Tic-tac-toe

Abstract: This document defines how to play a Tic-tac-toe game over XMPP

URL: http://www.xmpp.org/extensions/inbox/tictactoe-mug.html

The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.


From stpeter at stpeter.im  Fri Apr 10 17:28:50 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 16:28:50 -0600
Subject: [Standards] XMPP-IM - presence subscription handling
In-Reply-To: <e962983d0902240753o181f7c33nbc0aaf0459f60bfc@mail.gmail.com>
References: <e962983d0902240753o181f7c33nbc0aaf0459f60bfc@mail.gmail.com>
Message-ID: <49DFC822.6010300@stpeter.im>

On 2/24/09 8:53 AM, Ji?? Z?rev?ck? wrote:
> Hello all.
> 
> I've been thinking about the current subscription management in the
> XMPP-IM for some time now. I think it's not very well designed.

Where were you in 1999?!? We could have used your help back then.

> For example, there's an obvious redundancy in the roster pushes and
> subscription stanzas. For (almost) every subscription update /
> request, there is a presence stanza and a roster push. But that only
> applies to the contact, who receives the change. Also, the "ask"
> attribute looks like a maimed boolean and roster pushes do not contain
> all the state information - inbound request is missing.
> 
> Even though the client can track most of the changes by tracking
> roster pushes and subscription stanzas, there is one change client can
> never track. When there is an inbound subscription request with no
> item and user declines it, other resources get no push and no presence
> stanza - no notification. That is not really a big problem, but all
> this inconsistency in pushes and presence stanzas makes it all seem
> very chaotic and untidy.

Yep. But what is broken? We don't make protocol changes just for aesthetics.

> Originally, I wanted to propose modifying roster pushes so they
> contain all the state information (including eventual inbound
> subscription request message), essentially leaving
> subscription-managing presence stanzas only as the mean of requesting
> the change, not presenting it to the other entity or the other
> resources. Then one thing occured to me. Do we really need a separate
> subscription handling for inbound and outbound presences? Users
> generally don't want it separate. Users want mutual subscription. Is
> there ever need to have one-side subscription?

Sometimes. But I agree that for most end users they don't need that.
IMHO this is a client interface issue, not a protocol issue.

> Providing mechanism for just a mutual subscription, where there would
> be only both-direction or pending or no subscription at all, would
> immensely simplify things for both users and implementers. Yes, I
> agree that immediate effect would be increasing complexity and need of
> additional effort to maintain backward compatibility. 

There's the rub. This kind of effort is a non-starter.

> That would be a
> tricky task, but I believe that with proper interoperability rules, it
> would be possible to make transition relatively painless. I believe
> that in a long run, such change would be a huge improvement.

For whom?

> So, in case you are interested in this idea, I will continue with some
> semantics I have on my mind. Otherwise, just tell me why do you think
> it is not possible / feasible / wanted to implement it. I'm pretty
> sure there is some hidden problem with this I don't realize. I suppose
> many of you won't take me too seriously, since it would require too
> massive change to the core protocol, but I'd appreciate if you thought
> about it a bit. Thanks for any feedback.

My feedback is: don't waste time on this kind of project. The problems
with backwards-compatibility make it infeasible.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/9e47616a/attachment.bin 

From stpeter at stpeter.im  Fri Apr 10 17:34:24 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 16:34:24 -0600
Subject: [Standards] Inconsistent Subscriptions in XMPP
In-Reply-To: <333428.3869.qm@web95410.mail.in2.yahoo.com>
References: <333428.3869.qm@web95410.mail.in2.yahoo.com>
Message-ID: <49DFC970.2060803@stpeter.im>

On 4/1/09 12:07 PM, Mridul Muralidharan wrote:
> 
> 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 ?

You can probe anything you want. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/ff9615b2/attachment-0001.bin 

From stpeter at stpeter.im  Fri Apr 10 17:40:49 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 16:40:49 -0600
Subject: [Standards] Inconsistent Subscriptions in XMPP
In-Reply-To: <49DAF688.9090805@goodadvice.pages.de>
References: <20090224014950.0b613c9f@tiger>
	<49DAF688.9090805@goodadvice.pages.de>
Message-ID: <49DFCAF1.90702@stpeter.im>

On 4/7/09 12:45 AM, Philipp Hancke wrote:
> hijacking the thread... two concrete examples where error handling
> is needed:
> 
> subscription state is "none" initially:
> SENT: <presence to="foo at bar" id="jcl_37" type='subscribe'/>
> RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='push'
> type='set'><query xmlns='jabber:iq:roster'><item ask='subscribe'
> subscription='none' jid='foo at bar'/></query></iq>
> RECV: <presence from='foo at bar' to='me at local/Exodus' type='error'
> id='jcl_37'><error code='404' type='cancel'><remote-server-not-found
> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence>
> 
> after relogin and roster fetch:
> RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='jcl_40'
> type='result'><query xmlns='jabber:iq:roster'><item ask='subscribe'
> subscription='none' jid='foo at bar'/>
> 
> The presence error (which, as can be by looking at the id attribute,
> is a reply to the initial subscribe) does not affect the subscription
> state.

IMHO the server needs to periodically resend the subscribe to the
contact if the state remains ask="subscribe" (no reply received from the
contact). I'm pretty sure that I added something about this to rfc3921bis.

> subscription state is "both" initially:
> SENT: <iq id="jcl_50" type="set"><query xmlns="jabber:iq:roster"><item
> jid="some at jid" subscription="remove"/></query></iq>
> RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='push'
> type='set'><query xmlns='jabber:iq:roster'><item subscription='remove'
> jid='some at jid'/></query></iq>
> RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='jcl_50'
> type='result'/>
> RECV: <presence from='some at jid' to='me at local/Exodus' type='error'><error
> code='404' type='cancel'><remote-server-not-found
> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence>
> RECV: <presence from='some at jid' to='me at local/Exodus' type='error'><error
> code='404' type='cancel'><remote-server-not-found
> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence>
> 
> The subscription state is "none" afterwards - which is the users intention.
> The presence errors are replies to unsubscribe/unsubscribed stanzas
> generated by the server and should imo never have been sent to the
> client.

Agreed -- the server should eat those.

> The question is: how do error replies to presence subscription
> stanzas affect the subscription state?

That's up to the server. Smart servers will do the right thing. So we
need smarter servers (and to provide some advice in rfc3921bis).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/dd6d09e7/attachment.bin 

From stpeter at stpeter.im  Fri Apr 10 17:47:13 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 16:47:13 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <20090224190406.4cb35663@tiger>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>
	<20090224190406.4cb35663@tiger>
Message-ID: <49DFCC71.1050406@stpeter.im>

On 2/24/09 11:04 AM, Pavel Simerda wrote:
> On Tue, 24 Feb 2009 09:14:13 +0000
> Dave Cridland <dave at cridland.net> wrote:
> 
> What I would like... is to have an easy-to-understand and
> easy-to-implement piggybacking feature without unnecessary hassle.
> 
>> In fact, by specifying how to do this without actually doing  
>> dialbacks, but instead by verifying the identity of the sender based  
>> on the X.509 cert, we can actually get rid of SASL EXTERNAL and just  
>> use X.509 only, which eliminates the difference between the "first"  
>> authorization and subsequent ones.
> 
> I don't see any reason to get rid of SASL EXTERNAL. I quite like the
> concept of using the same authentication flows for all
> authenticated connections.
> 
> It would be nice to be able to authenticate each virtual connection
> separately. It's a multiplex, anyway, if one associations fails, others
> should remain working.

Right, we need a way to say "once we have a secure connection, we can
add new domains". Joe Hildebrand and I have been talking with some of
the TLS and SASL people about this. One of these days we'll at least
write up the requirements...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/1a6fe6a9/attachment.bin 

From stpeter at stpeter.im  Fri Apr 10 17:51:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 16:51:22 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <20090225165556.43e400e6@tiger>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<20090224191600.2a938cb5@tiger>
	<49A44713.505@goodadvice.pages.de> <20090225165556.43e400e6@tiger>
Message-ID: <49DFCD6A.7010409@stpeter.im>

On 2/25/09 8:55 AM, Pavel Simerda wrote:
> On Tue, 24 Feb 2009 20:14:27 +0100
> Philipp Hancke <fippo at goodadvice.pages.de> wrote:
> 
>> Pavel Simerda wrote:
>>>>>> * connection reuse for multiple s2s links would be a very useful
>>>>>>   feature, ask Dave for details
>>>>> Piggybacking.
>>>> Which is subtly broken in RFC 3920 - at least 50% of it.
>>>> <host-unknown/> makes 'target piggybacking' (different to)
>>>> unusable, as you risk the entire stream.
>>> Please provide more specific info about how to fix it in bis 
>> I fixed in in my working copy of 220 by completly getting rid of
>> host-unknown for dialback. type='error' seems a good fix.
>>
>>  > and if/why it is broken now.
>>
>> The relevant passage from 3920 about piggybacking is:
>> "After successful dialback negotiation, the Receiving Server SHOULD
>>   accept subsequent <db:result/> packets (e.g., validation requests
>> sent to a subdomain or other hostname serviced by the Receiving
>> Server) from the Originating Server over the existing validated
>> connection; this enables "piggybacking" of the original validated
>> connection in one direction."
>>
>> If the receiving server is 'jabber.org', "validation requests sent
>>   to a subdomain or other hostname serviced by the Receiving Server"
>> means that I can piggyback stanzas to 'users.jabber.org' on that
>> connection (target piggybacking, google uses source piggybacking).
>>
>> draft-saintandre-rfc3920bis-08.html added the host-unknown stream
>> error to dialback with the following description:
>> the value of the 'to' attribute provided by the initiating entity in
>> the stream header does not correspond to a hostname that is hosted by
>> the ^^^^^^^^^^^^^
>> server.
>>
>> Now what happens should I attempt to piggyback the users.jabber.org
>> connection on the jabber.org connection? jabber.org kills my stream.
> 
> As I said to Peter....
> 
> IMO the whole idea of piggybacking is misguided. Piggybacking means
> re-using a connection A for data that would otherwise come in B.
> 
> It would be better to think about it as a generic multiplex. Then all
> virtual connections would be equal (A and B, specifically). One would
> immediately see the consequences of closing the physical connection
> (that should only be closed if all virtual connections are closed).
> 
> Keeping this as an optional feature (I believe that is a near consensus)
> will further simplify the most basic implementations.

That's the general idea, yes.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/d2645e76/attachment-0001.bin 

From stpeter at stpeter.im  Fri Apr 10 18:04:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 17:04:21 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49A44713.505@goodadvice.pages.de>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<20090224191600.2a938cb5@tiger>
	<49A44713.505@goodadvice.pages.de>
Message-ID: <49DFD075.5000703@stpeter.im>

On 2/24/09 12:14 PM, Philipp Hancke wrote:
> Pavel Simerda wrote:
>>>>> * connection reuse for multiple s2s links would be a very useful
>>>>>   feature, ask Dave for details
>>>> Piggybacking.
>>> Which is subtly broken in RFC 3920 - at least 50% of it.
>>> <host-unknown/> makes 'target piggybacking' (different to)
>>> unusable, as you risk the entire stream.
>>
>> Please provide more specific info about how to fix it in bis 
> 
> I fixed in in my working copy of 220 by completly getting rid of
> host-unknown for dialback. type='error' seems a good fix.
> 
>> and if/why it is broken now.
> 
> The relevant passage from 3920 about piggybacking is:
> "After successful dialback negotiation, the Receiving Server SHOULD
>  accept subsequent <db:result/> packets (e.g., validation requests sent
>  to a subdomain or other hostname serviced by the Receiving Server) from
>  the Originating Server over the existing validated connection; this
>  enables "piggybacking" of the original validated connection in one
>  direction."
> 
> If the receiving server is 'jabber.org', "validation requests sent
>  to a subdomain or other hostname serviced by the Receiving Server"
> means that I can piggyback stanzas to 'users.jabber.org' on that
> connection (target piggybacking, google uses source piggybacking).
> 
> draft-saintandre-rfc3920bis-08.html added the host-unknown stream
> error to dialback with the following description:
> the value of the 'to' attribute provided by the initiating entity in the
> stream header does not correspond to a hostname that is hosted by the
> ^^^^^^^^^^^^^
> server.
> 
> Now what happens should I attempt to piggyback the users.jabber.org
> connection on the jabber.org connection? jabber.org kills my stream.

Really? Why?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/8b79e98c/attachment.bin 

From stpeter at stpeter.im  Fri Apr 10 18:09:52 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 17:09:52 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49A3C79E.9030009@goodadvice.pages.de>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>
	<49A3C79E.9030009@goodadvice.pages.de>
Message-ID: <49DFD1C0.2020906@stpeter.im>

On 2/24/09 3:10 AM, Philipp Hancke wrote:
> Dave Cridland wrote:
>> On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote:
>>> * bidirectional s2s could be announced in <stream:features> sent
>>>   right after the opening <stream> tag from the initiator.
> 
> Unidirectional S2S has been around for too long, I do not see a real
> gain in fixing that now.

That was an artifact of dialback. If we have mutual authentication via
TLS+SASL then why not have a bidirectional s2s connection?

>>> * connection reuse for multiple s2s links would be a very useful
>>>   feature, ask Dave for details
>> Piggybacking.
> 
> Which is subtly broken in RFC 3920 - at least 50% of it.
> <host-unknown/> makes 'target piggybacking' (different to)
> unusable, as you risk the entire stream.

I'm not so sure about that. <host-unknown/> means you're trying to
communicate with a domain that I don't host at my server.

>> What I'd like to do here is use the dialback elements as an
>> authorization request mechanism.
> 
> Dialback is 50% authorization request, 50% key verification.
> Splitting it up accordingly simplifies the description.

As long as it's backwards-compatible.

>> In fact, by specifying how to do this without actually doing
>> dialbacks, but instead by verifying the identity of the sender based
>> on the X.509 cert, we can actually get rid of SASL EXTERNAL and just
>> use X.509 only, which eliminates the difference between the "first"
>> authorization and subsequent ones.
> 
> There is no 'subsequent' auth with 0178 yet, is there?

There is no subsequent auth anywhere, yet.

> There are three different options:
> 1) do 0178 and add subsequent auth (including graceful failure)
> 2) do 0178 for the first authorization and use piggybacking (with
>    graceful failure again) for subsequent authorization... err...
>    verification
> 3) ignore any 0178 offers and do piggybacking for everything.
>    Might be a problem if servers require 0178 and really mean it.
> 
>> The dialback flow then becomes:
>>
>> 1) O2R : <db:result/>
>> 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT
> 
> Assumes that the originating server does not check with the
> authoritative server that the receiving server has verified
> the key.
> 
>> 3) R: Connect to A
>> 4) R2A: Establish TLS.
>> 5) R2A: If A's certificate matches O's, goto ACCEPT
> 
> Nice optimization ;-)
> 
>> 6) R2A: <db:verify/>
>> 7) A2R: <db:verify/>, goto ACCEPT
>> ACCEPT:
>> 8) R2O: Authorize O as requested domain, send <db:result/>

It's still not clear to me what TLS+dialback really means. If you're
going to do TLS, use real certs and then you can do authentication via
SASL EXTERNAL.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/60af2ab7/attachment.bin 

From stpeter at stpeter.im  Fri Apr 10 18:24:45 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 10 Apr 2009 17:24:45 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <2033.1235466853.517526@peirce.dave.cridland.net>
References: <20090224013125.2a8f6fed@tiger>
	<2033.1235466853.517526@peirce.dave.cridland.net>
Message-ID: <49DFD53D.5090008@stpeter.im>

On 2/24/09 2:14 AM, Dave Cridland wrote:
> On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote:
>> * bidirectional s2s could be announced in <stream:features> sent
>>   right after the opening <stream> tag from the initiator.
>>
>>
> Well...
> 
> What you need is to:
> 
> a) Signal the ability of the receiver to handle features sent by the
> initiator.
> 
> b) Signal the ability of the initiator to handle bidi streams.
> 
> c) Turn this on, which presumably involves an authorization phase.
> 
> I was thinking that the receiver has a stream:feature to handle
> stream:features, the initiator then sends these, and the receiver can
> then proceed as the initiator in the other direction. So the initiator
> would send SASL mechanisms, and the receiver would act as a SASL client
> to the initator and request authorization.

Interesting. I think we need a separate thread about this topic. I'll
try to start that soon.

>> * connection reuse for multiple s2s links would be a very useful
>>   feature, ask Dave for details
>>
>>
> Piggybacking.
> 
> What I'd like to do here is use the dialback elements as an
> authorization request mechanism.

I think that connection re-use is broader than dialback.

> In fact, by specifying how to do this without actually doing dialbacks,
> but instead by verifying the identity of the sender based on the X.509
> cert, we can actually get rid of SASL EXTERNAL and just use X.509 only,
> which eliminates the difference between the "first" authorization and
> subsequent ones.

I'm not convinced of that. Why get rid of SASL EXTERNAL? (It seems
preferable to use TLS+SASL for both c2s and s2s.) And what does it mean
to "just use X.509"?

> The dialback flow then becomes:
> 
> 1) O2R : <db:result/>
> 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT
> 3) R: Connect to A
> 4) R2A: Establish TLS.
> 5) R2A: If A's certificate matches O's, goto ACCEPT
> 6) R2A: <db:verify/>
> 7) A2R: <db:verify/>, goto ACCEPT
> ACCEPT:
> 8) R2O: Authorize O as requested domain, send <db:result/>

Perhaps. :)

>> * resource conflicts should be handled consistently in servers
>>
>>
> It's not always possible to handle conflicts in the same way.

What do we mean by "handled consistently"?

>> * an explicit way to kick other resources might be very handy
>>
>>
> Here be tigers.

I'd rather punt on this one. What problem are we solving here, exactly?
Can't we use XEP-0146 for this?

>> * multiple resources could have a less confusing named feature (not
>>   unbind, but something like multi-bind probably)
>>
>>
> I'm less than convinced about the validity of multiple resources as a
> solution to any problem.

I think we have consensus to remove this from rfc3920bis.

>> * xml:lang per stanza seems to be pretty rare, I would prefer MAY to
>>   SHOULD, or even to discurage per-stanza xml:lang entirerely and
>>   encourage use of xml:lang only for elements with localized strings.
>>   Many users (and also client developers) just don't care about
>>   languages. Unqualified strings are (and will be) very common, I would
>>   use MAY even for the elements.
>>
>>
> In principle, the stanza-level xml:lang can be used especially over S2S
> sessions to indicate a preferred language for errors.
> 
> However... various protocols have had features like this for years, and
> to the best of my knowledge nobody ever uses them.

So it seems. So perhaps Pavel's proposal is appropriate.

>> * "gone" has a very good usecase that could be made explicit... it is
>>   JID redirection and could be handled by clients (e.g. the client could
>>   offer the user to add the new JID upon error - presence/message
>>   would trigger it).
>>
>>
> Right - a jid redirection would be useful. We'd also need to put
> together a companion protocol for users to enable it.

http://xmpp.org/extensions/inbox/forwarding-delivery.html

http://xmpp.org/extensions/inbox/forwarding-request.html

>> * Consider including XEP-198 Stream Management in the RFC
> 
> We need to actually prove it, first. I don't think anyone's got as far
> as coding it, yet.

Now we have Prosody on the server side and Lampiro on the client side.
Time for some testing. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090410/d22d2000/attachment-0001.bin 

From zarevucky.jiri at gmail.com  Fri Apr 10 19:08:50 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Sat, 11 Apr 2009 02:08:50 +0200
Subject: [Standards] XMPP-IM - presence subscription handling
In-Reply-To: <49DFC822.6010300@stpeter.im>
References: <e962983d0902240753o181f7c33nbc0aaf0459f60bfc@mail.gmail.com>
	<49DFC822.6010300@stpeter.im>
Message-ID: <e962983d0904101708r577fd767qe8f22057ce4e82b9@mail.gmail.com>

2009/4/11 Peter Saint-Andre <stpeter at stpeter.im>:
>
> My feedback is: don't waste time on this kind of project. The problems
> with backwards-compatibility make it infeasible.
>
> Peter
>

Yeah. I sometimes get very stupid ideas. Sorry about that. :)

From mridulm80 at yahoo.com  Fri Apr 10 21:36:35 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Sat, 11 Apr 2009 08:06:35 +0530 (IST)
Subject: [Standards] Inconsistent Subscriptions in XMPP
Message-ID: <692736.72700.qm@web95403.mail.in2.yahoo.com>




--- On Sat, 11/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> From: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards" <standards at xmpp.org>
> Date: Saturday, 11 April, 2009, 4:04 AM
> On 4/1/09 12:07 PM, Mridul
> Muralidharan wrote:
> > 
> > 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 ?
> 
> You can probe anything you want. :)


I should have clarified better.

Assume that there is mutual subscription between userA and userB.
Support we have :

userA has session userA at domain/resA
userB has session userB at domain/resB1
userB has session userB at domain/resB2


After presence has been exchanged, suppose userA blocks userB (or all users) - so an unavailable presence is sent to userB's resources.
Subsequent to that, suppose userA sends available to one of the resources, say - userB at domain/resB1

Now, iirc, if resB2 probes, userA's server must return unavailable.
But if resB1 probes, userA's server must return the last directed presence sent (subsequent to unavailable).

We could replace userB with muc or any other component in the above.




IIRC this was a usecase discussed quite a while back - was it removed ?
If not, my query was, how does it interact with this list below related to probes, etc.


Thanks,
Mridul





> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From fabio.forno at gmail.com  Sat Apr 11 05:25:08 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Sat, 11 Apr 2009 12:25:08 +0200
Subject: [Standards] roster partial activation & privacy lists
In-Reply-To: <49DEA9FA.7010503@stpeter.im>
References: <2fd53c3a0903180719s6dd3d3b8xb018c0aa1b62a302@mail.gmail.com>
	<49DEA9FA.7010503@stpeter.im>
Message-ID: <2fd53c3a0904110325v61d16d1byec0adbaec965e649@mail.gmail.com>

On Fri, Apr 10, 2009 at 4:07 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:

[Privacy list management]
> Another possible hack is to create a "temp" group and add/subtract
> people in that group (leaving VIPs alone).
>

Yep, nice thought. This suggests me that perhaps hiding privacy lists
from users and doing a bit of group and rule name standardization as
for dataforms could solve many of the problems with them.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From stpeter at stpeter.im  Sat Apr 11 10:03:20 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sat, 11 Apr 2009 09:03:20 -0600
Subject: [Standards] roster partial activation & privacy lists
In-Reply-To: <2fd53c3a0904110325v61d16d1byec0adbaec965e649@mail.gmail.com>
References: <2fd53c3a0903180719s6dd3d3b8xb018c0aa1b62a302@mail.gmail.com>	<49DEA9FA.7010503@stpeter.im>
	<2fd53c3a0904110325v61d16d1byec0adbaec965e649@mail.gmail.com>
Message-ID: <49E0B138.9050603@stpeter.im>

On 4/11/09 4:25 AM, Fabio Forno wrote:
> On Fri, Apr 10, 2009 at 4:07 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 
> [Privacy list management]
>> Another possible hack is to create a "temp" group and add/subtract
>> people in that group (leaving VIPs alone).
>>
> 
> Yep, nice thought. This suggests me that perhaps hiding privacy lists
> from users 

+1

> and doing a bit of group and rule name standardization as
> for dataforms could solve many of the problems with them.

Not a bad idea. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090411/e52f97a5/attachment.bin 

From stpeter at stpeter.im  Sun Apr 12 14:15:26 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 12 Apr 2009 13:15:26 -0600
Subject: [Standards] Inconsistent Subscriptions in XMPP
In-Reply-To: <692736.72700.qm@web95403.mail.in2.yahoo.com>
References: <692736.72700.qm@web95403.mail.in2.yahoo.com>
Message-ID: <49E23DCE.6030507@stpeter.im>

On 4/10/09 8:36 PM, Mridul Muralidharan wrote:
> 
> 
> --- On Sat, 11/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 
>> From: Peter Saint-Andre <stpeter at stpeter.im> Subject: Re:
>> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards"
>> <standards at xmpp.org> Date: Saturday, 11 April, 2009, 4:04 AM On
>> 4/1/09 12:07 PM, Mridul Muralidharan wrote:
>>> 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 ?
>> 
>> You can probe anything you want. :)
> 
> 
> I should have clarified better.
> 
> Assume that there is mutual subscription between userA and userB. 
> Support we have :
> 
> userA has session userA at domain/resA 
> userB has session userB at domain/resB1
> userB has session userB at domain/resB2
> 
> 
> After presence has been exchanged, suppose userA blocks userB (or all
> users) - so an unavailable presence is sent to userB's resources. 
> Subsequent to that, suppose userA sends available to one of the
> resources, say - userB at domain/resB1
> 
> Now, iirc, if resB2 probes, userA's server must return unavailable. 

That seems reasonable.

> But if resB1 probes, userA's server must return the last directed
> presence sent (subsequent to unavailable).

That also seems reasonable.

> We could replace userB with muc or any other component in the above.

Right. The MUC example is more apropos.

> IIRC this was a usecase discussed quite a while back - was it removed
> ? If not, my query was, how does it interact with this list below

We had some text about this in rfc3921bis but IIRC we removed it because
people thought it belonged in XEP-0045 (e.g., an implementation note on
"how to remove ghost users"), not the RFC. However, I think the text
never made it to XEP-0045. I'll check on that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090412/f5f65ba7/attachment.bin 

From mridulm80 at yahoo.com  Sun Apr 12 14:20:38 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Mon, 13 Apr 2009 00:50:38 +0530 (IST)
Subject: [Standards] Inconsistent Subscriptions in XMPP
Message-ID: <601084.76576.qm@web95402.mail.in2.yahoo.com>




--- On Mon, 13/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> From: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards" <standards at xmpp.org>
> 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 <stpeter at stpeter.im>
> wrote:
> > 
> >> From: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re:
> >> [Standards] Inconsistent Subscriptions in XMPP To:
> "XMPP Standards"
> >> <standards at xmpp.org>
> Date: Saturday, 11 April, 2009, 4:04 AM On
> >> 4/1/09 12:07 PM, Mridul Muralidharan wrote:
> >>> 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 ?
> >> 
> >> You can probe anything you want. :)
> > 
> > 
> > I should have clarified better.
> > 
> > Assume that there is mutual subscription between userA
> and userB. 
> > Support we have :
> > 
> > userA has session userA at domain/resA 
> > userB has session userB at domain/resB1
> > userB has session userB at domain/resB2
> > 
> > 
> > After presence has been exchanged, suppose userA
> blocks userB (or all
> > users) - so an unavailable presence is sent to userB's
> resources. 
> > Subsequent to that, suppose userA sends available to
> one of the
> > resources, say - userB at domain/resB1
> > 
> > Now, iirc, if resB2 probes, userA's server must return
> unavailable. 
> 
> That seems reasonable.
> 
> > But if resB1 probes, userA's server must return the
> last directed
> > presence sent (subsequent to unavailable).
> 
> That also seems reasonable.
> 
> > We could replace userB with muc or any other component
> in the above.
> 
> Right. The MUC example is more apropos.
> 
> > IIRC this was a usecase discussed quite a while back -
> was it removed
> > ? If not, my query was, how does it interact with this
> list below
> 
> We had some text about this in rfc3921bis but IIRC we
> removed it because
> people thought it belonged in XEP-0045 (e.g., an
> implementation note on
> "how to remove ghost users"), not the RFC. However, I think
> the text
> never made it to XEP-0045. I'll check on that.


Shouldn't this not be part of the CORE xmpp spec ?
Privacy enforcement, routing decisions, presence management happen within the server - and only server has visibility of the user's stanza history to support this imo - so, if required, wouldn't it not be for the server to handle it ? ('it' being responding to probe with previous presence stanza in case of directed presence - or maybe this is already there and I just did not see it ?).

A quick search did not reveal much on discussion about this - any overriding reason why this was pulled out ?


Thanks,
Mridul

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From stpeter at stpeter.im  Sun Apr 12 14:25:18 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 12 Apr 2009 13:25:18 -0600
Subject: [Standards] Inconsistent Subscriptions in XMPP
In-Reply-To: <601084.76576.qm@web95402.mail.in2.yahoo.com>
References: <601084.76576.qm@web95402.mail.in2.yahoo.com>
Message-ID: <49E2401E.2020209@stpeter.im>

On 4/12/09 1:20 PM, Mridul Muralidharan wrote:
> 
> 
> --- On Mon, 13/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 
>> From: Peter Saint-Andre <stpeter at stpeter.im> Subject: Re:
>> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards"
>> <standards at xmpp.org> 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 <stpeter at stpeter.im>
>> wrote:
>>>> From: Peter Saint-Andre <stpeter at stpeter.im>
>> Subject: Re:
>>>> [Standards] Inconsistent Subscriptions in XMPP To:
>> "XMPP Standards"
>>>> <standards at xmpp.org>
>> Date: Saturday, 11 April, 2009, 4:04 AM On
>>>> 4/1/09 12:07 PM, Mridul Muralidharan wrote:
>>>>> 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 ?
>>>> 
>>>> You can probe anything you want. :)
>>> 
>>> I should have clarified better.
>>> 
>>> Assume that there is mutual subscription between userA
>> and userB.
>>> Support we have :
>>> 
>>> userA has session userA at domain/resA userB has session
>>> userB at domain/resB1 userB has session userB at domain/resB2
>>> 
>>> 
>>> After presence has been exchanged, suppose userA
>> blocks userB (or all
>>> users) - so an unavailable presence is sent to userB's
>> resources.
>>> Subsequent to that, suppose userA sends available to
>> one of the
>>> resources, say - userB at domain/resB1
>>> 
>>> Now, iirc, if resB2 probes, userA's server must return
>> unavailable.
>> 
>> That seems reasonable.
>> 
>>> But if resB1 probes, userA's server must return the
>> last directed
>>> presence sent (subsequent to unavailable).
>> That also seems reasonable.
>> 
>>> We could replace userB with muc or any other component
>> in the above.
>> 
>> Right. The MUC example is more apropos.
>> 
>>> IIRC this was a usecase discussed quite a while back -
>> was it removed
>>> ? If not, my query was, how does it interact with this
>> list below
>> 
>> We had some text about this in rfc3921bis but IIRC we removed it
>> because people thought it belonged in XEP-0045 (e.g., an 
>> implementation note on "how to remove ghost users"), not the RFC.
>> However, I think the text never made it to XEP-0045. I'll check on
>> that.
> 
> 
> Shouldn't this not be part of the CORE xmpp spec ? Privacy
> enforcement, routing decisions, presence management happen within the
> server - and only server has visibility of the user's stanza history
> to support this imo - so, if required, wouldn't it not be for the
> server to handle it ? ('it' being responding to probe with previous
> presence stanza in case of directed presence - or maybe this is
> already there and I just did not see it ?).
> 
> A quick search did not reveal much on discussion about this - any
> overriding reason why this was pulled out ?

People found it confusing and MUC-specific. However, that was for the
full use case. I do think that rfc3921bis needs to say something about
answering probes from entities to which you've sent directed presence,
so that would belong in Section 4.3.2 or Section 4.6.2 of rfc3921bis.

I'll add that to my task list for the RFC revisions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090412/4e1a71e6/attachment-0001.bin 

From zarevucky.jiri at gmail.com  Mon Apr 13 12:18:39 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Mon, 13 Apr 2009 19:18:39 +0200
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <49DE1ADB.3020309@stpeter.im>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com> <49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
	<49DE1ADB.3020309@stpeter.im>
Message-ID: <e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>

Hi, I have a question about a particular scenario (it's a bit
simplified, just for illustration).

This is the initial state:

<query ver="300">
? ?<item jid="contact1 at jabber.org" subscription="none" />
? ?<item jid="contact2 at jabber.org" subscription="none" />
? ?...
</query>


Now magine you have four pushes in the following order:

<query ver="301">
? ?<item jid="contact1 at jabber.org" name="Contact 1" />
</query>

<query ver="302">
? ?<item jid="contact2 at jabber.org" name="Contact 2" />
</query>

<query ver="303">
? ?<item jid="contact1 at jabber.org" subscription="both" />
</query>

<query ver="304">
? ?<item jid="contact2 at jabber.org" subscription="both" />
</query>


So, when the client requests a difference from ver="300", it should
receive only the final state, but when it receives the final state of
contact1:

<query ver="303">
    <item jid="contact1 at jabber.org" subscription="both" name="Contact 1" />
</query>

,the client now thinks it has the full state for ver="303". If for
some reason connection fails at the moment, the client would next
request state 303, losing information about contact2's new name.

Am I right? Any idea how to handle it fool-proof way without actually
sending two interim pushes for contact1?
Or maybe just specify that the client must not store the new changes
until everything is received.

From zarevucky.jiri at gmail.com  Mon Apr 13 12:22:04 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Mon, 13 Apr 2009 19:22:04 +0200
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com> <49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
	<49DE1ADB.3020309@stpeter.im>
	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
Message-ID: <e962983d0904131022o59c878fdyfd51ee47dc07b61b@mail.gmail.com>

Dne 13. duben 2009 19:18 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com> napsal(a):
> Hi, I have a question about a particular scenario (it's a bit
> simplified, just for illustration).
> .....

Ok, I probably just made an idiot from myself. I for some reason
didn't realize that the item is still send complete. :( Sorry...

From badlop at gmail.com  Mon Apr 13 14:16:00 2009
From: badlop at gmail.com (Badlop)
Date: Mon, 13 Apr 2009 21:16:00 +0200
Subject: [Standards] Problem after enabling MUC in ejabberd
In-Reply-To: <imoracle.3pzqs0@no-mx.jabberforum.org>
References: <imoracle.3pzqs0@no-mx.jabberforum.org>
Message-ID: <732f49190904131216k4a0dcb0aw4e326131f250f2cb@mail.gmail.com>

2009/4/2 imoracle <imoracle.3pzqs0 at no-mx.jabberforum.org>:
> I am trying to dig into MUC protocol, but I have having problem on my
> very first step.
>
> I went to ejabberd.cfg and added the following for enabling group
> chat:

Your question seems to be administering a Jabber server, so probably
the correct mailing list would be
http://mail.jabber.org/mailman/listinfo/jadmin , not the Standards
mailing list.


> ?{host_config, "localhost", [{auth_method, [anonymous]}, {anonymous_protocol, sasl_anon}]}.

> However after enabling MUC chat in ejabberd, all of a sudden I am
> unable to log in as single user using PSI IM. It just replies back as
> wrong authentication credentials.

If you configure ejabberd to only allow "SASL Anonymous
authentication", obviously you can only authenticate using that
method. Does Psi support it? If so, did you enable such method in your
client?

I found this:
XEP-0175: Best Practices for Use of SASL ANONYMOUS
http://xmpp.org/extensions/xep-0175.html

I don't find that XEP mentioned in
http://psi-im.org/wiki/Supported_Protocols

Tkabber, Gajim, and Jabbim don't support that XEP, either. I don't
know if there is any mainstream Jabber client that supports that XEP.


> However if i disable ANONYMOUS login, I can successfully login as
> single user.


>  {mod_muc,      [
>                  {host, "localhost"},
>                  {access, muc},
>                  {access_create, muc},
>                  {access_persistent, muc},
>                  {access_admin, muc_admin}
>                 ]},

The value you set for option host of mod_muc is terribly wrong.
You must check the "ejabberd Installation and Operation Guide".
It says:

> 3.3.8 mod_muc
> Module options:
>    * host
>    This option defines the Jabber ID of the service.
>    If the host option is not specified, the Jabber ID will be the hostname of the virtual host
>    with the prefix ?conference.?.

In case of doubt, the file ejabberd.cfg.example includes this example:

>  {mod_muc,      [
>		  %%{host, "conference. at HOST@"},
>		  {access, muc},
>		  {access_create, muc},
>		  {access_persistent, muc},
>		  {access_admin, muc_admin}
>		 ]},

So, if you set this in your ejabberd.cfg:
{hosts, ["localhost"]}.
{modules, [
  {mod_muc, [ {host, "localhost"} ]},
  ...
 ]}.
what are you telling ejabberd?

You are telling it that you want:
1. one Jabber/XMPP server with JID: "localhost"
2. one MUC service with JID: "localhost"

Do you expect that to work correctly?

It is preferable to put:
  {mod_muc, [ {host, "conference.localhost"} ]},
or quite simply don't specify any host option and let ejabberd decide it:
  {mod_muc, [  ]},


> Finally I am unable to join any chat room using PSI-IM ->
> Join Group chat feature.

With that terrible 'host' option value you set, it would be a surprise
that it worked ;)


---

From dave at cridland.net  Mon Apr 13 18:57:39 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 14 Apr 2009 00:57:39 +0100
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com> <49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
	<49DE1ADB.3020309@stpeter.im>
	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
Message-ID: <31062.1239667059.266787@puncture>

On Mon Apr 13 18:18:39 2009, Ji?? Z?rev?ck? wrote:
> Am I right?

Yes, you are, well spotted.

>  Any idea how to handle it fool-proof way without actually
> sending two interim pushes for contact1?

Yes, you don't want to send two interim responses, since then servers  
would actually have to remember what versions were.


> Or maybe just specify that the client must not store the new changes
> until everything is received.

That's the simplest option, yes - we can just add that at the end of  
section 2.4, where it describes how to check if everything has been  
received yet.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Mon Apr 13 19:00:15 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 13 Apr 2009 18:00:15 -0600
Subject: [Standards] PubSub revisions
Message-ID: <49E3D20F.9070301@stpeter.im>

FYI, I have started to process the ~100 emails that I've received over
the last 6 months regarding the PubSub specification (XEP-0060). No
matter whether the original message was sent to standards at xmpp.org or
pubsub at xmpp.org, I will post the reply to the pubsub@ list (because most
of these items are errata or not of general interest on standards@). If
you are not subscribed to the pubsub@ list and want to track these
discussion, please subscribe via:

http://mail.jabber.org/mailman/listinfo/pubsub

or

mailto:pubsub-subscribe at xmpp.org

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090413/0f8d507d/attachment.bin 

From stpeter at stpeter.im  Mon Apr 13 19:57:53 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 13 Apr 2009 18:57:53 -0600
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <31062.1239667059.266787@puncture>
References: <E1Lre0m-0003z0-00@apollo>
	<200904091224.55856.sachin@geodesic.com>	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>	<200904091927.45127.sachin@geodesic.com>
	<49DE0C02.5010908@stpeter.im>	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>	<49DE1ADB.3020309@stpeter.im>	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
	<31062.1239667059.266787@puncture>
Message-ID: <49E3DF91.1050401@stpeter.im>

On 4/13/09 5:57 PM, Dave Cridland wrote:
> On Mon Apr 13 18:18:39 2009, Ji?? Z?rev?ck? wrote:
>> Am I right?
> 
> Yes, you are, well spotted.
> 
>>  Any idea how to handle it fool-proof way without actually
>> sending two interim pushes for contact1?
> 
> Yes, you don't want to send two interim responses, since then servers
> would actually have to remember what versions were.
> 
> 
>> Or maybe just specify that the client must not store the new changes
>> until everything is received.
> 
> That's the simplest option, yes - we can just add that at the end of
> section 2.4, where it describes how to check if everything has been
> received yet.

That seems sensible.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090413/53666f0b/attachment-0001.bin 

From stpeter at stpeter.im  Mon Apr 13 20:26:23 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 13 Apr 2009 19:26:23 -0600
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <49E3DF91.1050401@stpeter.im>
References: <E1Lre0m-0003z0-00@apollo>	<200904091224.55856.sachin@geodesic.com>	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>	<200904091927.45127.sachin@geodesic.com>	<49DE0C02.5010908@stpeter.im>	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>	<49DE1ADB.3020309@stpeter.im>	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>	<31062.1239667059.266787@puncture>
	<49E3DF91.1050401@stpeter.im>
Message-ID: <49E3E63F.8070400@stpeter.im>

On 4/13/09 6:57 PM, Peter Saint-Andre wrote:
> On 4/13/09 5:57 PM, Dave Cridland wrote:
>> On Mon Apr 13 18:18:39 2009, Ji?? Z?rev?ck? wrote:
>>
>>> Or maybe just specify that the client must not store the new changes
>>> until everything is received.
>> That's the simplest option, yes - we can just add that at the end of
>> section 2.4, where it describes how to check if everything has been
>> received yet.
> 
> That seems sensible.

I added the following sentence:

"The client MUST NOT process any of the interim roster pushes until it
has processed all of them (this helps to prevent partial processing if
the client loses its connection to the server before it has received all
of the interim roster pushes)."

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0237.xml?%40diffMode=u&%40diffWrap=s&r1=3026&r2=3043&u=3&ignore=&k=

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090413/4fa20467/attachment.bin 

From fippo at goodadvice.pages.de  Tue Apr 14 00:59:04 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Tue, 14 Apr 2009 07:59:04 +0200
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49DFD075.5000703@stpeter.im>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<20090224191600.2a938cb5@tiger>	<49A44713.505@goodadvice.pages.de>
	<49DFD075.5000703@stpeter.im>
Message-ID: <49E42628.8060509@goodadvice.pages.de>

Peter Saint-Andre wrote:
[snip]
>> Now what happens should I attempt to piggyback the users.jabber.org
>> connection on the jabber.org connection? jabber.org kills my stream.
> 
> Really? Why?

<host-unknown/>.

From fippo at goodadvice.pages.de  Tue Apr 14 00:59:34 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Tue, 14 Apr 2009 07:59:34 +0200
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49DFD1C0.2020906@stpeter.im>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>
	<49DFD1C0.2020906@stpeter.im>
Message-ID: <49E42646.5090805@goodadvice.pages.de>

Peter Saint-Andre
[snip]
>>>> * connection reuse for multiple s2s links would be a very useful
>>>>   feature, ask Dave for details
>>> Piggybacking.
>> Which is subtly broken in RFC 3920 - at least 50% of it.
>> <host-unknown/> makes 'target piggybacking' (different to)
>> unusable, as you risk the entire stream.
> 
> I'm not so sure about that. <host-unknown/> means you're trying to
> communicate with a domain that I don't host at my server.

How does the initiator discover that without running into the error?
DNS does not work even in the same domain.

>>> What I'd like to do here is use the dialback elements as an
>>> authorization request mechanism.
>> Dialback is 50% authorization request, 50% key verification.
>> Splitting it up accordingly simplifies the description.
> 
> As long as it's backwards-compatible.

It is merely a different way of describing it. The protocol already
contains this split:
db:result (authorization part)
db:verify (key verification).

>>> In fact, by specifying how to do this without actually doing
>>> dialbacks, but instead by verifying the identity of the sender based
>>> on the X.509 cert, we can actually get rid of SASL EXTERNAL and just
>>> use X.509 only, which eliminates the difference between the "first"
>>> authorization and subsequent ones.
>> There is no 'subsequent' auth with 0178 yet, is there?
> 
> There is no subsequent auth anywhere, yet.

There is piggybacking :-p

[snip]
> It's still not clear to me what TLS+dialback really means. If you're
> going to do TLS, use real certs and then you can do authentication
> via SASL EXTERNAL.

SASL EXTERNAL is a non-starter in the public network.

From zarevucky.jiri at gmail.com  Tue Apr 14 03:41:28 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 14 Apr 2009 10:41:28 +0200
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <31062.1239667059.266787@puncture>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com> <49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
	<49DE1ADB.3020309@stpeter.im>
	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
	<31062.1239667059.266787@puncture>
Message-ID: <e962983d0904140141p549fc1c0se209cf38e0997a5a@mail.gmail.com>

2009/4/14 Dave Cridland <dave at cridland.net>:
> On Mon Apr 13 18:18:39 2009, Ji?? Z?rev?ck? wrote:
>>
>> Am I right?
>
> Yes, you are, well spotted.
>

Actually, I'm not. My reasoning would require that the items
themselves are partial, which they are not. So the push includes the
complete last known state of the item, not a change.

That means there is no such problem, as even though the client is not
guaranteed to have a complete state on failure, it will have it when
it resumes receiving from the point it left of.

That also means this part can be somewhat misleading:

    4. The interim roster pushes would not include all of the
intermediate steps, only the final
        result of all changes applied while the client was in fact offline.

.. as it suggests that the changes (to a single item) combine, while
in fact they replace each other.

From dave at cridland.net  Tue Apr 14 03:49:13 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 14 Apr 2009 09:49:13 +0100
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904140141p549fc1c0se209cf38e0997a5a@mail.gmail.com>
References: <E1Lre0m-0003z0-00@apollo> <200904091224.55856.sachin@geodesic.com>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com> <49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
	<49DE1ADB.3020309@stpeter.im>
	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
	<31062.1239667059.266787@puncture>
	<e962983d0904140141p549fc1c0se209cf38e0997a5a@mail.gmail.com>
Message-ID: <31062.1239698953.759847@puncture>

On Tue Apr 14 09:41:28 2009, Ji?? Z?rev?ck? wrote:
> 2009/4/14 Dave Cridland <dave at cridland.net>:
> > On Mon Apr 13 18:18:39 2009, Ji?? Z?rev?ck? wrote:
> >>
> >> Am I right?
> >
> > Yes, you are, well spotted.
> >
> 
> Actually, I'm not. My reasoning would require that the items
> themselves are partial, which they are not. So the push includes the
> complete last known state of the item, not a change.
> 
> 
Ah, yes - your reasoning would alternately mean that a single change  
could encompass more than one roster item, which it also cannot (and  
if it could, the solution would be different).

I shouldn't reply to these things so late at night.

> That means there is no such problem, as even though the client is  
> not
> guaranteed to have a complete state on failure, it will have it when
> it resumes receiving from the point it left of.

Yes. So we're both wrong - yay! But thanks for looking into this  
carefully.

> That also means this part can be somewhat misleading:
> 
>     4. The interim roster pushes would not include all of the
> intermediate steps, only the final
>         result of all changes applied while the client was in fact  
> offline.
> 
> .. as it suggests that the changes (to a single item) combine, while
> in fact they replace each other.

I'm not sure they replace, as such - collapse might be a better word.

Changing both subscription state, and, later, changing name, results  
in a single roster push containing both changes. However, changing  
name twice will effectively replace.

I think an example speaks a thousand words, here - since you've a  
feel for this, could you write one? (I'm sure Peter would appreciate  
it).

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From zarevucky.jiri at gmail.com  Tue Apr 14 04:06:50 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 14 Apr 2009 11:06:50 +0200
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <31062.1239698953.759847@puncture>
References: <E1Lre0m-0003z0-00@apollo>
	<4db9cacb0904090539w6e7974c5y6d7528d1ad3399d5@mail.gmail.com>
	<200904091927.45127.sachin@geodesic.com> <49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
	<49DE1ADB.3020309@stpeter.im>
	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
	<31062.1239667059.266787@puncture>
	<e962983d0904140141p549fc1c0se209cf38e0997a5a@mail.gmail.com>
	<31062.1239698953.759847@puncture>
Message-ID: <e962983d0904140206j646ec274g3d86a0fa67f55e1b@mail.gmail.com>

2009/4/14 Dave Cridland <dave at cridland.net>:
>
> I shouldn't reply to these things so late at night.
>

I shouldn't write them so late at night in the first place... :)

>
> I'm not sure they replace, as such - collapse might be a better word.
>
> Changing both subscription state, and, later, changing name, results in a
> single roster push containing both changes. However, changing name twice
> will effectively replace.
>

You can't do that. See:

<query ver="300">
  <item jid="contact at example.org" subscription="none" />
</query>

<query ver="301">
  <item jid="contact at example.org" subscription="none" name="Contact" />
</query>

<query ver="302">
  <item jid="contact at example.org" subscription="to" />
</query>

Now there is no name, as the last push erased it.
If I'm mistaken in this and one of the attributes can be left out to
signify "don't change it", it has to be made explicit in the spec
anyway, as normally leaving out name means "remove".

-----------------------

But I realized there is a rare scenario where it could really cause problem.

<query ver="300">
  <item jid="bob at example.org" subscription="none" />
</query>

<query ver="301">
  <item jid="alice at example.org" subscription="none" />
</query>

<query ver="302">
  <item jid="bob at example.org" name="Bob" subscription="none" />
</query>

<query ver="303">
  <item jid="alice at example.org" subscription="to" />
</query>

<query ver="304">
  <item jid="bob at example.org" name="Bob" subscription="from" />
</query>

<query ver="305">
  <item jid="bob at example.org" name="Bob" subscription="none" />
</query>

Client knows 300. The roster would send 303 first, and 305 second. If
connection failed after sending 303, client would next request 303+,
but never received 302 in the first place.
Now (only) in case the server checks the last state client should
know, it will find out it doesn't need to send the push since there is
the same state as in 302. Client wouldn't receive bob's name until
next change.

That is easily fixed by disallowing servers such checks.

From zarevucky.jiri at gmail.com  Tue Apr 14 04:17:54 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 14 Apr 2009 11:17:54 +0200
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904140206j646ec274g3d86a0fa67f55e1b@mail.gmail.com>
References: <E1Lre0m-0003z0-00@apollo> <200904091927.45127.sachin@geodesic.com>
	<49DE0C02.5010908@stpeter.im>
	<4db9cacb0904090816t15bb5725xe95da6595f3efdae@mail.gmail.com>
	<49DE1ADB.3020309@stpeter.im>
	<e962983d0904131018g70cec5f3m7845853b5d4d518c@mail.gmail.com>
	<31062.1239667059.266787@puncture>
	<e962983d0904140141p549fc1c0se209cf38e0997a5a@mail.gmail.com>
	<31062.1239698953.759847@puncture>
	<e962983d0904140206j646ec274g3d86a0fa67f55e1b@mail.gmail.com>
Message-ID: <e962983d0904140217r2689199arc441d48fc1122ecf@mail.gmail.com>

Dne 14. duben 2009 11:06 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com> napsal(a):
> If I'm mistaken in this and one of the attributes can be left out to
> signify "don't change it", it has to be made explicit in the spec
> anyway, as normally leaving out name means "remove".
>

No, I can't be mistaken since that behavior is relevant to updates
client generate (which is already defined in XMPP-IM)...

From nicolas.verite at gmail.com  Tue Apr 14 04:27:01 2009
From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=)
Date: Tue, 14 Apr 2009 11:27:01 +0200
Subject: [Standards] XEP-0224 Attention
Message-ID: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>

Hi,

Small typo in http://xmpp.org/extensions/xep-0224.html#intro
s/Notificaitons/Notifications/

In 3rd bullet point of section 4,
http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
receive a delayed 'attention', though I propose the change from MUST
to SHOULD.

In 5th bullet point, I propose a change to
"The attention extension MUST NOT use <iq/> stanzas, since use this
feature is part of the conversation."

Regards,
N?co
-- 
Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com
Jabber ID : xmpp:nyco at jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adh?rez ? l'April : http://april.org/

From zarevucky.jiri at gmail.com  Tue Apr 14 04:36:20 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 14 Apr 2009 11:36:20 +0200
Subject: [Standards] XEP-0224 Attention
In-Reply-To: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>
References: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>
Message-ID: <e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>

2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
> Hi,
>
> Small typo in http://xmpp.org/extensions/xep-0224.html#intro
> s/Notificaitons/Notifications/
>
> In 3rd bullet point of section 4,
> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
> receive a delayed 'attention', though I propose the change from MUST
> to SHOULD.
>

That's nonsense. When user receives your delayed attention request,
you could very well be in work, school, with girlfriend, etc by then.
Attention is a way to get him to talk to you immediately.

> In 5th bullet point, I propose a change to
> "The attention extension MUST NOT use <iq/> stanzas, since use this
> feature is part of the conversation."
>

No objections against that. There's a typo though, "since use *of*
this feature" (it's in the original text, too).

From nicolas.verite at gmail.com  Tue Apr 14 04:40:42 2009
From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=)
Date: Tue, 14 Apr 2009 11:40:42 +0200
Subject: [Standards] XEP-0224 Attention
In-Reply-To: <e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>
References: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>
	<e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>
Message-ID: <6e2f977f0904140240p3d1e3c0fm4fd9edbe6115bdbe@mail.gmail.com>

2009/4/14 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com>:
> 2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
>> In 3rd bullet point of section 4,
>> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
>> receive a delayed 'attention', though I propose the change from MUST
>> to SHOULD.
>
> That's nonsense. When user receives your delayed attention request,
> you could very well be in work, school, with girlfriend, etc by then.
> Attention is a way to get him to talk to you immediately.

Not so nonsense: I wish I had the passed attention requests when I get
back to my client...
It is a worthwhile information, even if it's too late. That way, I
could contact back the guy that tried to get my attention.
-- 
Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com
Jabber ID : xmpp:nyco at jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adh?rez ? l'April : http://april.org/

From kevin at kismith.co.uk  Tue Apr 14 04:43:20 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 14 Apr 2009 10:43:20 +0100
Subject: [Standards] XEP-0224 Attention
In-Reply-To: <6e2f977f0904140240p3d1e3c0fm4fd9edbe6115bdbe@mail.gmail.com>
References: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>
	<e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>
	<6e2f977f0904140240p3d1e3c0fm4fd9edbe6115bdbe@mail.gmail.com>
Message-ID: <f5aae3ec0904140243s3c535917l120df7b566b78115@mail.gmail.com>

On Tue, Apr 14, 2009 at 10:40 AM, Nicolas V?rit?
<nicolas.verite at gmail.com> wrote:
> Not so nonsense: I wish I had the passed attention requests when I get
> back to my client...
> It is a worthwhile information, even if it's too late. That way, I
> could contact back the guy that tried to get my attention.

Damn - if only we had some sort of messaging system we could use for this...

/K

From zarevucky.jiri at gmail.com  Tue Apr 14 04:44:05 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 14 Apr 2009 11:44:05 +0200
Subject: [Standards] XEP-0224 Attention
In-Reply-To: <6e2f977f0904140240p3d1e3c0fm4fd9edbe6115bdbe@mail.gmail.com>
References: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>
	<e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>
	<6e2f977f0904140240p3d1e3c0fm4fd9edbe6115bdbe@mail.gmail.com>
Message-ID: <e962983d0904140244i47bef82ek419e0006247a0881@mail.gmail.com>

2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
> 2009/4/14 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com>:
>> 2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
>>> In 3rd bullet point of section 4,
>>> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
>>> receive a delayed 'attention', though I propose the change from MUST
>>> to SHOULD.
>>
>> That's nonsense. When user receives your delayed attention request,
>> you could very well be in work, school, with girlfriend, etc by then.
>> Attention is a way to get him to talk to you immediately.
>
> Not so nonsense: I wish I had the passed attention requests when I get
> back to my client...
> It is a worthwhile information, even if it's too late. That way, I
> could contact back the guy that tried to get my attention.
>

You won't generally try an "attention" to someone you haven't send
several classic messages already and didn't get response... That would
be considered rude and maybe even spamming.

From stpeter at stpeter.im  Tue Apr 14 08:55:15 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 07:55:15 -0600
Subject: [Standards] XEP-0224 Attention
In-Reply-To: <e962983d0904140244i47bef82ek419e0006247a0881@mail.gmail.com>
References: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>	<e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>	<6e2f977f0904140240p3d1e3c0fm4fd9edbe6115bdbe@mail.gmail.com>
	<e962983d0904140244i47bef82ek419e0006247a0881@mail.gmail.com>
Message-ID: <49E495C3.30109@stpeter.im>

On 4/14/09 3:44 AM, Ji?? Z?rev?ck? wrote:
> 2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
>> 2009/4/14 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com>:
>>> 2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
>>>> In 3rd bullet point of section 4,
>>>> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
>>>> receive a delayed 'attention', though I propose the change from MUST
>>>> to SHOULD.
>>> That's nonsense. When user receives your delayed attention request,
>>> you could very well be in work, school, with girlfriend, etc by then.
>>> Attention is a way to get him to talk to you immediately.
>> Not so nonsense: I wish I had the passed attention requests when I get
>> back to my client...
>> It is a worthwhile information, even if it's too late. That way, I
>> could contact back the guy that tried to get my attention.
>>
> 
> You won't generally try an "attention" to someone you haven't send
> several classic messages already and didn't get response... That would
> be considered rude and maybe even spamming.

Right. Let's not propose technical solutions to social problems.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/c650def0/attachment.bin 

From stpeter at stpeter.im  Tue Apr 14 08:56:25 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 07:56:25 -0600
Subject: [Standards] XEP-0224 Attention
In-Reply-To: <e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>
References: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>
	<e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>
Message-ID: <49E49609.8010208@stpeter.im>

On 4/14/09 3:36 AM, Ji?? Z?rev?ck? wrote:
> 2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
>
>> In 5th bullet point, I propose a change to
>> "The attention extension MUST NOT use <iq/> stanzas, since use this
>> feature is part of the conversation."
>>
> 
> No objections against that. There's a typo though, "since use *of*
> this feature" (it's in the original text, too).

How about this?

"The attention extension MUST NOT be sent in <iq/> stanzas, since use of
this feature is part of a messaging conversation."

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/72d50820/attachment-0001.bin 

From nicolas.verite at gmail.com  Tue Apr 14 09:10:12 2009
From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=)
Date: Tue, 14 Apr 2009 16:10:12 +0200
Subject: [Standards] XEP-0224 Attention
In-Reply-To: <49E49609.8010208@stpeter.im>
References: <6e2f977f0904140227ucf8b72fn5839cca6347fbf37@mail.gmail.com>
	<e962983d0904140236le2af46dg2e6237f605a4ab3a@mail.gmail.com>
	<49E49609.8010208@stpeter.im>
Message-ID: <6e2f977f0904140710h641e50f3kdde684b17ec54559@mail.gmail.com>

On Tue, Apr 14, 2009 at 15:56, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 4/14/09 3:36 AM, Ji?? Z?rev?ck? wrote:
>> 2009/4/14 Nicolas V?rit? <nicolas.verite at gmail.com>:
>>
>>> In 5th bullet point, I propose a change to
>>> "The attention extension MUST NOT use <iq/> stanzas, since use this
>>> feature is part of the conversation."
>>>
>>
>> No objections against that. There's a typo though, "since use *of*
>> this feature" (it's in the original text, too).
>
> How about this?
>
> "The attention extension MUST NOT be sent in <iq/> stanzas, since use of
> this feature is part of a messaging conversation."

Better of course, thanks.
-- 
Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com
Jabber ID : xmpp:nyco at jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adh?rez ? l'April : http://april.org/

From stpeter at stpeter.im  Tue Apr 14 10:26:27 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 09:26:27 -0600
Subject: [Standards] [Fwd: Re:  LAST CALL: XEP-0237 (Roster Versioning)]
Message-ID: <49E4AB23.9000203@stpeter.im>

resend...

-------- Original Message --------
Subject: Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
Date: Tue, 14 Apr 2009 09:15:47 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
To: XMPP Standards <standards at xmpp.org>

On 4/14/09 3:06 AM, Ji?? Z?rev?ck? wrote:

> But I realized there is a rare scenario where it could really cause problem.
> 
> <query ver="300">
>   <item jid="bob at example.org" subscription="none" />
> </query>
> 
> <query ver="301">
>   <item jid="alice at example.org" subscription="none" />
> </query>
> 
> <query ver="302">
>   <item jid="bob at example.org" name="Bob" subscription="none" />
> </query>
> 
> <query ver="303">
>   <item jid="alice at example.org" subscription="to" />
> </query>
> 
> <query ver="304">
>   <item jid="bob at example.org" name="Bob" subscription="from" />
> </query>
> 
> <query ver="305">
>   <item jid="bob at example.org" name="Bob" subscription="none" />
> </query>
> 
> Client knows 300. The roster would send 303 first, and 305 second. If
> connection failed after sending 303, client would next request 303+,
> but never received 302 in the first place.

There seems to be some confusion about how roster versioning works.
Perhaps the spec needs to describe this all in a lot more detail.
However, I'll do that here first.

Let's say you have two clients, 1 and 2. 1 is up to date as of ver='299'
and then goes offline. 2 stays online and completes some roster
management tasks. Then 1 comes back online.

1: <iq type='get'>
     <query xmlns='jabber:iq:roster'>
   </iq>

S: <iq type='result'>
     <query xmlns='jabber:iq:roster' ver='299'>
       <item jid='ji??@?echy.cz'/>
     </query>
   </iq>

1: </presence>

[first roster update from client 2, with Set and Push]

2: <iq type='set'>
     <query>
       <item jid="bob at example.org" subscription="none" />
     </query>
   </iq>

S: <iq type='set'>
     <query ver="300">
       <item jid="bob at example.org" subscription="none" />
     </query>
   </iq>

[second roster update from client 2, with Set and Push]

2: <iq type='set'>
     <query>
       <item jid="alice at example.org" subscription="none" />
     </query>
   </iq>

S: <iq type='set'>
     <query ver="301">
       <item jid="alice at example.org" subscription="none" />
     </query>
   </iq>

[third roster update from client 2, with Set and Push]

2: <iq type='set'>
     <query>
       <item jid="bob at example.org" name="Bob" subscription="none" />
     </query>
   </iq>

S: <iq type='set'>
     <query ver="302">
       <item jid="bob at example.org" name="Bob" subscription="none" />
     </query>
   </iq>

[Alice approves subscription request from user]

S: <iq type='set'>
     <query ver="303">
       <item jid="alice at example.org" subscription="to" />
     </query>
   </iq>

[client 2 approves subscription request from Bob]

S: <iq type='set'>
     <query ver="304">
       <item jid="bob at example.org" name="Bob" subscription="from" />
     </query>
   </iq>

[Bob sends unsubscribe]

S: <iq type='set'>
     <query ver="305">
       <item jid="bob at example.org" name="Bob" subscription="none" />
     </query>
   </iq>

Now the user comes back online with client 1.

1: <iq type='get'>
     <query xmlns='jabber:iq:roster' ver='299'/>
   </iq>

So the server needs to send what's changed to client 1. It does this,
not by sending 300, 301, 302, 303, 304, and 305, but by sending the
effective difference between 299 and 305.

First it tells client 1 that there are changes:

S: <iq type='result'>
     <query xmlns='jabber:iq:roster' ver='305'/>
   </iq>

That means "the latest version is no longer 299 but I'm going to send
you the changes as roster pushes -- when you receive a push numbered 305
then you know you're up to date".

Now the server sends two roster pushes: one related to Alice (303) and
one related to Bob (305):

S: <iq type='set'>
     <query ver="303">
       <item jid="alice at example.org" subscription="to" />
     </query>
   </iq>

S: <iq type='set'>
     <query ver="305">
       <item jid="bob at example.org" name="Bob" subscription="none" />
     </query>
   </iq>

Therefore client 1 knows that it's up to date, and it has received the
most recent information about each roster item that was changed while it
was offline.

You are raising the scenario of the stream dying right after the server
sends 303. I'm saying that client 1 MUST NOT consider itself to be up to
date when it receives 303, because the server has already told it that
the latest version is 305. Therefore, when the client reconnects it MUST
behave as if it never received the roster push for version 303 and
instead send the exact same roster get it sent when it came back online
 (i.e., 299).

> Now (only) in case the server checks the last state client should
> know, it will find out it doesn't need to send the push since there is
> the same state as in 302. Client wouldn't receive bob's name until
> next change.
> 
> That is easily fixed by disallowing servers such checks.

Sure.

Perhaps we need an implementation note for servers, which says:
"basically, you need to keep a record of each roster item that has
changed since the last roster get(s) for this account, but you don't
need to keep a record of each change, only the last state related to
each changed item".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/0e3efb65/attachment.bin 

From stpeter at stpeter.im  Tue Apr 14 11:01:08 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 10:01:08 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49E42628.8060509@goodadvice.pages.de>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<20090224191600.2a938cb5@tiger>	<49A44713.505@goodadvice.pages.de>	<49DFD075.5000703@stpeter.im>
	<49E42628.8060509@goodadvice.pages.de>
Message-ID: <49E4B344.5070101@stpeter.im>

On 4/13/09 11:59 PM, Philipp Hancke wrote:
> Peter Saint-Andre wrote:
> [snip]
>>> Now what happens should I attempt to piggyback the users.jabber.org
>>> connection on the jabber.org connection? jabber.org kills my stream.
>>
>> Really? Why?
> 
> <host-unknown/>.

If jabber.org really does host users.jabber.org, why does it return a
<host-unknown/> error?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/0a7788a5/attachment-0001.bin 

From stpeter at stpeter.im  Tue Apr 14 11:07:41 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 10:07:41 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49E42646.5090805@goodadvice.pages.de>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<49DFD1C0.2020906@stpeter.im>
	<49E42646.5090805@goodadvice.pages.de>
Message-ID: <49E4B4CD.7030903@stpeter.im>

On 4/13/09 11:59 PM, Philipp Hancke wrote:
> Peter Saint-Andre
> [snip]
>>>>> * connection reuse for multiple s2s links would be a very useful
>>>>>   feature, ask Dave for details
>>>> Piggybacking.
>>> Which is subtly broken in RFC 3920 - at least 50% of it.
>>> <host-unknown/> makes 'target piggybacking' (different to)
>>> unusable, as you risk the entire stream.
>>
>> I'm not so sure about that. <host-unknown/> means you're trying to
>> communicate with a domain that I don't host at my server.
> 
> How does the initiator discover that without running into the error?
> DNS does not work even in the same domain.

I don't follow.

>>>> What I'd like to do here is use the dialback elements as an
>>>> authorization request mechanism.
>>> Dialback is 50% authorization request, 50% key verification.
>>> Splitting it up accordingly simplifies the description.
>>
>> As long as it's backwards-compatible.
> 
> It is merely a different way of describing it. The protocol already
> contains this split:
> db:result (authorization part)
> db:verify (key verification).

Sure, if it helps to describe things that way, then let's update the
description. :)

>>>> In fact, by specifying how to do this without actually doing
>>>> dialbacks, but instead by verifying the identity of the sender based
>>>> on the X.509 cert, we can actually get rid of SASL EXTERNAL and just
>>>> use X.509 only, which eliminates the difference between the "first"
>>>> authorization and subsequent ones.
>>> There is no 'subsequent' auth with 0178 yet, is there?
>>
>> There is no subsequent auth anywhere, yet.
> 
> There is piggybacking :-p

Dialback is not an authentication protocol.

> [snip]
>> It's still not clear to me what TLS+dialback really means. If you're
>> going to do TLS, use real certs and then you can do authentication
>> via SASL EXTERNAL.
> 
> SASL EXTERNAL is a non-starter in the public network.

That's an assertion not necessarily backed up by evidence. I am not
convinced that TLS + EXTERNAL is a non-starter on the public XMPP
network, but then again I help to run a CA that issues free domain
certificates for that network (visit http://xmpp.org/ca/ to get yours
today). I think we can say that TLS + EXTERNAL has not been widely
adopted, but that doesn't mean it never will be widely adopted. It all
depends on what threats people perceive. If the costs of getting a
domain cert start to be less than the costs of unsecured federation,
then people will start to use certificates.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/8d3d2e1b/attachment.bin 

From zarevucky.jiri at gmail.com  Tue Apr 14 13:44:41 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 14 Apr 2009 20:44:41 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E4AB23.9000203@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>
Message-ID: <e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>

>
> You are raising the scenario of the stream dying right after the server
> sends 303. I'm saying that client 1 MUST NOT consider itself to be up to
> date when it receives 303, because the server has already told it that
> the latest version is 305. Therefore, when the client reconnects it MUST
> behave as if it never received the roster push for version 303 and
> instead send the exact same roster get it sent when it came back online
> ?(i.e., 299).
>

Client does not consider itself up-to-date but it would retrieve a
complete state if it starts retrieving again from that particular
point. So it could save the interim pushes as they arrive (if we
disregard the last change to the spec, which was based on wrong
assumptions).
That could make a huge difference if the client is on very low
bandwidth, or expensive connection based on transfered data (which for
example GPRS on mobile phones).

From stpeter at stpeter.im  Tue Apr 14 13:53:49 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 12:53:49 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
Message-ID: <49E4DBBD.1030000@stpeter.im>

On 4/14/09 12:44 PM, Ji?? Z?rev?ck? wrote:
>> You are raising the scenario of the stream dying right after the server
>> sends 303. I'm saying that client 1 MUST NOT consider itself to be up to
>> date when it receives 303, because the server has already told it that
>> the latest version is 305. Therefore, when the client reconnects it MUST
>> behave as if it never received the roster push for version 303 and
>> instead send the exact same roster get it sent when it came back online
>>  (i.e., 299).
>>
> 
> Client does not consider itself up-to-date but it would retrieve a
> complete state if it starts retrieving again from that particular
> point. So it could save the interim pushes as they arrive (if we
> disregard the last change to the spec, which was based on wrong
> assumptions).
> That could make a huge difference if the client is on very low
> bandwidth, or expensive connection based on transfered data (which for
> example GPRS on mobile phones).

Aha, I see what you are saying. That's possible. I'll need to think
about it some more...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/bc280427/attachment.bin 

From fippo at goodadvice.pages.de  Tue Apr 14 14:46:15 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Tue, 14 Apr 2009 21:46:15 +0200
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49E4B344.5070101@stpeter.im>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<20090224191600.2a938cb5@tiger>	<49A44713.505@goodadvice.pages.de>	<49DFD075.5000703@stpeter.im>	<49E42628.8060509@goodadvice.pages.de>
	<49E4B344.5070101@stpeter.im>
Message-ID: <49E4E807.2060404@goodadvice.pages.de>

maybe discussing a concrete example makes this more clear...
> On 4/13/09 11:59 PM, Philipp Hancke wrote:
>> Peter Saint-Andre wrote:
>> [snip]
>>>> Now what happens should I attempt to piggyback the users.jabber.org
>>>> connection on the jabber.org connection? jabber.org kills my stream.
>>> Really? Why?
>> <host-unknown/>.
> 
> If jabber.org really does host users.jabber.org, why does it return a
> <host-unknown/> error?

Does the machine hermes.jabber.org really host users.jabber.org?
I think it does not - judging from behaviour. But you are the person
with access to the configuration files :-)

RFC 3920 says that
| the Receiving Server SHOULD accept subsequent <db:result/> packets (
| e.g., validation requests sent to a subdomain or other hostname
| serviced by the Receiving Server)

How does the originating server find out if a subdomain or hostname is
actually serviced by the receiving server?

 From the outside, how do I tell the difference between 
conference.jabber.org
and
users.jabber.org?
Both have SRV records which point to hermes.jabber.org:5269
- the machine that hosts jabber.org

philipp

From stpeter at stpeter.im  Tue Apr 14 16:41:17 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 15:41:17 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49E4E807.2060404@goodadvice.pages.de>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<20090224191600.2a938cb5@tiger>	<49A44713.505@goodadvice.pages.de>	<49DFD075.5000703@stpeter.im>	<49E42628.8060509@goodadvice.pages.de>	<49E4B344.5070101@stpeter.im>
	<49E4E807.2060404@goodadvice.pages.de>
Message-ID: <49E502FD.9020906@stpeter.im>

On 4/14/09 1:46 PM, Philipp Hancke wrote:
> maybe discussing a concrete example makes this more clear...
>> On 4/13/09 11:59 PM, Philipp Hancke wrote:
>>> Peter Saint-Andre wrote:
>>> [snip]
>>>>> Now what happens should I attempt to piggyback the users.jabber.org
>>>>> connection on the jabber.org connection? jabber.org kills my stream.
>>>> Really? Why?
>>> <host-unknown/>.
>>
>> If jabber.org really does host users.jabber.org, why does it return a
>> <host-unknown/> error?
> 
> Does the machine hermes.jabber.org really host users.jabber.org?
> I think it does not - judging from behaviour. But you are the person
> with access to the configuration files :-)

No, that service is offline.

> RFC 3920 says that
> | the Receiving Server SHOULD accept subsequent <db:result/> packets (
> | e.g., validation requests sent to a subdomain or other hostname
> | serviced by the Receiving Server)
> 
> How does the originating server find out if a subdomain or hostname is
> actually serviced by the receiving server?
> 
> From the outside, how do I tell the difference between
> conference.jabber.org
> and
> users.jabber.org?
> Both have SRV records which point to hermes.jabber.org:5269
> - the machine that hosts jabber.org

Don't read too much into a misconfiguration / admin failing on the
jabber.org service.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/69305f9b/attachment-0001.bin 

From stpeter at stpeter.im  Tue Apr 14 17:09:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 16:09:55 -0600
Subject: [Standards] MXM #2
Message-ID: <49E509B3.2090308@stpeter.im>

On March 12 and again today, we held a "Monthly XMPP Meeting":

http://logs.jabber.org/jdev at conference.jabber.org/2009-03-12.html#15:01:15

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:06:45

I know it's a bit backwards, but I'm going to report on today's meeting
first because it's fresh in my mind (and sorry about not yet publishing
minutes from the first meeting). There was no set agenda, but we talked
about the following topics:

1. Last Call for XEP-0232 (Software Information)

http://xmpp.org/extensions/xep-0232.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:10:41

Points:

- Is this a misuse of service discovery?

- Will this make entity capability caches less useful because they will
be too large to search easily?

- Does it make more sense to publish this information via PEP using the
XEP-0092 format?

The XMPP Council will vote on XEP-0232 at its next meeting (April 22).
More feedback is welcome before then.

2. Last Call for XEP-0237 (Roster Versioning)

http://xmpp.org/extensions/xep-0237.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:23:19

General agreement that this is in good shape. There are still a few edge
cases to figure out, especially the empty roster case.

3. Last Calls for the core Jingle specs

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:29:52

No real discussion here. Most people seemed to think that these are
ready for Draft.

4. Pubsub/PEP implementations

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:37:41

Consensus that we need more interop testing among idavoll, ejabberd,
Openfire, Tigase, etc. Perhaps make this a focus at the next XMPP Summit.

5. XEP-0198 (Stream Management)

http://xmpp.org/extensions/xep-0198.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:53:43

People like this. Let's go forth and implement. :)

6. Bidirectional s2s

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#15:00:34

We decided that we need a dedicated discussion session about s2s fixes
and improvements (dialback, multiplexing domains over a given stream via
TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus of
the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/696ff0c2/attachment.bin 

From stpeter at stpeter.im  Tue Apr 14 20:21:39 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 19:21:39 -0600
Subject: [Standards] more candidates for Final?
Message-ID: <49E536A3.7050200@stpeter.im>

Back in August 2007, I posted a list of specs that we might want to push
to Final status:

http://mail.jabber.org/pipermail/standards/2007-August/016477.html

Of those, we have advanced the following:

XEP-0012: Last Activity

XEP-0085: Chat State Notifications

XEP-0174: Serverless Messaging

Looking over the original list with the benefit of further experience, I
think that we might be able to advance some more specs to Final over the
next ~6 months. I have in mind the following:

XEP-0045: Multi-User Chat

XEP-0138: Stream Compression

XEP-0199: XMPP Ping

The only sticking point I see on these is that we need to define methods
for extending XEP-0045, likely using ad-hoc commands. At XMPP Summit #6
in Brussels, Matthew Wild and I said we would work on that, but we have
not yet gotten to it. Perhaps we can do that soon.

(Another possibility is XEP-0124 and XEP-0206, which define BOSH and our
use of it in XMPP.)

I will bring this up at the next Council meeting.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090414/9cd77224/attachment.bin 

From fippo at goodadvice.pages.de  Wed Apr 15 02:29:49 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Wed, 15 Apr 2009 09:29:49 +0200
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49E502FD.9020906@stpeter.im>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<20090224191600.2a938cb5@tiger>	<49A44713.505@goodadvice.pages.de>	<49DFD075.5000703@stpeter.im>	<49E42628.8060509@goodadvice.pages.de>	<49E4B344.5070101@stpeter.im>	<49E4E807.2060404@goodadvice.pages.de>
	<49E502FD.9020906@stpeter.im>
Message-ID: <49E58CED.6010709@goodadvice.pages.de>

Peter Saint-Andre wrote:
>> RFC 3920 says that
>> | the Receiving Server SHOULD accept subsequent <db:result/> packets (
>> | e.g., validation requests sent to a subdomain or other hostname
>> | serviced by the Receiving Server)
>>
>> How does the originating server find out if a subdomain or hostname is
>> actually serviced by the receiving server?
>>
>> From the outside, how do I tell the difference between
>> conference.jabber.org
>> and
>> users.jabber.org?
>> Both have SRV records which point to hermes.jabber.org:5269
>> - the machine that hosts jabber.org
> 
> Don't read too much into a misconfiguration / admin failing on the
> jabber.org service.

That is just a convenient scapegoat^Wexample.
The problem of finding out if a subdomain or hostname is actually
serviced by the receiving server remains.

Inband-probing by just sending a db:result when host/port matches is
efficient and easy to implement. But the risk of getting the stream
killed makes this unusable :-(

type=error as proposed by Matthias originally solves that problem.

philipp

From fippo at goodadvice.pages.de  Wed Apr 15 02:45:02 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Wed, 15 Apr 2009 09:45:02 +0200
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49E4B4CD.7030903@stpeter.im>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>	<49DFD1C0.2020906@stpeter.im>	<49E42646.5090805@goodadvice.pages.de>
	<49E4B4CD.7030903@stpeter.im>
Message-ID: <49E5907E.7060403@goodadvice.pages.de>

Peter Saint-Andre wrote:
[snip]
>> How does the initiator discover that without running into the error?
>> DNS does not work even in the same domain.
> 
> I don't follow.

See the other part of the thread.

>>>>> What I'd like to do here is use the dialback elements as an
>>>>> authorization request mechanism.
>>>> Dialback is 50% authorization request, 50% key verification.
>>>> Splitting it up accordingly simplifies the description.
>>> As long as it's backwards-compatible.
>> It is merely a different way of describing it. The protocol already
>> contains this split:
>> db:result (authorization part)
>> db:verify (key verification).
> 
> Sure, if it helps to describe things that way, then let's update the
> description. :)

Already in your inbox. Unfortunately, I am unable to judge if it really
helps... and getting feedback on s2s topics is quite hard.

>>>>> In fact, by specifying how to do this without actually doing
>>>>> dialbacks, but instead by verifying the identity of the sender based
>>>>> on the X.509 cert, we can actually get rid of SASL EXTERNAL and just
>>>>> use X.509 only, which eliminates the difference between the "first"
>>>>> authorization and subsequent ones.
>>>> There is no 'subsequent' auth with 0178 yet, is there?
>>> There is no subsequent auth anywhere, yet.
>> There is piggybacking :-p
> 
> Dialback is not an authentication protocol.

Shortening "authorization" to "auth" was a bad idea (-:
Let's wait for Dave to write up the dwd xep.

>>> It's still not clear to me what TLS+dialback really means. If you're
>>> going to do TLS, use real certs and then you can do authentication
>>> via SASL EXTERNAL.
>> SASL EXTERNAL is a non-starter in the public network.
> 
> That's an assertion not necessarily backed up by evidence. I am not

http://mail.jabber.org/pipermail/standards/2007-July/016086.html
Those figures have not changed much since 2007.

> convinced that TLS + EXTERNAL is a non-starter on the public XMPP
> network, but then again I help to run a CA that issues free domain
> certificates for that network (visit http://xmpp.org/ca/ to get yours
> today). I think we can say that TLS + EXTERNAL has not been widely
> adopted, but that doesn't mean it never will be widely adopted. It all
> depends on what threats people perceive. If the costs of getting a
> domain cert start to be less than the costs of unsecured federation,
> then people will start to use certificates.

We are talking about different problems. Imo the main problem with
s2s x509 is that servers continue connecting when they get a
mismatch of expected identity (see RFC 3920, 14.2 case #1).

philipp

From dave at cridland.net  Wed Apr 15 04:42:59 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 10:42:59 +0100
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49E4B4CD.7030903@stpeter.im>
References: <20090224013125.2a8f6fed@tiger>
	<2033.1235466853.517526@peirce.dave.cridland.net>
	<49A3C79E.9030009@goodadvice.pages.de> <49DFD1C0.2020906@stpeter.im>
	<49E42646.5090805@goodadvice.pages.de> <49E4B4CD.7030903@stpeter.im>
Message-ID: <7088.1239788579.895926@puncture>

On Tue Apr 14 17:07:41 2009, Peter Saint-Andre wrote:
> Dialback is not an authentication protocol.
> 
> 
I have no idea what else it is.

Dialback might not be a terribly secure authentication mechanism, but  
the intent is to verify an identity assertion, for use as the basis  
for authorization, and if that's not an authentication mechanism I  
have no idea how else to describe it.

FWIW, I'm not sure there's any such thing as an authorization  
protocol, since the act of authorization is almost by definition an  
internal matter. (Although policy query services would probably  
count).


> > [snip]
> >> It's still not clear to me what TLS+dialback really means. If  
> you're
> >> going to do TLS, use real certs and then you can do  
> authentication
> >> via SASL EXTERNAL.
> >
> > SASL EXTERNAL is a non-starter in the public network.
> 
> That's an assertion not necessarily backed up by evidence. I am not
> convinced that TLS + EXTERNAL is a non-starter on the public XMPP
> network, but then again I help to run a CA that issues free domain
> certificates for that network (visit http://xmpp.org/ca/ to get  
> yours
> today). I think we can say that TLS + EXTERNAL has not been widely
> adopted, but that doesn't mean it never will be widely adopted. It  
> all
> depends on what threats people perceive. If the costs of getting a
> domain cert start to be less than the costs of unsecured federation,
> then people will start to use certificates.

I'd readily agree here, with the caveat that it's the X.509 that's  
seeing quite successful deployment by the usual standards. In fact,  
if you compare the XMPP network to the HTTP one, and consider the  
proportion of XMPP servers deploying routine TLS with a CA-signed  
certificate, to the proportion of HTTP servers even offering any TLS  
at all, I think XMPP is looking remarkably good.

But Philip's right that we could never mandate CA-signed  
certificates, we can merely recommend strongly that servers obtain  
one - to mandate them and pretend that dialback does not exist would  
be burying our heads in the sand to an extraordinary degree.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Wed Apr 15 04:43:03 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 10:43:03 +0100
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <49DFD53D.5090008@stpeter.im>
References: <20090224013125.2a8f6fed@tiger>
	<2033.1235466853.517526@peirce.dave.cridland.net>
	<49DFD53D.5090008@stpeter.im>
Message-ID: <7088.1239788583.222856@puncture>

On Sat Apr 11 00:24:45 2009, Peter Saint-Andre wrote:
> > In fact, by specifying how to do this without actually doing  
> dialbacks,
> > but instead by verifying the identity of the sender based on the  
> X.509
> > cert, we can actually get rid of SASL EXTERNAL and just use X.509  
> only,
> > which eliminates the difference between the "first" authorization  
> and
> > subsequent ones.
> 
> I'm not convinced of that. Why get rid of SASL EXTERNAL? (It seems
> preferable to use TLS+SASL for both c2s and s2s.)

But we're not - SASL EXTERNAL is, essentially, a way to say "I don't  
want to use SASL". Given that, and given that our protocol  
architecture doesn't require a SASL step at all, we may as well drop  
that pretense. (Unless we really want to use anything else but  
EXTERNAL on S2S links).

>  And what does it mean
> to "just use X.509"?
> 
> 
Aside from SASL, I mean - so the basis of a server's identity becomes  
the X.509 certificate, which we're using already.


> > The dialback flow then becomes:
> >
> > 1) O2R : <db:result/>
> > 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT
> > 3) R: Connect to A
> > 4) R2A: Establish TLS.
> > 5) R2A: If A's certificate matches O's, goto ACCEPT
> > 6) R2A: <db:verify/>
> > 7) A2R: <db:verify/>, goto ACCEPT
> > ACCEPT:
> > 8) R2O: Authorize O as requested domain, send <db:result/>
> 
> Perhaps. :)
> 
> 
Philipp's suggestion of splitting the matter of authentication  
request and verification in XEP-0220 makes this clearer, since there  
are then multiple ways of verifying, but only one way of requesting  
authentication.

> >> * resource conflicts should be handled consistently in servers
> >>
> >>
> > It's not always possible to handle conflicts in the same way.
> 
> What do we mean by "handled consistently"?
> 
> 
I would assume statements such as "The new connection wins, and the  
old one is disconnected", or some such. That's not always possible -  
consider the case of a split cluster, where one node knows that a  
conflict exists, but cannot signal that to the other node. In this  
case, the best option is to allocate a new resource, yet wherever  
possible one should test and kill the "old" session and replace it.

> >> * xml:lang per stanza seems to be pretty rare, I would prefer  
> MAY to
> >>   SHOULD, or even to discurage per-stanza xml:lang entirerely and
> >>   encourage use of xml:lang only for elements with localized  
> strings.
> >>   Many users (and also client developers) just don't care about
> >>   languages. Unqualified strings are (and will be) very common,  
> I would
> >>   use MAY even for the elements.
> >>
> >>
> > In principle, the stanza-level xml:lang can be used especially  
> over S2S
> > sessions to indicate a preferred language for errors.
> >
> > However... various protocols have had features like this for  
> years, and
> > to the best of my knowledge nobody ever uses them.
> 
> So it seems. So perhaps Pavel's proposal is appropriate.
> 
> 
Well, if you're going to markup anguages, then unless we mandte what  
that language must be, we'll have a mixture over S2S channels, in  
which case you have to markup per-stanza.


> >> * "gone" has a very good usecase that could be made explicit...  
> it is
> >>   JID redirection and could be handled by clients (e.g. the  
> client could
> >>   offer the user to add the new JID upon error - presence/message
> >>   would trigger it).
> >>
> >>
> > Right - a jid redirection would be useful. We'd also need to put
> > together a companion protocol for users to enable it.
> 
> http://xmpp.org/extensions/inbox/forwarding-delivery.html
> 
> http://xmpp.org/extensions/inbox/forwarding-request.html
> 
> 
I'll read up.


> >> * Consider including XEP-198 Stream Management in the RFC
> >
> > We need to actually prove it, first. I don't think anyone's got  
> as far
> > as coding it, yet.
> 
> Now we have Prosody on the server side and Lampiro on the client  
> side.
> Time for some testing. :)

For XEP-0198? I thought they'd only done XEP-0237?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Wed Apr 15 04:54:49 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 10:54:49 +0100
Subject: [Standards] MXM #2
In-Reply-To: <49E509B3.2090308@stpeter.im>
References: <49E509B3.2090308@stpeter.im>
Message-ID: <7088.1239789289.390264@puncture>

On Tue Apr 14 23:09:55 2009, Peter Saint-Andre wrote:
> The XMPP Council will vote on XEP-0232 at its next meeting (April  
> 22).
> More feedback is welcome before then.
> 
> 
As usual, you're welcome to turn up to the Council meetings, and  
express your views there. (But for the next meeting, you'll need to  
bring cake.)

> We decided that we need a dedicated discussion session about s2s  
> fixes
> and improvements (dialback, multiplexing domains over a given  
> stream via
> TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus  
> of
> the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Matthew Wild and I have agreed to write "something" up in terms of a  
strawman proposal we can batter about.

Feel free to write one too - I'll endeavour to send something to the  
list before then.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From fabio.forno at gmail.com  Wed Apr 15 07:44:56 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Wed, 15 Apr 2009 14:44:56 +0200
Subject: [Standards] crazy idea of the day: Oauth'ed sessions
Message-ID: <2fd53c3a0904150544y57c088c2i6b7bd9bc767fc8d4@mail.gmail.com>

Hi,

while I was testing speeqe, the nice BOSH based MUC client of StanzIQ,
I've noticed one limitation we have with XMPP which is only partially
addressed with XEP-0235, OAuth Over XMPP. XEP-0235 allows to use XMPP
resources with an auth token obtained via OAuth. All the use cases in
the XEP are based on the assumption that an XMPP entity needs to do
some operations on resources on which it has no rights, and therefore
it needs a special authorization. That is the purpose of OAuth,
however there is  one more case which isn't addressed: allow somebody
else to behave as if it were me only for a limited scope.
Examples are web based chats I don't completely trust: instead of
giving them my password I just pass them an OAuth token which allows
at most n logins or just exchanging messaging with a given
conferencing server. The basic mechanism would be a simple token-based
authentication, after which is created a session with the limitations
set during the token generation.

Right now I'm just asking because it's something that needs big
changes in server session management and it will take a long time
before seeing it implemented. So it's better to know in advance if
there is interest or better way to do the same things. Possible
applications:
- in general login with untrusted clients or hw (the authentication
token can be also generated with an external device such as a
smartcard)
- web based sessions, with bosh clients embedded in third parties
sites (e.g. I'm on facebook and I don't want to use their ugly chat,
but my real JID and I don't want to give away my password)

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From stpeter at stpeter.im  Wed Apr 15 08:34:10 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 15 Apr 2009 07:34:10 -0600
Subject: [Standards] MXM #2
In-Reply-To: <7088.1239789289.390264@puncture>
References: <49E509B3.2090308@stpeter.im> <7088.1239789289.390264@puncture>
Message-ID: <49E5E252.206@stpeter.im>

On 4/15/09 3:54 AM, Dave Cridland wrote:
> On Tue Apr 14 23:09:55 2009, Peter Saint-Andre wrote:
> 
>> We decided that we need a dedicated discussion session about s2s fixes
>> and improvements (dialback, multiplexing domains over a given stream via
>> TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus of
>> the next Monthly XMPP Meeting, tentatively scheduled for May 5.
> 
> Matthew Wild and I have agreed to write "something" up in terms of a
> strawman proposal we can batter about.
> 
> Feel free to write one too - I'll endeavour to send something to the
> list before then.

Joe Hildebrand and I have been thinking mostly the multiplexing use
cases, especially for the sake of services hosting lots of virtual
domains (think Google Apps) that would like to do so securely. It's high
on my list to write a strawman about that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090415/32e05f1d/attachment.bin 

From dawid.nowak at nortel.com  Wed Apr 15 12:25:40 2009
From: dawid.nowak at nortel.com (Dawid Nowak)
Date: Wed, 15 Apr 2009 18:25:40 +0100
Subject: [Standards] Comments on xep-025 standard
Message-ID: <CF268C57160BE84289D36FF46801A2C805FFF3AD@zharhxm0.corp.nortel.com>

Hi,
I am no expert in XMPP but have been looking at this standard from a
call centre operator perspective and have following comments :

1. Caller always knows the address of Callee as it gets it from
Attendant in the transfer message. I suppose Callee and Attendant know
about each other but I am not sure if the same could be said about
Caller. It is possible to envisage the scenario where Caller is ringing
a well known public number, is asked some questions by the IVR and
transferred to a specific consultant based on hers/his answers.
In the current proposal Attendant seems to pass Callee's address to
Caller without Callee's knowledge or permission. This address could
later be used to call Caller directly.

2. I think current proposal gives Caller too much control over the
transfer and it should be Attendant who controls the transfer scenario.

3. Currently Callee can not indicate to Attendant that it can not accept
transfer.


I have modified the existing diagram to reflect these points. 

Unattended transfer

Caller                 Attendant(IVR,etc)         Callee
  |                        |                        |
  |   session-initiate     |                        |
  |----------------------->|                        |
  |   ack                  |                        |
  |<-----------------------|                        |
  |   session-accept       |                        |
  |<-----------------------|                        |
  |   ack                  |                        |
  |----------------------->|                        |
  |    AUDIO (RTP)         |                        | 
  |<======================>|                        |
  |                        |                        |
  |                 transfer-indication             |
  |				   |----------------------->|
  |                        |          ack           |
  |     transfer           |<-----------------------|
  |<-----------------------|                        |
  |       ack              |                        |
  |----------------------->|                        |
  |                 session-initiate                |
  |------------------------------------------------>|
  |                 session-accept                  |
  |<------------------------------------------------|
  |                       ack                       |
  |------------------------------------------------>|
  |                    AUDIO (RTP)                  |
  |<===============================================>|

  
Where transfer-indication is:

<iq from='attendant at office.biz/desk'
	id='transfer-indication1'
    	to='boss at bigdesk.biz/phone'
    	type='set'>
	<jingle xmlns='urn:xmpp:jingle:0'
         	action='session-info'
         	initiator='caller at world.sun/phone'
         	responder='attendant at office.biz/desk'
         	sid='851ba2'>
	<transfer-indication xmlns='urn:xmpp:jingle:transfer:0'
      	from='caller at world.sun/phone'
transfer-placeholder='transfer at office.biz/transfer1'
transfer-id='unique-transfer-id'/>
 	</jingle>
</iq>


Attendant sends Transfer back to Client. This message could also
indicate that existing call between Caller and Attendant should be
terminated.

<iq from='attendant at office.biz/desk'
    	id='transfer1'
    	to='caller at world.sun/phone'
    	type='set'>
 	<jingle xmlns='urn:xmpp:jingle:0'
         	action='session-info'
         	initiator='caller at world.sun/phone'
         	responder='attendant at office.biz/desk'
         	sid='851ba2'>
   	<transfer xmlns='urn:xmpp:jingle:transfer:0'
      	to='transfer at office.biz/transfer1'
		transfer-id='unique-transfer-id'/>

	 </jingle>
</iq>


And Client initiates a new session to a placeholder address which the
switch translates into a valid address.

<iq from='attendant at office.biz/desk'
    	id='jingle3'
    	to='transfer at office.biz/transfer1'
    	type='set'>
    	<jingle xmlns='urn:xmpp:jingle:0'
         	action='session-initiate'
         	initiator='caller at world.sun/phone'
         	sid='1a332d'>
   		<content creator='initiator'
            	disposition='session'
            	name='voice'>
	     		<description xmlns='urn:xmpp:jingle:apps:rtp:0'
                  media='audio'>
			<payload-type id='0' name='PCMU' />
     			</description>
     			<transport
xmlns='urn:xmpp:jingle:transports:ice-udp:0'/>
		</content>
		<transfer xmlns='urn:xmpp:jingle:transfer:0'
transfer-id='unique-transfer-id'/>   
	</jingle>
</iq>

Regards
Dawid Nowak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090415/f0b277ba/attachment.htm 

From arcriley at gmail.com  Wed Apr 15 16:22:44 2009
From: arcriley at gmail.com (Arc Riley)
Date: Wed, 15 Apr 2009 17:22:44 -0400
Subject: [Standards] Proposed XMPP Extension: Multi-User Gaming
In-Reply-To: <E1LsN5Z-0004AK-00@apollo>
References: <E1LsN5Z-0004AK-00@apollo>
Message-ID: <bad82a80904151422r6772d0c7sb2a7c3cb698e3944@mail.gmail.com>

I'd like to repeat my earlier request for the title of this XEP to specify
"in-band" gaming

thanks

On Fri, Apr 10, 2009 at 4:12 PM, XMPP Extensions Editor <editor at xmpp.org>wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Multi-User Gaming
>
> Abstract: This document defines an XMPP protocol extension for multi-user
> gaming.
>
> URL: http://www.xmpp.org/extensions/inbox/multi-user_gaming.html
>
> The XMPP Council will decide at its next meeting whether to accept this
> proposal as an official XEP.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090415/528f2844/attachment.htm 

From dave at cridland.net  Wed Apr 15 17:05:39 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 23:05:39 +0100
Subject: [Standards] Proposed XMPP Extension: Multi-User Gaming
In-Reply-To: <bad82a80904151422r6772d0c7sb2a7c3cb698e3944@mail.gmail.com>
References: <E1LsN5Z-0004AK-00@apollo>
	<bad82a80904151422r6772d0c7sb2a7c3cb698e3944@mail.gmail.com>
Message-ID: <5975.1239833139.632280@puncture>

On Wed Apr 15 22:22:44 2009, Arc Riley wrote:
> I'd like to repeat my earlier request for the title of this XEP to  
> specify
> "in-band" gaming
> 
> 
I hate the expression "in-band", actually, but "Multiplayer games  
over XMPP" would be a more useful title - I was expecting an  
XFire-style thing from the title.

Dave
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Wed Apr 15 17:28:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 15 Apr 2009 16:28:22 -0600
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <7088.1239788579.895926@puncture>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>
	<49DFD1C0.2020906@stpeter.im>	<49E42646.5090805@goodadvice.pages.de>
	<49E4B4CD.7030903@stpeter.im> <7088.1239788579.895926@puncture>
Message-ID: <49E65F86.1020907@stpeter.im>

On 4/15/09 3:42 AM, Dave Cridland wrote:
> On Tue Apr 14 17:07:41 2009, Peter Saint-Andre wrote:
>> Dialback is not an authentication protocol.
>>
>>
> I have no idea what else it is.

The IETF said we needed to call it "weak identity verification". :P

> Dialback might not be a terribly secure authentication mechanism, but
> the intent is to verify an identity assertion, for use as the basis for
> authorization, and if that's not an authentication mechanism I have no
> idea how else to describe it.
> 
> FWIW, I'm not sure there's any such thing as an authorization protocol,
> since the act of authorization is almost by definition an internal
> matter. (Although policy query services would probably count).
> 
> 
>> > [snip]
>> >> It's still not clear to me what TLS+dialback really means. If you're
>> >> going to do TLS, use real certs and then you can do authentication
>> >> via SASL EXTERNAL.
>> >
>> > SASL EXTERNAL is a non-starter in the public network.
>>
>> That's an assertion not necessarily backed up by evidence. I am not
>> convinced that TLS + EXTERNAL is a non-starter on the public XMPP
>> network, but then again I help to run a CA that issues free domain
>> certificates for that network (visit http://xmpp.org/ca/ to get yours
>> today). I think we can say that TLS + EXTERNAL has not been widely
>> adopted, but that doesn't mean it never will be widely adopted. It all
>> depends on what threats people perceive. If the costs of getting a
>> domain cert start to be less than the costs of unsecured federation,
>> then people will start to use certificates.
> 
> I'd readily agree here, with the caveat that it's the X.509 that's
> seeing quite successful deployment by the usual standards. In fact, if
> you compare the XMPP network to the HTTP one, and consider the
> proportion of XMPP servers deploying routine TLS with a CA-signed
> certificate, to the proportion of HTTP servers even offering any TLS at
> all, I think XMPP is looking remarkably good.
> 
> But Philip's right that we could never mandate CA-signed certificates,
> we can merely recommend strongly that servers obtain one - to mandate
> them and pretend that dialback does not exist would be burying our heads
> in the sand to an extraordinary degree.

Naturally, we can't mandate any deployment decisions of this kind. But
if all the major nodes on the network start to require TLS for s2s,
adoption would increase significantly. Unfortunately we're not yet close
to doing that yet because of the rule about one stream per domain (in
fact two until s2s streams can be bidirectional), which pretty much
makes it impossible for services like Google Apps to do TLS s2s. That's
why I am so interested in solving the multiplexing problem.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090415/308d885a/attachment-0001.bin 

From stpeter at stpeter.im  Wed Apr 15 18:06:17 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 15 Apr 2009 17:06:17 -0600
Subject: [Standards] Comments on xep-025 standard
In-Reply-To: <CF268C57160BE84289D36FF46801A2C805FFF3AD@zharhxm0.corp.nortel.com>
References: <CF268C57160BE84289D36FF46801A2C805FFF3AD@zharhxm0.corp.nortel.com>
Message-ID: <49E66869.3010404@stpeter.im>

On 4/15/09 11:25 AM, Dawid Nowak wrote:
> Hi,
> I am no expert in XMPP but have been looking at this standard 

FYI, we never call something a standard. It's just a specification.

Also, I think you mean XEP-0251: Jingle Session Transfer, no?

http://xmpp.org/extensions/xep-0251.html

> from a
> call centre operator perspective and have following comments :

Your comments are appreciated. I've poked the primary authors of this
specification to get their feedback (my role was mostly editorial).

We'll probably receive more focused feedback on the Jingle list so I
have forwarded it there, too:

http://mail.jabber.org/mailman/listinfo/jingle

More soon.

Peter

--
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090415/c8d9d72a/attachment.bin 

From arcriley at gmail.com  Wed Apr 15 22:06:14 2009
From: arcriley at gmail.com (Arc Riley)
Date: Wed, 15 Apr 2009 23:06:14 -0400
Subject: [Standards] Proposed XMPP Extension: Multi-User Gaming
In-Reply-To: <5975.1239833139.632280@puncture>
References: <E1LsN5Z-0004AK-00@apollo>
	<bad82a80904151422r6772d0c7sb2a7c3cb698e3944@mail.gmail.com>
	<5975.1239833139.632280@puncture>
Message-ID: <bad82a80904152006t576113fdt543c0be56cc04dc0@mail.gmail.com>

I find "over XMPP" just as misleading in scope.

We're doing out-of-band gaming over XMPP via Jingle ICE-UDP in our game
engine with XMPP handling server info announcements, ICE negotiation,
inter-game shared buddy lists and messaging.

If we publish an XEP it should be clear by their titles what each is
designed for.  There are already a few gaming XEPs (and proto-XEPs) with
extremely niche use cases actually, it'd be nice to work on these (ie,
xep-0196) so they're more general purpose and suitable for standardization.


On Wed, Apr 15, 2009 at 6:05 PM, Dave Cridland <dave at cridland.net> wrote:

> On Wed Apr 15 22:22:44 2009, Arc Riley wrote:
>
>> I'd like to repeat my earlier request for the title of this XEP to specify
>> "in-band" gaming
>>
>>
>>  I hate the expression "in-band", actually, but "Multiplayer games over
> XMPP" would be a more useful title - I was expecting an XFire-style thing
> from the title.
>
> Dave
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090415/01244de1/attachment.htm 

From fippo at goodadvice.pages.de  Thu Apr 16 02:46:44 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Thu, 16 Apr 2009 09:46:44 +0200
Subject: [Standards] various rfc3920bis feedback
In-Reply-To: <7088.1239788579.895926@puncture>
References: <20090224013125.2a8f6fed@tiger>	<2033.1235466853.517526@peirce.dave.cridland.net>	<49A3C79E.9030009@goodadvice.pages.de>
	<49DFD1C0.2020906@stpeter.im>	<49E42646.5090805@goodadvice.pages.de>
	<49E4B4CD.7030903@stpeter.im> <7088.1239788579.895926@puncture>
Message-ID: <49E6E264.3010606@goodadvice.pages.de>

Dave Cridland schrieb:
>> That's an assertion not necessarily backed up by evidence. I am not
>> convinced that TLS + EXTERNAL is a non-starter on the public XMPP
>> network, but then again I help to run a CA that issues free domain
>> certificates for that network (visit http://xmpp.org/ca/ to get yours
>> today). I think we can say that TLS + EXTERNAL has not been widely
>> adopted, but that doesn't mean it never will be widely adopted. It all
>> depends on what threats people perceive. If the costs of getting a
>> domain cert start to be less than the costs of unsecured federation,
>> then people will start to use certificates.
> 
> I'd readily agree here, with the caveat that it's the X.509 that's 
> seeing quite successful deployment by the usual standards. In fact, if 

TLS is seeing quite successful deployment, yes. But not x.509.

> you compare the XMPP network to the HTTP one, and consider the 
> proportion of XMPP servers deploying routine TLS with a CA-signed 
> certificate, to the proportion of HTTP servers even offering any TLS at 
> all, I think XMPP is looking remarkably good.

comparing HTTP behaviour with XMPP behaviour with regard to expected
identity (if I connect to jabber.org, I expect the certificate to
say 'jabber.org' somewhere):
If a browser gets a mismatch of expected identity it shows a warning.
If a xmpp client gets a mismatch of expected identity, it will show a 
warning, too.
If a xmpp server gets a mismatch of expected identity, it continues to
connect. Which is not even what RFC 3920 recommends.

philipp

From nicolas.verite at gmail.com  Thu Apr 16 09:03:39 2009
From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=)
Date: Thu, 16 Apr 2009 16:03:39 +0200
Subject: [Standards] Small typos in ad-hoc commands (XEP-0050)
Message-ID: <6e2f977f0904160703h695c9f24wdde23775479cb330@mail.gmail.com>

Hi,

There are small typos in XEP-0050: Ad-Hoc Commands:
http://xmpp.org/extensions/xep-0050.html

:%s/X-Windows/X-Window/g

http://en.wikipedia.org/wiki/X_Window_System

;-)
-- 
Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com
Jabber ID : xmpp:nyco at jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adh?rez ? l'April : http://april.org/

From stpeter at stpeter.im  Thu Apr 16 10:08:32 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 16 Apr 2009 09:08:32 -0600
Subject: [Standards] Small typos in ad-hoc commands (XEP-0050)
In-Reply-To: <6e2f977f0904160703h695c9f24wdde23775479cb330@mail.gmail.com>
References: <6e2f977f0904160703h695c9f24wdde23775479cb330@mail.gmail.com>
Message-ID: <49E749F0.2050008@stpeter.im>

On 4/16/09 8:03 AM, Nicolas V?rit? wrote:
> Hi,
> 
> There are small typos in XEP-0050: Ad-Hoc Commands:
> http://xmpp.org/extensions/xep-0050.html
> 
> :%s/X-Windows/X-Window/g
> 
> http://en.wikipedia.org/wiki/X_Window_System
> 
> ;-)

Fixed, thanks. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090416/de9f9814/attachment-0001.bin 

From stpeter at stpeter.im  Thu Apr 16 15:09:10 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 16 Apr 2009 14:09:10 -0600
Subject: [Standards] Meta-data in Pubsub XEP-0060
In-Reply-To: <494B95AC.5060506@yahoo.com>
References: <494B95AC.5060506@yahoo.com>
Message-ID: <49E79066.7010208@stpeter.im>

On 12/19/08 5:38 AM, Brett Zamir wrote:
> Might the meta-data query result (section 5.4 in XEP-0060) recommend the
> @type attribute on the <x>'s <field/> children so that a client could,
> for example, know to display a boolean type as the more readable "true"
> and "false" as opposed to the potential values of 1 and 0?

The metadata has FORM_TYPE of
http://jabber.org/protocol/pubsub#meta-data and the data types can be
determined from that. But it doesn't hurt to include the types. I'll add
a note about that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090416/60a46969/attachment.bin 

From stpeter at stpeter.im  Thu Apr 16 16:48:04 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 16 Apr 2009 15:48:04 -0600
Subject: [Standards] Pubsub extension idea
In-Reply-To: <49546D27.3060603@yahoo.com>
References: <49546D27.3060603@yahoo.com>
Message-ID: <49E7A794.1060500@stpeter.im>

On 12/25/08 10:35 PM, Brett Zamir wrote:
> Hi,
> 
> Along the lines of how Data Forms types and Data Forms Validation can
> influence display of forms, I'd like to see some standard way in which
> Pubsub payloads could be similarly extensible, not only by allowing
> different namespaces (as is now allowable within Atom extension elements
> or for a wholly different root namespace), but by some extensible
> standardization which could give more hints than either of these at
> input and display type. Data Forms & Data Forms validation might
> themselves be used as a payload, but I can see a need for more types
> targeting display of different types of GUI elements. For example, it
> would be nice to know whether an uploaded file (which could use
> sipub:file-transfer as the datatype) should be suggested as an image, an
> iframe, a link for download, etc.. This would allow:
> 
> 1) As with DF, a uniform way to know how to display payloads
> 2) Allow semantic extensibility while also being able to suggest a
> display mode when the semantic namespace is not recognized.
> 
> However, even with DF + DFV, there would need to be some way to indicate
> that DFV was also supported (if these are kept as separate specs), since
> Pubsub only allows for specification of one payload namespace--this
> might, I imagine, be done by requiring that both namespaces be supported
> if used as a Pubsub payload or, even better, by adding an option to
> Pubsub to indicate additional sub-namespace(s) that are
> required/supported).
> 
> While Atom is extensible, there is no way to make a meta-data query to
> know what inner namespaces are supported (or to specify which ones
> during Node configuration), so DF+DFV (or any other option) is not so
> suitable as an Atom extension. DF + DFV could be used as the root, even
> indicating Atom namespaces+type within <field var>, but again, there
> would be no way to detect ahead of time which semantic namespaces (such
> as Atom) were being used within DF+DFV without first accepting the payload.
> 
> Thus I'd like to suggest
> 1) a list-multi option be added to Pubsub to allow additional supported
> sub-namespaces to be indicated (whatever the top-level namespace).

Doesn't that break the rule of one namespace per node?

> 2) Data Forms and DFV be extended to offer greater specificity in types
> suggesting various input and display elements. (Maybe some existing GUI
> kit could be used as the basis for such a namespace.)
> 
> Also, I think it might be nice to have an option to be able to indicate
> whether the namespaces (or subnamespaces) were required for proper
> viewing, or just supplementary.

I don't see a strong use case for this yet.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090416/d62cb8f5/attachment.bin 

From stpeter at stpeter.im  Thu Apr 16 21:09:05 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 16 Apr 2009 20:09:05 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
Message-ID: <49E7E4C1.8000908@stpeter.im>

On 4/14/09 12:44 PM, Ji?? Z?rev?ck? wrote:
>> You are raising the scenario of the stream dying right after the server
>> sends 303. I'm saying that client 1 MUST NOT consider itself to be up to
>> date when it receives 303, because the server has already told it that
>> the latest version is 305. Therefore, when the client reconnects it MUST
>> behave as if it never received the roster push for version 303 and
>> instead send the exact same roster get it sent when it came back online
>>  (i.e., 299).
>>
> 
> Client does not consider itself up-to-date but it would retrieve a
> complete state if it starts retrieving again from that particular
> point. So it could save the interim pushes as they arrive (if we
> disregard the last change to the spec, which was based on wrong
> assumptions).

You mean this?

"The client MUST NOT process any of the interim roster pushes until it
has processed all of them (this helps to prevent partial processing if
the client loses its connection to the server before it has received all
of the interim roster pushes)."

> That could make a huge difference if the client is on very low
> bandwidth, or expensive connection based on transfered data (which for
> example GPRS on mobile phones).

I'm not convinced of this. How often do people have a lot of new
contacts in their roster? I have 2200 contacts, but even I don't always
have a roster change waiting for me when I log in. Usually I have one or
two subscription requests to process, but not a roster push. What is the
likelihood that I will lose connectivity after the first roster push?
And can't I just request the the same state I started with? I think
you're making it too complicated for the typical usage.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090416/d7d20637/attachment-0001.bin 

From zarevucky.jiri at gmail.com  Thu Apr 16 21:39:26 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 04:39:26 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E7E4C1.8000908@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
Message-ID: <e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> I think you're making it too complicated for the typical usage.
>
> Peter
>

Yeah. You are probably right. These are just nuances that would affect
very little people throughout the whole existence of the protocol, but
given they don't make anything more complex or introduce any
inconveniences for anyone, I think they are worth doing. For all we
know, someone's aggravation over few second longer delay when loading
roster can ultimately lead to World War III... :-D

From stpeter at stpeter.im  Thu Apr 16 21:59:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 16 Apr 2009 20:59:31 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
Message-ID: <49E7F093.1060400@stpeter.im>

Ahoj Jirka,

On 4/16/09 8:39 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> I think you're making it too complicated for the typical usage.
>>
>> Peter
>>
> 
> Yeah. You are probably right. These are just nuances that would affect
> very little people throughout the whole existence of the protocol, but
> given they don't make anything more complex or introduce any
> inconveniences for anyone, I think they are worth doing. For all we
> know, someone's aggravation over few second longer delay when loading
> roster can ultimately lead to World War III... :-D

I think that the things you are describing fall into the category of
optimizations that a smart client can implement to improve the user
experience. But we don't need to describe all that in the spec ("in the
unlikely event that you get disconnected after receiving some but not
all of the roster pushes, cache what you've received so far but then
when you reconnect you can shave a few seconds off the reconnection
process by requesting the roster based on the version of the last roster
push you cached, not the last full roster update"). That kind of thing
is great but IMHO it doesn't really belong in an RFC.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20090416/a7ea0185/attachment.bin 

From zarevucky.jiri at gmail.com  Thu Apr 16 22:23:15 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 05:23:15 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E7F093.1060400@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
Message-ID: <e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> Ahoj Jirka,
>
> On 4/16/09 8:39 PM, Ji?? Z?rev?ck? wrote:
>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>> I think you're making it too complicated for the typical usage.
>>>
>>> Peter
>>>
>>
>> Yeah. You are probably right. These are just nuances that would affect
>> very little people throughout the whole existence of the protocol, but
>> given they don't make anything more complex or introduce any
>> inconveniences for anyone, I think they are worth doing. For all we
>> know, someone's aggravation over few second longer delay when loading
>> roster can ultimately lead to World War III... :-D
>
> I think that the things you are describing fall into the category of
> optimizations that a smart client can implement to improve the user
> experience. But we don't need to describe all that in the spec ("in the
> unlikely event that you get disconnected after receiving some but not
> all of the roster pushes, cache what you've received so far but then
> when you reconnect you can shave a few seconds off the reconnection
> process by requesting the roster based on the version of the last roster
> push you cached, not the last full roster update"). That kind of thing
> is great but IMHO it doesn't really belong in an RFC.
>

Actually, I described an error scenario that could occur (but probably
never would, and even if it did, nobody would likely notice) when both
client and server utilize a specific optimization. :)  which is
probably making half of this thread a truly regrettable waste of your
time... sorry about that... :)

From niess at uni-potsdam.de  Fri Apr 17 01:03:10 2009
From: niess at uni-potsdam.de (niess at uni-potsdam.de)
Date: Fri, 17 Apr 2009 08:03:10 +0200
Subject: [Standards] Proposed XMPP Extension: Multi-User Gaming
In-Reply-To: <bad82a80904152006t576113fdt543c0be56cc04dc0@mail.gmail.com>
References: <E1LsN5Z-0004AK-00@apollo>
	<bad82a80904151422r6772d0c7sb2a7c3cb698e3944@mail.gmail.com>
	<5975.1239833139.632280@puncture>
	<bad82a80904152006t576113fdt543c0be56cc04dc0@mail.gmail.com>
Message-ID: <20090417060310.GA5493@aiken.home.pappanoa.de>

On Wed, Apr 15, 2009 at 11:06:14PM -0400, Arc Riley wrote:
> On Wed, Apr 15, 2009 at 6:05 PM, Dave Cridland <dave at cridland.net>
> wrote:
> >> I'd like to repeat my earlier request for the title of this XEP to
> >> specify "in-band" gaming
> >
> > I hate the expression "in-band", actually, but "Multiplayer games
> > over XMPP" would be a more useful title - I was expecting an 
> > XFire-style thing from the title.
> >
> I find "over XMPP" just as misleading in scope.
>
> We're doing out-of-band gaming over XMPP via Jingle ICE-UDP in our
> game engine with XMPP handling server info announcements, ICE 
> negotiation, inter-game shared buddy lists and messaging.
>
> If we publish an XEP it should be clear by their titles what each is
> designed for.

Agreed. We started this protocol based on Game Sessions [1]. But we soon
realized that our proposal gets far away from it, so we looked for
another title.
The goal of this proposal is to support any game which is suitable for
XMPP. That means we want to use the strengths of XMPP [2] and not limit
the use of XMPP by out-of-band data. So we had in mind that we don't
want to limit that proposal to a special kind of games only for that
games which aren't suitable for XMPP.
But if several people don't expect that under the title "Multi-User
Gaming" then we should look for a more appropriate title.

> There are already a few gaming XEPs (and proto-XEPs) with extremely
> niche use cases actually, it'd be nice to work on these (ie, xep-0196) 
> so they're more general purpose and suitable for standardization.

We used User Gaming [3] for publishing active game sessions. But what
other XEPs do you mean and how is the relation to this proposal?
Do you think this proposal should be more modular or use more other
XEPs? Or do you think there is no use case of this proposal?

Best regards


[1] http://xmpp.org/extensions/inbox/gamesessions.html
[2] http://xmpp.org/extensions/xep-0134.html#strengths
[3] http://xmpp.org/extensions/xep-0196.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2230 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20090417/2d908bb7/attachment.bin 

From dawid.nowak at nortel.com  Fri Apr 17 03:35:54 2009
From: dawid.nowak at nortel.com (Dawid Nowak)
Date: Fri, 17 Apr 2009 09:35:54 +0100
Subject: [Standards] Comments on XEP-0251
Message-ID: <CF268C57160BE84289D36FF46801A2C80606C129@zharhxm0.corp.nortel.com>

You are right, It should be XEP-0251. 
D

Date: Wed, 15 Apr 2009 17:06:17 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Subject: Re: [Standards] Comments on xep-025 standard
To: XMPP Standards <standards at xmpp.org>
Message-ID: <49E66869.3010404 at stpeter.im>
Content-Type: text/plain; charset="utf-8"

On 4/15/09 11:25 AM, Dawid Nowak wrote:
> Hi,
> I am no expert in XMPP but have been looking at this standard

FYI, we never call something a standard. It's just a specification.

Also, I think you mean XEP-0251: Jingle Session Transfer, no?

http://xmpp.org/extensions/xep-0251.html

> from a
> call centre operator perspective and have following comments :

Your comments are appreciated. I've poked the primary authors of this
specification to get their feedback (my role was mostly editorial).

We'll probably receive more focused feedback on the Jingle list so I
have forwarded it there, too:

http://mail.jabber.org/mailman/listinfo/jingle

More soon.

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090417/1c25cf17/attachment-0001.htm 

From adrian.hornsby at tut.fi  Fri Apr 17 04:03:48 2009
From: adrian.hornsby at tut.fi (hornsby)
Date: Fri, 17 Apr 2009 12:03:48 +0300
Subject: [Standards] EXI as an XMPP stream compression method
Message-ID: <1239959028.6526.13.camel@hornsby-laptop>

Dear All,

Any news regarding EXI as an XMPP stream compression method ?

best,
adrian


On Mon, Mar 10, 2008 at 5:49 PM, Peter Saint-Andre <[EMAIL PROTECTED]>
wrote:


> At its meeting last week [1], the XMPP Council declined [2] to publish
>  the proposal [3] regarding use of Efficient XML Interchange [4] as an
>  XMPP stream compression method conforming to XEP-0138 [5]. The reason is
>  that we're not yet sure if EXI is even workable as a stream compression
>  method. We will seek input from one or more EXI experts regarding this
>  matter before moving forward with publication.

As a developer of a mobile client I say that it's unlikely I will ever
use EXI in this way, since it forces me to have two parsers, one
before the stream upgrade, the other after. I'd rather use EXI
exploiting the initial magic number allowing to start a stream
directly with the binary encoding.

bye

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20090417/a564d790/attachment.htm 

From fabio.forno at gmail.com  Fri Apr 17 04:58:23 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Fri, 17 Apr 2009 11:58:23 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E7F093.1060400@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
Message-ID: <2fd53c3a0904170258v2ca27f17x50d14e5620389f83@mail.gmail.com>

On Fri, Apr 17, 2009 at 4:59 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> I think that the things you are describing fall into the category of
> optimizations that a smart client can implement to improve the user
> experience. But we don't need to describe all that in the spec ("in the
> unlikely event that you get disconnected after receiving some but not
> all of the roster pushes, cache what you've received so far but then
> when you reconnect you can shave a few seconds off the reconnection
> process by requesting the roster based on the version of the last roster
> push you cached, not the last full roster update"). That kind of thing
> is great but IMHO it doesn't really belong in an RFC.

+1

In fact in our implementation based on the current xep we haven't seen
any real issue that can't be dealt with good heuristics

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From stpeter at stpeter.im  Fri Apr 17 08:09:43 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 07:09:43 -0600
Subject: [Standards] EXI as an XMPP stream compression method
In-Reply-To: <1239959028.6526.13.camel@hornsby-laptop>
References: <1239959028.6526.13.camel@hornsby-laptop>
Message-ID: <49E87F97.4080602@stpeter.im>

On 4/17/09 3:03 AM, hornsby wrote:
> Dear All,
> 
> Any news regarding EXI as an XMPP stream compression method ?

The only person who was agitating for this didn't find the time to write
one of the shortest XEPs in existence about this topic (it would be as
long as XEP-0229), which I took as a sign that there isn't a lot of
interest. Besides, the last time we discussed this we realized that EXI
is probably not a simple compression method but a stream feature or even
an alternative connection method requiring its own SRV record and port.
Check the list archives for details.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/861ea9a4/attachment.bin>

From stpeter at stpeter.im  Fri Apr 17 08:21:54 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 07:21:54 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
Message-ID: <49E88272.1090006@stpeter.im>

On 4/16/09 9:23 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> Ahoj Jirka,
>>
>> On 4/16/09 8:39 PM, Ji?? Z?rev?ck? wrote:
>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>> I think you're making it too complicated for the typical usage.
>>>>
>>>> Peter
>>>>
>>> Yeah. You are probably right. These are just nuances that would affect
>>> very little people throughout the whole existence of the protocol, but
>>> given they don't make anything more complex or introduce any
>>> inconveniences for anyone, I think they are worth doing. For all we
>>> know, someone's aggravation over few second longer delay when loading
>>> roster can ultimately lead to World War III... :-D
>> I think that the things you are describing fall into the category of
>> optimizations that a smart client can implement to improve the user
>> experience. But we don't need to describe all that in the spec ("in the
>> unlikely event that you get disconnected after receiving some but not
>> all of the roster pushes, cache what you've received so far but then
>> when you reconnect you can shave a few seconds off the reconnection
>> process by requesting the roster based on the version of the last roster
>> push you cached, not the last full roster update"). That kind of thing
>> is great but IMHO it doesn't really belong in an RFC.
>>
> 
> Actually, I described an error scenario that could occur (but probably
> never would, and even if it did, nobody would likely notice) when both
> client and server utilize a specific optimization. :)  which is
> probably making half of this thread a truly regrettable waste of your
> time... sorry about that... :)

Ji??, it's better to raise issues than to ignore them. Sometimes we
conclude that the issue isn't very serious, but often we don't know that
until we discuss it for a while. So keep posting!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/c446c626/attachment-0001.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 09:06:36 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 16:06:36 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E88272.1090006@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
Message-ID: <e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>
> Ji??, it's better to raise issues than to ignore them. Sometimes we
> conclude that the issue isn't very serious, but often we don't know that
> until we discuss it for a while. So keep posting!
>

Sure, I will.
I guess the only "issue" now is the unneeded restriction you added to
the SVN based on my incorrect feedback. I mean the part "The client
MUST NOT process any of the interim roster pushes until...". I think
you can safely remove it again, as the reason for the change was
proven invalid.

From leon at darkk.net.ru  Fri Apr 17 09:18:37 2009
From: leon at darkk.net.ru (Leonid Evdokimov)
Date: Fri, 17 Apr 2009 21:18:37 +0700
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
Message-ID: <49E88FBD.1050804@darkk.net.ru>

Ji?? Z?rev?ck? wrote:
> I guess the only "issue" now is the unneeded restriction you added to
> the SVN based on my incorrect feedback. I mean the part "The client
> MUST NOT process any of the interim roster pushes until...". I think
> you can safely remove it again, as the reason for the change was
> proven invalid.

No, that's quite valid restriction. Client MAY cache some roster pushes
to resume operation from the middle of "transaction" in case of broken
connection, but it MUST NOT bump it's internal roster version until it
gets the full "transaction" of pushes.

-- 
WBRBW, Leonid Evdokimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/e7d285ac/attachment.pgp>

From zarevucky.jiri at gmail.com  Fri Apr 17 09:37:41 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 16:37:41 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E88FBD.1050804@darkk.net.ru>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru>
Message-ID: <e962983d0904170737v1c77a7e3qa1bf648074f9d0ee@mail.gmail.com>

2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
> Ji?? Z?rev?ck? wrote:
>> I guess the only "issue" now is the unneeded restriction you added to
>> the SVN based on my incorrect feedback. I mean the part "The client
>> MUST NOT process any of the interim roster pushes until...". I think
>> you can safely remove it again, as the reason for the change was
>> proven invalid.
>
> No, that's quite valid restriction. Client MAY cache some roster pushes
> to resume operation from the middle of "transaction" in case of broken
> connection, but it MUST NOT bump it's internal roster version until it
> gets the full "transaction" of pushes.
>

Ok, that seems like a retelling of the restriction. What is the reason
for it? The reason I posted was invalid. Do you know of some other way
it could negatively affect the retrieval?

From zarevucky.jiri at gmail.com  Fri Apr 17 09:40:27 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 16:40:27 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904170737v1c77a7e3qa1bf648074f9d0ee@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru>
	<e962983d0904170737v1c77a7e3qa1bf648074f9d0ee@mail.gmail.com>
Message-ID: <e962983d0904170740j43a71725od6cf70a003486438@mail.gmail.com>

2009/4/17 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com>:
> 2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
>> Ji?? Z?rev?ck? wrote:
>>> I guess the only "issue" now is the unneeded restriction you added to
>>> the SVN based on my incorrect feedback. I mean the part "The client
>>> MUST NOT process any of the interim roster pushes until...". I think
>>> you can safely remove it again, as the reason for the change was
>>> proven invalid.
>>
>> No, that's quite valid restriction. Client MAY cache some roster pushes
>> to resume operation from the middle of "transaction" in case of broken
>> connection, but it MUST NOT bump it's internal roster version until it
>> gets the full "transaction" of pushes.
>>
>
> Ok, that seems like a retelling of the restriction. What is the reason
> for it? The reason I posted was invalid. Do you know of some other way
> it could negatively affect the retrieval?
>

I think you misunderstood the sentence. It forbids any processing at
all until the full transaction is finished. You can't cache anything.

From dave at cridland.net  Fri Apr 17 09:41:26 2009
From: dave at cridland.net (Dave Cridland)
Date: Fri, 17 Apr 2009 15:41:26 +0100
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E88FBD.1050804@darkk.net.ru>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru>
Message-ID: <9746.1239979286.789569@puncture>

On Fri Apr 17 15:18:37 2009, Leonid Evdokimov wrote:
> Ji?? Z?rev?ck? wrote:
> > I guess the only "issue" now is the unneeded restriction you  
> added to
> > the SVN based on my incorrect feedback. I mean the part "The  
> client
> > MUST NOT process any of the interim roster pushes until...". I  
> think
> > you can safely remove it again, as the reason for the change was
> > proven invalid.
> 
> No, that's quite valid restriction. Client MAY cache some roster  
> pushes
> to resume operation from the middle of "transaction" in case of  
> broken
> connection, but it MUST NOT bump it's internal roster version until  
> it
> gets the full "transaction" of pushes.

We decided that each roster push was in and of itself atomic, so the  
"transaction" you're referring to doesn't exist - each roster push  
can be effectively treated as an atomic commit point in and of itself.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Fri Apr 17 09:42:44 2009
From: dave at cridland.net (Dave Cridland)
Date: Fri, 17 Apr 2009 15:42:44 +0100
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
Message-ID: <9746.1239979364.333453@puncture>

On Fri Apr 17 15:06:36 2009, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> >
> > Ji??, it's better to raise issues than to ignore them.  
> Sometimes we
> > conclude that the issue isn't very serious, but often we don't  
> know that
> > until we discuss it for a while. So keep posting!
> >
> 
> Sure, I will.
> I guess the only "issue" now is the unneeded restriction you added  
> to
> the SVN based on my incorrect feedback. I mean the part "The client
> MUST NOT process any of the interim roster pushes until...". I think
> you can safely remove it again, as the reason for the change was
> proven invalid.

While you're looking at this, what's your opinion on the empty roster  
case? (That is, when a roster becomes empty).

It's an odd edge case, but I'm not sure the protocol handles this  
usefully.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From zarevucky.jiri at gmail.com  Fri Apr 17 10:05:06 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 17:05:06 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <9746.1239979364.333453@puncture>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<9746.1239979364.333453@puncture>
Message-ID: <e962983d0904170805w80cb386jf081da338c77de45@mail.gmail.com>

2009/4/17 Dave Cridland <dave at cridland.net>:
> On Fri Apr 17 15:06:36 2009, Ji?? Z?rev?ck? wrote:
>>
>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> >
>> > Ji??, it's better to raise issues than to ignore them. Sometimes we
>> > conclude that the issue isn't very serious, but often we don't know that
>> > until we discuss it for a while. So keep posting!
>> >
>>
>> Sure, I will.
>> I guess the only "issue" now is the unneeded restriction you added to
>> the SVN based on my incorrect feedback. I mean the part "The client
>> MUST NOT process any of the interim roster pushes until...". I think
>> you can safely remove it again, as the reason for the change was
>> proven invalid.
>
> While you're looking at this, what's your opinion on the empty roster case?
> (That is, when a roster becomes empty).
>
> It's an odd edge case, but I'm not sure the protocol handles this usefully.
>

That's really tricky. And surely can't stay that way, since client
wouldn't know, how to interpret it in some cases.

I think it could be solved by sending interim pushes _first_, then an
empty IQ result to mark interim pushes were all sent.
What do you think?

From dave at cridland.net  Fri Apr 17 10:07:30 2009
From: dave at cridland.net (Dave Cridland)
Date: Fri, 17 Apr 2009 16:07:30 +0100
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904170805w80cb386jf081da338c77de45@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>
	<49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<9746.1239979364.333453@puncture>
	<e962983d0904170805w80cb386jf081da338c77de45@mail.gmail.com>
Message-ID: <19468.1239980850.520944@puncture>

On Fri Apr 17 16:05:06 2009, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Dave Cridland <dave at cridland.net>:
> > On Fri Apr 17 15:06:36 2009, Ji?? Z?rev?ck? wrote:
> >>
> >> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> >> >
> >> > Ji??, it's better to raise issues than to ignore them.  
> Sometimes we
> >> > conclude that the issue isn't very serious, but often we don't  
> know that
> >> > until we discuss it for a while. So keep posting!
> >> >
> >>
> >> Sure, I will.
> >> I guess the only "issue" now is the unneeded restriction you  
> added to
> >> the SVN based on my incorrect feedback. I mean the part "The  
> client
> >> MUST NOT process any of the interim roster pushes until...". I  
> think
> >> you can safely remove it again, as the reason for the change was
> >> proven invalid.
> >
> > While you're looking at this, what's your opinion on the empty  
> roster case?
> > (That is, when a roster becomes empty).
> >
> > It's an odd edge case, but I'm not sure the protocol handles this  
> usefully.
> >
> 
> That's really tricky. And surely can't stay that way, since client
> wouldn't know, how to interpret it in some cases.
> 
> I think it could be solved by sending interim pushes _first_, then  
> an
> empty IQ result to mark interim pushes were all sent.
> What do you think?

Or we could respond with "What you have is okay, I may send you some  
pushes", by returning an empty result - we've established there's no  
need to treat these pushes any differently to normal ones, after all.

This then means that an empty roster is different to an empty result,  
and means fewer octets for the optimal case.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From zarevucky.jiri at gmail.com  Fri Apr 17 10:17:17 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 17:17:17 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <19468.1239980850.520944@puncture>
References: <49E4AB23.9000203@stpeter.im> <49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<9746.1239979364.333453@puncture>
	<e962983d0904170805w80cb386jf081da338c77de45@mail.gmail.com>
	<19468.1239980850.520944@puncture>
Message-ID: <e962983d0904170817g221b1018o6d6f54289287af70@mail.gmail.com>

2009/4/17 Dave Cridland <dave at cridland.net>:
> On Fri Apr 17 16:05:06 2009, Ji?? Z?rev?ck? wrote:
>>
>> 2009/4/17 Dave Cridland <dave at cridland.net>:
>> > On Fri Apr 17 15:06:36 2009, Ji?? Z?rev?ck? wrote:
>> >>
>> >> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> >> >
>> >> > Ji??, it's better to raise issues than to ignore them. Sometimes we
>> >> > conclude that the issue isn't very serious, but often we don't know
>> >> > that
>> >> > until we discuss it for a while. So keep posting!
>> >> >
>> >>
>> >> Sure, I will.
>> >> I guess the only "issue" now is the unneeded restriction you added to
>> >> the SVN based on my incorrect feedback. I mean the part "The client
>> >> MUST NOT process any of the interim roster pushes until...". I think
>> >> you can safely remove it again, as the reason for the change was
>> >> proven invalid.
>> >
>> > While you're looking at this, what's your opinion on the empty roster
>> > case?
>> > (That is, when a roster becomes empty).
>> >
>> > It's an odd edge case, but I'm not sure the protocol handles this
>> > usefully.
>> >
>>
>> That's really tricky. And surely can't stay that way, since client
>> wouldn't know, how to interpret it in some cases.
>>
>> I think it could be solved by sending interim pushes _first_, then an
>> empty IQ result to mark interim pushes were all sent.
>> What do you think?
>
> Or we could respond with "What you have is okay, I may send you some
> pushes", by returning an empty result - we've established there's no need to
> treat these pushes any differently to normal ones, after all.
>
> This then means that an empty roster is different to an empty result, and
> means fewer octets for the optimal case.
>

I completely agree. I think that knowing, how many versions are to be
expected on startup, doesn't matter for any implementation.

From stpeter at stpeter.im  Fri Apr 17 10:46:10 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 09:46:10 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <19468.1239980850.520944@puncture>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<9746.1239979364.333453@puncture>	<e962983d0904170805w80cb386jf081da338c77de45@mail.gmail.com>
	<19468.1239980850.520944@puncture>
Message-ID: <49E8A442.4010506@stpeter.im>

On 4/17/09 9:07 AM, Dave Cridland wrote:
> On Fri Apr 17 16:05:06 2009, Ji?? Z?rev?ck? wrote:
>> 2009/4/17 Dave Cridland <dave at cridland.net>:
>>
>> > While you're looking at this, what's your opinion on the empty
>> roster case?
>> > (That is, when a roster becomes empty).
>> >
>> > It's an odd edge case, but I'm not sure the protocol handles this
>> usefully.
>> >
>>
>> That's really tricky. And surely can't stay that way, since client
>> wouldn't know, how to interpret it in some cases.
>>
>> I think it could be solved by sending interim pushes _first_, then an
>> empty IQ result to mark interim pushes were all sent.
>> What do you think?

We can't send an IQ-result that's unrelated to any IQ-set or IQ-get.

> Or we could respond with "What you have is okay, I may send you some
> pushes", by returning an empty result 

That seems better.

> - we've established there's no
> need to treat these pushes any differently to normal ones, after all.

That principle is key, here.

> This then means that an empty roster is different to an empty result,
> and means fewer octets for the optimal case.

Aha, so you are suggesting that an empty roster is this:

<iq type='result'>
  <query/>
</iq>

Whereas an indication that you are up to date (aside from possibly some
roster pushes) is this:

<iq type='result'/>

Correct?

/me ponders

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/b1396901/attachment.bin>

From leon at darkk.net.ru  Fri Apr 17 10:46:25 2009
From: leon at darkk.net.ru (Leonid Evdokimov)
Date: Fri, 17 Apr 2009 22:46:25 +0700
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <9746.1239979286.789569@puncture>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<9746.1239979286.789569@puncture>
Message-ID: <49E8A451.6000304@darkk.net.ru>

Dave Cridland wrote:
>> No, that's quite valid restriction. Client MAY cache some roster pushes
>> to resume operation from the middle of "transaction" in case of broken
>> connection, but it MUST NOT bump it's internal roster version until it
>> gets the full "transaction" of pushes.
> 
> We decided that each roster push was in and of itself atomic, so the
> "transaction" you're referring to doesn't exist - each roster push can
> be effectively treated as an atomic commit point in and of itself.

I still think it exists, let me explain my point of view more precisely.

Here is set of versions:

  <query xmlns='jabber:iq:roster' ver='305'>
    <item jid='bill at shakespeare.lit' subscription='none'/>
  </query>

  <query xmlns='jabber:iq:roster' ver='306'>
    <item jid='bill at shakespeare.lit' subscription='to'/>
  </query>

  <query xmlns='jabber:iq:roster' ver='307'>
    <item jid='shylock at shakespeare.lit' subscription='remove'/>
  </query>

  <query xmlns='jabber:iq:roster' ver='308'>
    <item jid='bill at shakespeare.lit' subscription='both'/>
  </query>

Client knowns 305, current version is 308. The server will send 307, 308
and the notification that the latest version is 308.

Let's assume that connection was broken and client got 307 but not 308,
 client does not know version 307 at the moment, as it *does* *not* know
that bill@ has subscription="to". That's why I name the set of stanzas a
"transaction" and that's why I'm against of processing interim roster
pushes until client has received all pushes.

Let me extend the example and show how things may get wrong if client
behaves in another way.

While client was reconnecting some more roster version bumps occured,
let them include some "reverting" change:

  <query xmlns='jabber:iq:roster' ver='309'>
    <item jid='bill at shakespeare.lit' subscription='to'/>
  </query>

  <query xmlns='jabber:iq:roster' ver='310'>
    <item jid='nurse at capulet.lit' subscription='none'/>
  </query>

Now the difference between 307 and 310 includes nurse@ but does not
include bill at . So client will not know that bill@ has subscription="to"
and will continue to assume that bill@ has subscription="none" (as it
was in version 305).

XEP-0237 does not state that server should send "final state of all
touched roster items", it should send "the final result of all changes
applied" and the result may be understood as the difference.

Am I mistaken somewhere?


Moreover, after constructing this example I don't think that caching
parts of transaction is a good idea. Caching will introduce several
corner cases.


By the way, I added nurse@ to this example to avoid sending empty
difference between two different versions of the roster as XEP suggests
no way to do that. I'm not completely sure that "unchanged" reply is the
best way to handle the situation.

-- 
WBRBW, Leonid Evdokimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/b5c7116a/attachment.pgp>

From stpeter at stpeter.im  Fri Apr 17 10:57:42 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 09:57:42 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E88FBD.1050804@darkk.net.ru>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru>
Message-ID: <49E8A6F6.8090605@stpeter.im>

On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
> Ji?? Z?rev?ck? wrote:
>> I guess the only "issue" now is the unneeded restriction you added to
>> the SVN based on my incorrect feedback. I mean the part "The client
>> MUST NOT process any of the interim roster pushes until...". I think
>> you can safely remove it again, as the reason for the change was
>> proven invalid.
> 
> No, that's quite valid restriction. Client MAY cache some roster pushes
> to resume operation from the middle of "transaction" in case of broken
> connection, but it MUST NOT bump it's internal roster version until it
> gets the full "transaction" of pushes.

That seems right to me. I think we just need to change "process" to
something else (you can process the push, but don't think that you are
up to date until you receive the last one).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/2e4c91df/attachment-0001.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 11:02:56 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 18:02:56 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8A442.4010506@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<9746.1239979364.333453@puncture>
	<e962983d0904170805w80cb386jf081da338c77de45@mail.gmail.com>
	<19468.1239980850.520944@puncture> <49E8A442.4010506@stpeter.im>
Message-ID: <e962983d0904170902k67899bf7tb6329a7724964e18@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>
> We can't send an IQ-result that's unrelated to any IQ-set or IQ-get.
>

I was thinking more like this:

Client sends IQ get.
Server sends interim pushes.
Server sends empty result to the clients get.

>> Or we could respond with "What you have is okay, I may send you some
>> pushes", by returning an empty result
>
> That seems better.
>

That's quite the same except for the order of sending. It's better in
case we treat interim pushes exactly the same as normal ones.

From zarevucky.jiri at gmail.com  Fri Apr 17 11:07:28 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 18:07:28 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8A451.6000304@darkk.net.ru>
References: <49E4AB23.9000203@stpeter.im> <49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru> <9746.1239979286.789569@puncture>
	<49E8A451.6000304@darkk.net.ru>
Message-ID: <e962983d0904170907i2a4b3c73ya2212b823f372e4b@mail.gmail.com>

2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
> Dave Cridland wrote:
>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>> to resume operation from the middle of "transaction" in case of broken
>>> connection, but it MUST NOT bump it's internal roster version until it
>>> gets the full "transaction" of pushes.
>>
>> We decided that each roster push was in and of itself atomic, so the
>> "transaction" you're referring to doesn't exist - each roster push can
>> be effectively treated as an atomic commit point in and of itself.
>
> I still think it exists, let me explain my point of view more precisely.
>
> Here is set of versions:
>
> ?<query xmlns='jabber:iq:roster' ver='305'>
> ? ?<item jid='bill at shakespeare.lit' subscription='none'/>
> ?</query>
>
> ?<query xmlns='jabber:iq:roster' ver='306'>
> ? ?<item jid='bill at shakespeare.lit' subscription='to'/>
> ?</query>
>
> ?<query xmlns='jabber:iq:roster' ver='307'>
> ? ?<item jid='shylock at shakespeare.lit' subscription='remove'/>
> ?</query>
>
> ?<query xmlns='jabber:iq:roster' ver='308'>
> ? ?<item jid='bill at shakespeare.lit' subscription='both'/>
> ?</query>
>
> Client knowns 305, current version is 308. The server will send 307, 308
> and the notification that the latest version is 308.
>
> Let's assume that connection was broken and client got 307 but not 308,
> ?client does not know version 307 at the moment, as it *does* *not* know
> that bill@ has subscription="to". That's why I name the set of stanzas a
> "transaction" and that's why I'm against of processing interim roster
> pushes until client has received all pushes.
>

That's what I was talking about earlier, isn't it?

>
> XEP-0237 does not state that server should send "final state of all
> touched roster items", it should send "the final result of all changes
> applied" and the result may be understood as the difference.
>
> Am I mistaken somewhere?
>

No, that's also the reason for the ultra-rare corner case I posted earlier.

Changing the definition to "final state of all touched roster items"
as you suggest will solve every possible problem and allow us to treat
interim pushes as normal ones.

From leon at darkk.net.ru  Fri Apr 17 11:21:58 2009
From: leon at darkk.net.ru (Leonid Evdokimov)
Date: Fri, 17 Apr 2009 23:21:58 +0700
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904170907i2a4b3c73ya2212b823f372e4b@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<9746.1239979286.789569@puncture>	<49E8A451.6000304@darkk.net.ru>
	<e962983d0904170907i2a4b3c73ya2212b823f372e4b@mail.gmail.com>
Message-ID: <49E8ACA6.3030801@darkk.net.ru>

Ji?? Z?rev?ck? wrote:
>> Let's assume that connection was broken and client got 307 but not 308,
>>  client does not know version 307 at the moment, as it *does* *not* know
>> that bill@ has subscription="to". That's why I name the set of stanzas a
>> "transaction" and that's why I'm against of processing interim roster
>> pushes until client has received all pushes.
> 
> That's what I was talking about earlier, isn't it?

Excuse me, I misread your original message. You're right, that's exactly
the same situation.


>> XEP-0237 does not state that server should send "final state of all
>> touched roster items", it should send "the final result of all changes
>> applied" and the result may be understood as the difference.
> 
> that's also the reason for the ultra-rare corner case I posted earlier.
> 
> Changing the definition to "final state of all touched roster items"
> as you suggest will solve every possible problem and allow us to treat
> interim pushes as normal ones.

Right, it will also eliminate the problem with empty difference between
two roster versions ? the difference will be always non-empty.

This solution increases amount of traffic a bit, but I don't think that
the corner case really deserves extra optimization.

-- 
WBRBW, Leonid Evdokimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/ddac26d8/attachment.pgp>

From stpeter at stpeter.im  Fri Apr 17 12:00:15 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 11:00:15 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8ACA6.3030801@darkk.net.ru>
References: <49E4AB23.9000203@stpeter.im>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>	<9746.1239979286.789569@puncture>	<49E8A451.6000304@darkk.net.ru>	<e962983d0904170907i2a4b3c73ya2212b823f372e4b@mail.gmail.com>
	<49E8ACA6.3030801@darkk.net.ru>
Message-ID: <49E8B59F.3090508@stpeter.im>

On 4/17/09 10:21 AM, Leonid Evdokimov wrote:
> Ji?? Z?rev?ck? wrote:
>>> Let's assume that connection was broken and client got 307 but not 308,
>>>  client does not know version 307 at the moment, as it *does* *not* know
>>> that bill@ has subscription="to". That's why I name the set of stanzas a
>>> "transaction" and that's why I'm against of processing interim roster
>>> pushes until client has received all pushes.
>> That's what I was talking about earlier, isn't it?
> 
> Excuse me, I misread your original message. You're right, that's exactly
> the same situation.
> 
> 
>>> XEP-0237 does not state that server should send "final state of all
>>> touched roster items", it should send "the final result of all changes
>>> applied" and the result may be understood as the difference.
>> that's also the reason for the ultra-rare corner case I posted earlier.
>>
>> Changing the definition to "final state of all touched roster items"
>> as you suggest will solve every possible problem and allow us to treat
>> interim pushes as normal ones.
> 
> Right, it will also eliminate the problem with empty difference between
> two roster versions ? the difference will be always non-empty.

I think this works well.

> This solution increases amount of traffic a bit, but I don't think that
> the corner case really deserves extra optimization.

Agreed.

I'm working to update the spec now...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/5ce9c86c/attachment.bin>

From stpeter at stpeter.im  Fri Apr 17 12:40:08 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 11:40:08 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8A6F6.8090605@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<49E8A6F6.8090605@stpeter.im>
Message-ID: <49E8BEF8.20700@stpeter.im>

On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>> Ji?? Z?rev?ck? wrote:
>>> I guess the only "issue" now is the unneeded restriction you added to
>>> the SVN based on my incorrect feedback. I mean the part "The client
>>> MUST NOT process any of the interim roster pushes until...". I think
>>> you can safely remove it again, as the reason for the change was
>>> proven invalid.
>> No, that's quite valid restriction. Client MAY cache some roster pushes
>> to resume operation from the middle of "transaction" in case of broken
>> connection, but it MUST NOT bump it's internal roster version until it
>> gets the full "transaction" of pushes.
> 
> That seems right to me. I think we just need to change "process" to
> something else (you can process the push, but don't think that you are
> up to date until you receive the last one).

How is this text?

"The client can determine when the interim roster pushes have ended by
comparing the version number it received on the empty <query/> element
against the version number it receives in roster pushes. The client MUST
process the interim roster pushes as it would process any normal roster
push and MAY cache those items in case it loses its connection to the
server during the update process, but MUST NOT increment its internal
roster version until it receives the full set of pushes."

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/5f107daf/attachment.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 12:51:18 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 19:51:18 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8BEF8.20700@stpeter.im>
References: <49E4AB23.9000203@stpeter.im> <49E7E4C1.8000908@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru> <49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im>
Message-ID: <e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>> Ji?? Z?rev?ck? wrote:
>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>> you can safely remove it again, as the reason for the change was
>>>> proven invalid.
>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>> to resume operation from the middle of "transaction" in case of broken
>>> connection, but it MUST NOT bump it's internal roster version until it
>>> gets the full "transaction" of pushes.
>>
>> That seems right to me. I think we just need to change "process" to
>> something else (you can process the push, but don't think that you are
>> up to date until you receive the last one).
>
> How is this text?
>
> "The client can determine when the interim roster pushes have ended by
> comparing the version number it received on the empty <query/> element
> against the version number it receives in roster pushes. The client MUST
> process the interim roster pushes as it would process any normal roster
> push and MAY cache those items in case it loses its connection to the
> server during the update process, but MUST NOT increment its internal
> roster version until it receives the full set of pushes."
>

Waitaminit... Didn't we agree that treating interim pushes the same
way as normal ones is the best approach? Otherwise we yet need to
solve the empty roster case somehow.

From stpeter at stpeter.im  Fri Apr 17 12:52:53 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 11:52:53 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<49E8A6F6.8090605@stpeter.im>	<49E8BEF8.20700@stpeter.im>
	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>
Message-ID: <49E8C1F5.8010809@stpeter.im>

On 4/17/09 11:51 AM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>>> Ji?? Z?rev?ck? wrote:
>>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>> you can safely remove it again, as the reason for the change was
>>>>> proven invalid.
>>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>>> to resume operation from the middle of "transaction" in case of broken
>>>> connection, but it MUST NOT bump it's internal roster version until it
>>>> gets the full "transaction" of pushes.
>>> That seems right to me. I think we just need to change "process" to
>>> something else (you can process the push, but don't think that you are
>>> up to date until you receive the last one).
>> How is this text?
>>
>> "The client can determine when the interim roster pushes have ended by
>> comparing the version number it received on the empty <query/> element
>> against the version number it receives in roster pushes. The client MUST
>> process the interim roster pushes as it would process any normal roster
>> push and MAY cache those items in case it loses its connection to the
>> server during the update process, but MUST NOT increment its internal
>> roster version until it receives the full set of pushes."
>>
> 
> Waitaminit... Didn't we agree that treating interim pushes the same
> way as normal ones is the best approach? Otherwise we yet need to
> solve the empty roster case somehow.

Processing them means you handle them as normal. Just don't think that
you are completely up to date until you receive the last one.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/5c183ecc/attachment.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 12:55:01 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 19:55:01 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8C1F5.8010809@stpeter.im>
References: <49E4AB23.9000203@stpeter.im> <49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru> <49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im>
	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>
	<49E8C1F5.8010809@stpeter.im>
Message-ID: <e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> On 4/17/09 11:51 AM, Ji?? Z?rev?ck? wrote:
>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>>>> Ji?? Z?rev?ck? wrote:
>>>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>> you can safely remove it again, as the reason for the change was
>>>>>> proven invalid.
>>>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>>>> to resume operation from the middle of "transaction" in case of broken
>>>>> connection, but it MUST NOT bump it's internal roster version until it
>>>>> gets the full "transaction" of pushes.
>>>> That seems right to me. I think we just need to change "process" to
>>>> something else (you can process the push, but don't think that you are
>>>> up to date until you receive the last one).
>>> How is this text?
>>>
>>> "The client can determine when the interim roster pushes have ended by
>>> comparing the version number it received on the empty <query/> element
>>> against the version number it receives in roster pushes. The client MUST
>>> process the interim roster pushes as it would process any normal roster
>>> push and MAY cache those items in case it loses its connection to the
>>> server during the update process, but MUST NOT increment its internal
>>> roster version until it receives the full set of pushes."
>>>
>>
>> Waitaminit... Didn't we agree that treating interim pushes the same
>> way as normal ones is the best approach? Otherwise we yet need to
>> solve the empty roster case somehow.
>
> Processing them means you handle them as normal. Just don't think that
> you are completely up to date until you receive the last one.
>

Ok... now I definitely don't follow... processing them as normal also
means you won't know what the last one it... and we agreed (at least
with Dave) we don't need to know that anyway...

From stpeter at stpeter.im  Fri Apr 17 12:57:20 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 11:57:20 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<49E8A6F6.8090605@stpeter.im>	<49E8BEF8.20700@stpeter.im>	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>	<49E8C1F5.8010809@stpeter.im>
	<e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>
Message-ID: <49E8C300.3080101@stpeter.im>

On 4/17/09 11:55 AM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> On 4/17/09 11:51 AM, Ji?? Z?rev?ck? wrote:
>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>>>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>>>>> Ji?? Z?rev?ck? wrote:
>>>>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>>> you can safely remove it again, as the reason for the change was
>>>>>>> proven invalid.
>>>>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>>>>> to resume operation from the middle of "transaction" in case of broken
>>>>>> connection, but it MUST NOT bump it's internal roster version until it
>>>>>> gets the full "transaction" of pushes.
>>>>> That seems right to me. I think we just need to change "process" to
>>>>> something else (you can process the push, but don't think that you are
>>>>> up to date until you receive the last one).
>>>> How is this text?
>>>>
>>>> "The client can determine when the interim roster pushes have ended by
>>>> comparing the version number it received on the empty <query/> element
>>>> against the version number it receives in roster pushes. The client MUST
>>>> process the interim roster pushes as it would process any normal roster
>>>> push and MAY cache those items in case it loses its connection to the
>>>> server during the update process, but MUST NOT increment its internal
>>>> roster version until it receives the full set of pushes."
>>>>
>>> Waitaminit... Didn't we agree that treating interim pushes the same
>>> way as normal ones is the best approach? Otherwise we yet need to
>>> solve the empty roster case somehow.
>> Processing them means you handle them as normal. Just don't think that
>> you are completely up to date until you receive the last one.
>>
> 
> Ok... now I definitely don't follow... processing them as normal also
> means you won't know what the last one it... and we agreed (at least
> with Dave) we don't need to know that anyway...

For the purposes of Roster Versioning, you MUST NOT think that you are
up to date if you've received only some of the roster pushes. What is
not clear about that?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/d563df4b/attachment-0001.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 12:59:48 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 19:59:48 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8C300.3080101@stpeter.im>
References: <49E4AB23.9000203@stpeter.im> <49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru> <49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im>
	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>
	<49E8C1F5.8010809@stpeter.im>
	<e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>
	<49E8C300.3080101@stpeter.im>
Message-ID: <e962983d0904171059g17766197nd1a8b1ea79861fdd@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> On 4/17/09 11:55 AM, Ji?? Z?rev?ck? wrote:
>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>> On 4/17/09 11:51 AM, Ji?? Z?rev?ck? wrote:
>>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>>>>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>>>>>> Ji?? Z?rev?ck? wrote:
>>>>>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>>>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>>>> you can safely remove it again, as the reason for the change was
>>>>>>>> proven invalid.
>>>>>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>>>>>> to resume operation from the middle of "transaction" in case of broken
>>>>>>> connection, but it MUST NOT bump it's internal roster version until it
>>>>>>> gets the full "transaction" of pushes.
>>>>>> That seems right to me. I think we just need to change "process" to
>>>>>> something else (you can process the push, but don't think that you are
>>>>>> up to date until you receive the last one).
>>>>> How is this text?
>>>>>
>>>>> "The client can determine when the interim roster pushes have ended by
>>>>> comparing the version number it received on the empty <query/> element
>>>>> against the version number it receives in roster pushes. The client MUST
>>>>> process the interim roster pushes as it would process any normal roster
>>>>> push and MAY cache those items in case it loses its connection to the
>>>>> server during the update process, but MUST NOT increment its internal
>>>>> roster version until it receives the full set of pushes."
>>>>>
>>>> Waitaminit... Didn't we agree that treating interim pushes the same
>>>> way as normal ones is the best approach? Otherwise we yet need to
>>>> solve the empty roster case somehow.
>>> Processing them means you handle them as normal. Just don't think that
>>> you are completely up to date until you receive the last one.
>>>
>>
>> Ok... now I definitely don't follow... processing them as normal also
>> means you won't know what the last one it... and we agreed (at least
>> with Dave) we don't need to know that anyway...
>
> For the purposes of Roster Versioning, you MUST NOT think that you are
> up to date if you've received only some of the roster pushes. What is
> not clear about that?
>

That it contradicts the "treat as normal" statement. Client is always
as up-to-date as the version number of the last push it processed.
There is no up-to-date state. There is just client's roster version.

From stpeter at stpeter.im  Fri Apr 17 13:04:20 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 12:04:20 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171059g17766197nd1a8b1ea79861fdd@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<49E8A6F6.8090605@stpeter.im>	<49E8BEF8.20700@stpeter.im>	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>	<49E8C1F5.8010809@stpeter.im>	<e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>	<49E8C300.3080101@stpeter.im>
	<e962983d0904171059g17766197nd1a8b1ea79861fdd@mail.gmail.com>
Message-ID: <49E8C4A4.9080405@stpeter.im>

On 4/17/09 11:59 AM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> On 4/17/09 11:55 AM, Ji?? Z?rev?ck? wrote:
>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>> On 4/17/09 11:51 AM, Ji?? Z?rev?ck? wrote:
>>>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>>>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>>>>>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>>>>>>> Ji?? Z?rev?ck? wrote:
>>>>>>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>>>>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>>>>> you can safely remove it again, as the reason for the change was
>>>>>>>>> proven invalid.
>>>>>>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>>>>>>> to resume operation from the middle of "transaction" in case of broken
>>>>>>>> connection, but it MUST NOT bump it's internal roster version until it
>>>>>>>> gets the full "transaction" of pushes.
>>>>>>> That seems right to me. I think we just need to change "process" to
>>>>>>> something else (you can process the push, but don't think that you are
>>>>>>> up to date until you receive the last one).
>>>>>> How is this text?
>>>>>>
>>>>>> "The client can determine when the interim roster pushes have ended by
>>>>>> comparing the version number it received on the empty <query/> element
>>>>>> against the version number it receives in roster pushes. The client MUST
>>>>>> process the interim roster pushes as it would process any normal roster
>>>>>> push and MAY cache those items in case it loses its connection to the
>>>>>> server during the update process, but MUST NOT increment its internal
>>>>>> roster version until it receives the full set of pushes."
>>>>>>
>>>>> Waitaminit... Didn't we agree that treating interim pushes the same
>>>>> way as normal ones is the best approach? Otherwise we yet need to
>>>>> solve the empty roster case somehow.
>>>> Processing them means you handle them as normal. Just don't think that
>>>> you are completely up to date until you receive the last one.
>>>>
>>> Ok... now I definitely don't follow... processing them as normal also
>>> means you won't know what the last one it... and we agreed (at least
>>> with Dave) we don't need to know that anyway...
>> For the purposes of Roster Versioning, you MUST NOT think that you are
>> up to date if you've received only some of the roster pushes. What is
>> not clear about that?
>>
> 
> That it contradicts the "treat as normal" statement. Client is always
> as up-to-date as the version number of the last push it processed.
> There is no up-to-date state. There is just client's roster version.

You treat the roster push itself as normal -- update your local version
of the roster, update your local presence database if appropriate,
change the cute little icon in the GUI that shows the subscription
state, and whatever all else you care about. But because you are a
client that knows about roster versioning, you don't yet modify the
internal counter that keeps track of which roster version is the most
recent -- so in our example you still think that you have version 299,
not 307 or whatever the numbers are. If you then get disconnected before
you receive the roster push that matches the last version number that
the server communicated to you, you request the version number that you
have in your local counter (e.g., 299). Once you receive 307, you change
the counter from 299 to 307.

What is unclear?

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/687a5297/attachment.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 13:15:39 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 20:15:39 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8C4A4.9080405@stpeter.im>
References: <49E4AB23.9000203@stpeter.im> <49E88FBD.1050804@darkk.net.ru>
	<49E8A6F6.8090605@stpeter.im> <49E8BEF8.20700@stpeter.im>
	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>
	<49E8C1F5.8010809@stpeter.im>
	<e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>
	<49E8C300.3080101@stpeter.im>
	<e962983d0904171059g17766197nd1a8b1ea79861fdd@mail.gmail.com>
	<49E8C4A4.9080405@stpeter.im>
Message-ID: <e962983d0904171115x5f8962e2jfd9fe74ab504739@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> On 4/17/09 11:59 AM, Ji?? Z?rev?ck? wrote:
>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>> On 4/17/09 11:55 AM, Ji?? Z?rev?ck? wrote:
>>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>>> On 4/17/09 11:51 AM, Ji?? Z?rev?ck? wrote:
>>>>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>>>>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>>>>>>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>>>>>>>> Ji?? Z?rev?ck? wrote:
>>>>>>>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>>>>>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>>>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>>>>>> you can safely remove it again, as the reason for the change was
>>>>>>>>>> proven invalid.
>>>>>>>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>>>>>>>> to resume operation from the middle of "transaction" in case of broken
>>>>>>>>> connection, but it MUST NOT bump it's internal roster version until it
>>>>>>>>> gets the full "transaction" of pushes.
>>>>>>>> That seems right to me. I think we just need to change "process" to
>>>>>>>> something else (you can process the push, but don't think that you are
>>>>>>>> up to date until you receive the last one).
>>>>>>> How is this text?
>>>>>>>
>>>>>>> "The client can determine when the interim roster pushes have ended by
>>>>>>> comparing the version number it received on the empty <query/> element
>>>>>>> against the version number it receives in roster pushes. The client MUST
>>>>>>> process the interim roster pushes as it would process any normal roster
>>>>>>> push and MAY cache those items in case it loses its connection to the
>>>>>>> server during the update process, but MUST NOT increment its internal
>>>>>>> roster version until it receives the full set of pushes."
>>>>>>>
>>>>>> Waitaminit... Didn't we agree that treating interim pushes the same
>>>>>> way as normal ones is the best approach? Otherwise we yet need to
>>>>>> solve the empty roster case somehow.
>>>>> Processing them means you handle them as normal. Just don't think that
>>>>> you are completely up to date until you receive the last one.
>>>>>
>>>> Ok... now I definitely don't follow... processing them as normal also
>>>> means you won't know what the last one it... and we agreed (at least
>>>> with Dave) we don't need to know that anyway...
>>> For the purposes of Roster Versioning, you MUST NOT think that you are
>>> up to date if you've received only some of the roster pushes. What is
>>> not clear about that?
>>>
>>
>> That it contradicts the "treat as normal" statement. Client is always
>> as up-to-date as the version number of the last push it processed.
>> There is no up-to-date state. There is just client's roster version.
>
> You treat the roster push itself as normal -- update your local version
> of the roster, update your local presence database if appropriate,
> change the cute little icon in the GUI that shows the subscription
> state, and whatever all else you care about. But because you are a
> client that knows about roster versioning, you don't yet modify the
> internal counter that keeps track of which roster version is the most
> recent -- so in our example you still think that you have version 299,
> not 307 or whatever the numbers are. If you then get disconnected before
> you receive the roster push that matches the last version number that
> the server communicated to you, you request the version number that you
> have in your local counter (e.g., 299). Once you receive 307, you change
> the counter from 299 to 307.
>
> What is unclear?
>
> /psa
>
>

We definitely got out of sync. Such holding back of version isn't
needed and is impossible if we are to use the way Dave proposed and I
agreed with.

Now to be completely clear, a little use case: (based on the current spec)

However, if returning the complete roster would use more bandwidth
than sending individual roster pushes to the client (e.g., if the
roster contains many items, only a few of which have changed), the
server SHOULD return an empty IQ result, then send individual roster
pushes.

Example 4. Roster result with no content

<iq from='romeo at montague.lit' id='r1' to='romeo at montague.lit/home'
type='result' />


Example 5. Server sends any changes since the clients state as ordinary pushes

<iq from='romeo at montague.lit' id='p1' to='romeo at montague.lit/home' type='set'>
  <query xmlns='jabber:iq:roster' ver='313'>
    <item jid='shylock at shakespeare.lit' subscription='remove'/>
  </query>
</iq>

<iq from='romeo at montague.lit' id='p2' to='romeo at montague.lit/home' type='set'>
  <query xmlns='jabber:iq:roster' ver='317'>
    <item jid='bill at shakespeare.lit' subscription='both'/>
  </query>
</iq>


The client can't figure out which push is the last change, but that
doesn't matter, since all pushes are atomic.

To rule out several possible corner cases, server MUST always send
pushes for every changed item, even if there were several changes that
in fact reverted itself. That means the server MUST NOT send a simple
difference, but instead MUST send all the items that were modified at
any point in history.


---------------------

Now we are hopefully resynced and can talk about the same problem again.

From leon at darkk.net.ru  Fri Apr 17 13:24:55 2009
From: leon at darkk.net.ru (Leonid Evdokimov)
Date: Sat, 18 Apr 2009 01:24:55 +0700
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8BEF8.20700@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904141144ifbeeabbhf7feaf442c05c9f1@mail.gmail.com>	<49E7E4C1.8000908@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>	<49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im>
Message-ID: <49E8C977.5040700@darkk.net.ru>

Peter Saint-Andre wrote:
> "The client can determine when the interim roster pushes have ended by
> comparing the version number it received on the empty <query/> element
> against the version number it receives in roster pushes. The client MUST
> process the interim roster pushes as it would process any normal roster
> push and MAY cache those items in case it loses its connection to the
> server during the update process, but MUST NOT increment its internal
> roster version until it receives the full set of pushes."

As far as I see, caching may be easily done only in case when "the
result" is not "the difference between two states", but "final state of
all roster items touched between two states". Otherwise caching of the
items is quite useless as the client would have to rerequest same items
on reconnection to avoid the corner-case presented above.

Please, clarify "the final result" in the phrase "The interim roster
pushes would not include all of the intermediate steps, only the final
result of all changes applied while the client was in fact offline".

If the result if the difference:
* client must not cache items (it's useless)
* server may have to store all roster versions to produce proper diffs
(at least I see no other way right now, maybe I'm wrong)

If the result if set of touched roster items:
* client MAY increment his roster version counter while processing
items. Yes, client will not know if his counter reflects "real" roster
version, but client will know that (a) he is/isn't up to date (b) roster
item mr.foo at example.org was/wasn't modified since version 42 and that's
enough for continuing incremental update in case of broken connection.
* server has to store only "mtime" of every roster item (including deleted?)

So the first method works like trivial VCS and the second one works like
rsync or incremental tar. What method is actually described in the XEP ?
Seems, that will also answer Ji??'s question about `treat as normal`
statement.

-- 
WBRBW, Leonid Evdokimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090418/edf5b729/attachment-0001.pgp>

From stpeter at stpeter.im  Fri Apr 17 13:28:18 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 12:28:18 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171115x5f8962e2jfd9fe74ab504739@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<49E88FBD.1050804@darkk.net.ru>	<49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im>	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>	<49E8C1F5.8010809@stpeter.im>	<e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>	<49E8C300.3080101@stpeter.im>	<e962983d0904171059g17766197nd1a8b1ea79861fdd@mail.gmail.com>	<49E8C4A4.9080405@stpeter.im>
	<e962983d0904171115x5f8962e2jfd9fe74ab504739@mail.gmail.com>
Message-ID: <49E8CA42.1050208@stpeter.im>

On 4/17/09 12:15 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> On 4/17/09 11:59 AM, Ji?? Z?rev?ck? wrote:
>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>> On 4/17/09 11:55 AM, Ji?? Z?rev?ck? wrote:
>>>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>>>> On 4/17/09 11:51 AM, Ji?? Z?rev?ck? wrote:
>>>>>>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>>>>>>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
>>>>>>>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
>>>>>>>>>> Ji?? Z?rev?ck? wrote:
>>>>>>>>>>> I guess the only "issue" now is the unneeded restriction you added to
>>>>>>>>>>> the SVN based on my incorrect feedback. I mean the part "The client
>>>>>>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>>>>>>> you can safely remove it again, as the reason for the change was
>>>>>>>>>>> proven invalid.
>>>>>>>>>> No, that's quite valid restriction. Client MAY cache some roster pushes
>>>>>>>>>> to resume operation from the middle of "transaction" in case of broken
>>>>>>>>>> connection, but it MUST NOT bump it's internal roster version until it
>>>>>>>>>> gets the full "transaction" of pushes.
>>>>>>>>> That seems right to me. I think we just need to change "process" to
>>>>>>>>> something else (you can process the push, but don't think that you are
>>>>>>>>> up to date until you receive the last one).
>>>>>>>> How is this text?
>>>>>>>>
>>>>>>>> "The client can determine when the interim roster pushes have ended by
>>>>>>>> comparing the version number it received on the empty <query/> element
>>>>>>>> against the version number it receives in roster pushes. The client MUST
>>>>>>>> process the interim roster pushes as it would process any normal roster
>>>>>>>> push and MAY cache those items in case it loses its connection to the
>>>>>>>> server during the update process, but MUST NOT increment its internal
>>>>>>>> roster version until it receives the full set of pushes."
>>>>>>>>
>>>>>>> Waitaminit... Didn't we agree that treating interim pushes the same
>>>>>>> way as normal ones is the best approach? Otherwise we yet need to
>>>>>>> solve the empty roster case somehow.
>>>>>> Processing them means you handle them as normal. Just don't think that
>>>>>> you are completely up to date until you receive the last one.
>>>>>>
>>>>> Ok... now I definitely don't follow... processing them as normal also
>>>>> means you won't know what the last one it... and we agreed (at least
>>>>> with Dave) we don't need to know that anyway...
>>>> For the purposes of Roster Versioning, you MUST NOT think that you are
>>>> up to date if you've received only some of the roster pushes. What is
>>>> not clear about that?
>>>>
>>> That it contradicts the "treat as normal" statement. Client is always
>>> as up-to-date as the version number of the last push it processed.
>>> There is no up-to-date state. There is just client's roster version.
>> You treat the roster push itself as normal -- update your local version
>> of the roster, update your local presence database if appropriate,
>> change the cute little icon in the GUI that shows the subscription
>> state, and whatever all else you care about. But because you are a
>> client that knows about roster versioning, you don't yet modify the
>> internal counter that keeps track of which roster version is the most
>> recent -- so in our example you still think that you have version 299,
>> not 307 or whatever the numbers are. If you then get disconnected before
>> you receive the roster push that matches the last version number that
>> the server communicated to you, you request the version number that you
>> have in your local counter (e.g., 299). Once you receive 307, you change
>> the counter from 299 to 307.
>>
>> What is unclear?
>>
>> /psa
>>
>>
> 
> We definitely got out of sync. Such holding back of version isn't
> needed and is impossible if we are to use the way Dave proposed and I
> agreed with.
> 
> Now to be completely clear, a little use case: (based on the current spec)
> 
> However, if returning the complete roster would use more bandwidth
> than sending individual roster pushes to the client (e.g., if the
> roster contains many items, only a few of which have changed), the
> server SHOULD return an empty IQ result, then send individual roster
> pushes.
> 
> Example 4. Roster result with no content
> 
> <iq from='romeo at montague.lit' id='r1' to='romeo at montague.lit/home'
> type='result' />
> 
> 
> Example 5. Server sends any changes since the clients state as ordinary pushes
> 
> <iq from='romeo at montague.lit' id='p1' to='romeo at montague.lit/home' type='set'>
>   <query xmlns='jabber:iq:roster' ver='313'>
>     <item jid='shylock at shakespeare.lit' subscription='remove'/>
>   </query>
> </iq>
> 
> <iq from='romeo at montague.lit' id='p2' to='romeo at montague.lit/home' type='set'>
>   <query xmlns='jabber:iq:roster' ver='317'>
>     <item jid='bill at shakespeare.lit' subscription='both'/>
>   </query>
> </iq>
> 
> 
> The client can't figure out which push is the last change, but that
> doesn't matter, since all pushes are atomic.
> 
> To rule out several possible corner cases, server MUST always send
> pushes for every changed item, even if there were several changes that
> in fact reverted itself. That means the server MUST NOT send a simple
> difference, but instead MUST send all the items that were modified at
> any point in history.
> 
> 
> ---------------------
> 
> Now we are hopefully resynced and can talk about the same problem again.

Maybe we are back in sync. I think I processed some incremental protocol
versions but not all of them, then I got mentally disconnected. ;-) I'll
reply again once I've grokked the (seeming) consensus.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/e0a766ad/attachment.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 13:43:09 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 20:43:09 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8C977.5040700@darkk.net.ru>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>
	<49E7F093.1060400@stpeter.im>
	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>
	<49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru> <49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im> <49E8C977.5040700@darkk.net.ru>
Message-ID: <e962983d0904171143v61ff17an5813ddefa3ef7929@mail.gmail.com>

2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
> ...
>
> So the first method works like trivial VCS and the second one works like
> rsync or incremental tar. What method is actually described in the XEP ?
> Seems, that will also answer Ji??'s question about `treat as normal`
> statement.
>

The general idea of this thread is to say what should XEP actually
describe, right? ;) Can you please comment my example? I'd like to
know what you think.

From stpeter at stpeter.im  Fri Apr 17 13:48:24 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 12:48:24 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171143v61ff17an5813ddefa3ef7929@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<49E8A6F6.8090605@stpeter.im>	<49E8BEF8.20700@stpeter.im>
	<49E8C977.5040700@darkk.net.ru>
	<e962983d0904171143v61ff17an5813ddefa3ef7929@mail.gmail.com>
Message-ID: <49E8CEF8.9090904@stpeter.im>

On 4/17/09 12:43 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
>> ...
>>
>> So the first method works like trivial VCS and the second one works like
>> rsync or incremental tar. What method is actually described in the XEP ?
>> Seems, that will also answer Ji??'s question about `treat as normal`
>> statement.
>>
> 
> The general idea of this thread is to say what should XEP actually
> describe, right? ;) Can you please comment my example? I'd like to
> know what you think.

I *think* we have consensus, but I'm still pondering it. I will update
the spec accordingly to make sure that I understand it.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/59d69343/attachment-0001.bin>

From stpeter at stpeter.im  Fri Apr 17 13:57:04 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 12:57:04 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8CEF8.9090904@stpeter.im>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904161939v3ebcaaf6v29c3c2b1ad852533@mail.gmail.com>	<49E7F093.1060400@stpeter.im>	<e962983d0904162023p59af2804ve027cf12d6c85405@mail.gmail.com>	<49E88272.1090006@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>	<49E8A6F6.8090605@stpeter.im>	<49E8BEF8.20700@stpeter.im>	<49E8C977.5040700@darkk.net.ru>	<e962983d0904171143v61ff17an5813ddefa3ef7929@mail.gmail.com>
	<49E8CEF8.9090904@stpeter.im>
Message-ID: <49E8D100.8050307@stpeter.im>

On 4/17/09 12:48 PM, Peter Saint-Andre wrote:
> On 4/17/09 12:43 PM, Ji?? Z?rev?ck? wrote:
>> 2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
>>> ...
>>>
>>> So the first method works like trivial VCS and the second one works like
>>> rsync or incremental tar. What method is actually described in the XEP ?
>>> Seems, that will also answer Ji??'s question about `treat as normal`
>>> statement.
>>>
>> The general idea of this thread is to say what should XEP actually
>> describe, right? ;) Can you please comment my example? I'd like to
>> know what you think.
> 
> I *think* we have consensus, but I'm still pondering it. I will update
> the spec accordingly to make sure that I understand it.

Before I get too far in the spec updates, here is an example.

Client thinks version is 299. Server thinks it is 309. To simplify,
consider every odd version number to be significant (the server will be
pushing 301, 303, 305, 307, 309). So:

C: IQ-get [299]
S: IQ-result
S: push [301]
S: push [303]
S: push [305]
</stream:stream>
C: IQ-get [305]
S: push [307]
S: push [309]

Yes?

/psa


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/b0341669/attachment.bin>

From zarevucky.jiri at gmail.com  Fri Apr 17 14:00:11 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 21:00:11 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8D100.8050307@stpeter.im>
References: <49E4AB23.9000203@stpeter.im> <49E88272.1090006@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru> <49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im> <49E8C977.5040700@darkk.net.ru>
	<e962983d0904171143v61ff17an5813ddefa3ef7929@mail.gmail.com>
	<49E8CEF8.9090904@stpeter.im> <49E8D100.8050307@stpeter.im>
Message-ID: <e962983d0904171200r46d3b6acg1a2e2ad973f09925@mail.gmail.com>

2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
> On 4/17/09 12:48 PM, Peter Saint-Andre wrote:
>> On 4/17/09 12:43 PM, Ji?? Z?rev?ck? wrote:
>>> 2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
>>>> ...
>>>>
>>>> So the first method works like trivial VCS and the second one works like
>>>> rsync or incremental tar. What method is actually described in the XEP ?
>>>> Seems, that will also answer Ji??'s question about `treat as normal`
>>>> statement.
>>>>
>>> The general idea of this thread is to say what should XEP actually
>>> describe, right? ;) Can you please comment my example? I'd like to
>>> know what you think.
>>
>> I *think* we have consensus, but I'm still pondering it. I will update
>> the spec accordingly to make sure that I understand it.
>
> Before I get too far in the spec updates, here is an example.
>
> Client thinks version is 299. Server thinks it is 309. To simplify,
> consider every odd version number to be significant (the server will be
> pushing 301, 303, 305, 307, 309). So:
>
> C: IQ-get [299]
> S: IQ-result
> S: push [301]
> S: push [303]
> S: push [305]
> </stream:stream>
> C: IQ-get [305]
> S: push [307]
> S: push [309]
>
> Yes?
>

That's right.

From zarevucky.jiri at gmail.com  Fri Apr 17 14:01:15 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 17 Apr 2009 21:01:15 +0200
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171200r46d3b6acg1a2e2ad973f09925@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>
	<49E88FBD.1050804@darkk.net.ru> <49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im> <49E8C977.5040700@darkk.net.ru>
	<e962983d0904171143v61ff17an5813ddefa3ef7929@mail.gmail.com>
	<49E8CEF8.9090904@stpeter.im> <49E8D100.8050307@stpeter.im>
	<e962983d0904171200r46d3b6acg1a2e2ad973f09925@mail.gmail.com>
Message-ID: <e962983d0904171201t777bef52xebd41f85ce959023@mail.gmail.com>

2009/4/17 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com>:
> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>> On 4/17/09 12:48 PM, Peter Saint-Andre wrote:
>>> On 4/17/09 12:43 PM, Ji?? Z?rev?ck? wrote:
>>>> 2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
>>>>> ...
>>>>>
>>>>> So the first method works like trivial VCS and the second one works like
>>>>> rsync or incremental tar. What method is actually described in the XEP ?
>>>>> Seems, that will also answer Ji??'s question about `treat as normal`
>>>>> statement.
>>>>>
>>>> The general idea of this thread is to say what should XEP actually
>>>> describe, right? ;) Can you please comment my example? I'd like to
>>>> know what you think.
>>>
>>> I *think* we have consensus, but I'm still pondering it. I will update
>>> the spec accordingly to make sure that I understand it.
>>
>> Before I get too far in the spec updates, here is an example.
>>
>> Client thinks version is 299. Server thinks it is 309. To simplify,
>> consider every odd version number to be significant (the server will be
>> pushing 301, 303, 305, 307, 309). So:
>>
>> C: IQ-get [299]
>> S: IQ-result
>> S: push [301]
>> S: push [303]
>> S: push [305]
>> </stream:stream>
>> C: IQ-get [305]
>> S: push [307]
>> S: push [309]
>>
>> Yes?
>>
>
> That's right.
>

But you forget the second IQ-result. :)

From stpeter at stpeter.im  Fri Apr 17 14:09:58 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 13:09:58 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171201t777bef52xebd41f85ce959023@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>	<e962983d0904170706g63227e99q57f3bd8391fd0fd0@mail.gmail.com>	<49E88FBD.1050804@darkk.net.ru>
	<49E8A6F6.8090605@stpeter.im>	<49E8BEF8.20700@stpeter.im>
	<49E8C977.5040700@darkk.net.ru>	<e962983d0904171143v61ff17an5813ddefa3ef7929@mail.gmail.com>	<49E8CEF8.9090904@stpeter.im>
	<49E8D100.8050307@stpeter.im>	<e962983d0904171200r46d3b6acg1a2e2ad973f09925@mail.gmail.com>
	<e962983d0904171201t777bef52xebd41f85ce959023@mail.gmail.com>
Message-ID: <49E8D406.1080505@stpeter.im>

On 4/17/09 1:01 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/17 Ji?? Z?rev?ck? <zarevucky.jiri at gmail.com>:
>> 2009/4/17 Peter Saint-Andre <stpeter at stpeter.im>:
>>> On 4/17/09 12:48 PM, Peter Saint-Andre wrote:
>>>> On 4/17/09 12:43 PM, Ji?? Z?rev?ck? wrote:
>>>>> 2009/4/17 Leonid Evdokimov <leon at darkk.net.ru>:
>>>>>> ...
>>>>>>
>>>>>> So the first method works like trivial VCS and the second one works like
>>>>>> rsync or incremental tar. What method is actually described in the XEP ?
>>>>>> Seems, that will also answer Ji??'s question about `treat as normal`
>>>>>> statement.
>>>>>>
>>>>> The general idea of this thread is to say what should XEP actually
>>>>> describe, right? ;) Can you please comment my example? I'd like to
>>>>> know what you think.
>>>> I *think* we have consensus, but I'm still pondering it. I will update
>>>> the spec accordingly to make sure that I understand it.
>>> Before I get too far in the spec updates, here is an example.
>>>
>>> Client thinks version is 299. Server thinks it is 309. To simplify,
>>> consider every odd version number to be significant (the server will be
>>> pushing 301, 303, 305, 307, 309). So:
>>>
>>> C: IQ-get [299]
>>> S: IQ-result
>>> S: push [301]
>>> S: push [303]
>>> S: push [305]
>>> </stream:stream>
>>> C: IQ-get [305]
>>> S: push [307]
>>> S: push [309]
>>>
>>> Yes?
>>>
>> That's right.
>>
> 
> But you forget the second IQ-result. :)

Well, sure, typed it up fast. :P


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/65bfd18b/attachment-0001.bin>

From leon at darkk.net.ru  Fri Apr 17 15:08:09 2009
From: leon at darkk.net.ru (Leonid Evdokimov)
Date: Sat, 18 Apr 2009 03:08:09 +0700
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <e962983d0904171115x5f8962e2jfd9fe74ab504739@mail.gmail.com>
References: <49E4AB23.9000203@stpeter.im>
	<49E88FBD.1050804@darkk.net.ru>	<49E8A6F6.8090605@stpeter.im>
	<49E8BEF8.20700@stpeter.im>	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>	<49E8C1F5.8010809@stpeter.im>	<e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>	<49E8C300.3080101@stpeter.im>	<e962983d0904171059g17766197nd1a8b1ea79861fdd@mail.gmail.com>	<49E8C4A4.9080405@stpeter.im>
	<e962983d0904171115x5f8962e2jfd9fe74ab504739@mail.gmail.com>
Message-ID: <49E8E1A9.6060005@darkk.net.ru>

Ji?? Z?rev?ck? wrote:
> Example 4. Roster result with no content
> 
> <iq from='romeo at montague.lit' id='r1' to='romeo at montague.lit/home'
> type='result' />
> 
> Example 5. Server sends any changes since the clients state as ordinary pushes
> 
> <iq from='romeo at montague.lit' id='p1' to='romeo at montague.lit/home' type='set'>
>   <query xmlns='jabber:iq:roster' ver='313'>
>     <item jid='shylock at shakespeare.lit' subscription='remove'/>
>   </query>
> </iq>
> 
> <iq from='romeo at montague.lit' id='p2' to='romeo at montague.lit/home' type='set'>
>   <query xmlns='jabber:iq:roster' ver='317'>
>     <item jid='bill at shakespeare.lit' subscription='both'/>
>   </query>
> </iq>
> 
> 
> The client can't figure out which push is the last change, but that
> doesn't matter, since all pushes are atomic.

?Example 2. Roster result (unchanged)? equals ?Example 4. Roster result
with no content?. Yes, I understand that it's ok to send same reply in
both cases as it has following semantics: ?roster updates (if any) will
be sent as subsequent roster pushes?.

The client can't figure out which push is the last change, so it can't
send initial presence after receiving up-to-date roster as client never
knows if it is up-to-date. I don't know if that really matters, but that
interferes a bit with RFC3921:

| 7.3.  Retrieving One's Roster on Login
|
| Upon connecting to the server and becoming an active resource, a
| client SHOULD request the roster before sending initial presence
| (however, because receiving the roster may not be desirable for all
| resources, e.g., a connection with limited bandwidth, the client's
| request for the roster is OPTIONAL).

So client SHOULD request roster and send initial presence without
waiting for the roster to came.


> To rule out several possible corner cases, server MUST always send
> pushes for every changed item, even if there were several changes that
> in fact reverted itself. That means the server MUST NOT send a simple
> difference, but instead MUST send all the items that were modified at
> any point in history.

Right, that's exactly what I called "rsync-way".


-- 
WBRBW, Leonid Evdokimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090418/1cee8f8a/attachment.pgp>

From stpeter at stpeter.im  Fri Apr 17 15:11:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 17 Apr 2009 14:11:31 -0600
Subject: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
In-Reply-To: <49E8E1A9.6060005@darkk.net.ru>
References: <49E4AB23.9000203@stpeter.im>	<49E88FBD.1050804@darkk.net.ru>	<49E8A6F6.8090605@stpeter.im>	<49E8BEF8.20700@stpeter.im>	<e962983d0904171051y4847530fw9b2f939d371d0413@mail.gmail.com>	<49E8C1F5.8010809@stpeter.im>	<e962983d0904171055t3f4da0a5ye57633f199c3457c@mail.gmail.com>	<49E8C300.3080101@stpeter.im>	<e962983d0904171059g17766197nd1a8b1ea79861fdd@mail.gmail.com>	<49E8C4A4.9080405@stpeter.im>	<e962983d0904171115x5f8962e2jfd9fe74ab504739@mail.gmail.com>
	<49E8E1A9.6060005@darkk.net.ru>
Message-ID: <49E8E273.8010601@stpeter.im>

On 4/17/09 2:08 PM, Leonid Evdokimov wrote:
> Ji?? Z?rev?ck? wrote:
>> Example 4. Roster result with no content
>>
>> <iq from='romeo at montague.lit' id='r1' to='romeo at montague.lit/home'
>> type='result' />
>>
>> Example 5. Server sends any changes since the clients state as ordinary pushes
>>
>> <iq from='romeo at montague.lit' id='p1' to='romeo at montague.lit/home' type='set'>
>>   <query xmlns='jabber:iq:roster' ver='313'>
>>     <item jid='shylock at shakespeare.lit' subscription='remove'/>
>>   </query>
>> </iq>
>>
>> <iq from='romeo at montague.lit' id='p2' to='romeo at montague.lit/home' type='set'>
>>   <query xmlns='jabber:iq:roster' ver='317'>
>>     <item jid='bill at shakespeare.lit' subscription='both'/>
>>   </query>
>> </iq>
>>
>>
>> The client can't figure out which push is the last change, but that
>> doesn't matter, since all pushes are atomic.

Right.

> ?Example 2. Roster result (unchanged)? equals ?Example 4. Roster result
> with no content?. Yes, I understand that it's ok to send same reply in
> both cases as it has following semantics: ?roster updates (if any) will
> be sent as subsequent roster pushes?.
> 
> The client can't figure out which push is the last change, so it can't
> send initial presence after receiving up-to-date roster as client never
> knows if it is up-to-date. I don't know if that really matters, but that
> interferes a bit with RFC3921:
> 
> | 7.3.  Retrieving One's Roster on Login
> |
> | Upon connecting to the server and becoming an active resource, a
> | client SHOULD request the roster before sending initial presence
> | (however, because receiving the roster may not be desirable for all
> | resources, e.g., a connection with limited bandwidth, the client's
> | request for the roster is OPTIONAL).
> 
> So client SHOULD request roster and send initial presence without
> waiting for the roster to came.

Yes, same as it has always been (at least since I've been involved in
the Jabber/XMPP community!).

>> To rule out several possible corner cases, server MUST always send
>> pushes for every changed item, even if there were several changes that
>> in fact reverted itself. That means the server MUST NOT send a simple
>> difference, but instead MUST send all the items that were modified at
>> any point in history.
> 
> Right, that's exactly what I called "rsync-way".

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090417/44522158/attachment.bin>

From editor at xmpp.org  Fri Apr 17 16:03:57 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Fri, 17 Apr 2009 16:03:57 -0500
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
Message-ID: <E1LuvE5-0003v3-00@apollo>

Version 0.7 of XEP-0237 (Roster Versioning) has been released.

Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not changed, thus saving bandwidth during session establishment.

Changelog: Modified the underlying model per list consensus; added more detailed scenarios to illustrate usage. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0237.xml?%40diffMode=u&%40diffWrap=s&r1=2936&r2=3055&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0237.html


From mwild1 at gmail.com  Fri Apr 17 22:49:06 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Sat, 18 Apr 2009 04:49:06 +0100
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <E1LuvE5-0003v3-00@apollo>
References: <E1LuvE5-0003v3-00@apollo>
Message-ID: <4db9cacb0904172049y37a40761red1d34af75d87288@mail.gmail.com>

On Fri, Apr 17, 2009 at 10:03 PM, XMPP Extensions Editor
<editor at xmpp.org> wrote:
> Version 0.7 of XEP-0237 (Roster Versioning) has been released.

Just gave it a read through. I'm happy :)

Thanks!
Matthew

From stpeter at stpeter.im  Sat Apr 18 16:49:14 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sat, 18 Apr 2009 15:49:14 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <4db9cacb0904172049y37a40761red1d34af75d87288@mail.gmail.com>
References: <E1LuvE5-0003v3-00@apollo>
	<4db9cacb0904172049y37a40761red1d34af75d87288@mail.gmail.com>
Message-ID: <49EA4ADA.6050103@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/17/09 9:49 PM, Matthew Wild wrote:
> On Fri, Apr 17, 2009 at 10:03 PM, XMPP Extensions Editor
> <editor at xmpp.org> wrote:
>> Version 0.7 of XEP-0237 (Roster Versioning) has been released.
> 
> Just gave it a read through. I'm happy :)

Woot!

/psa

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknqStoACgkQNL8k5A2w/vz4XACg7SkZcsuanDuLlPTi82DNleMj
beQAoOuwAH/U1eM0YKwyYRqI60GU+YX2
=yHAD
-----END PGP SIGNATURE-----

From vincent.barat at ubikod.com  Mon Apr 20 04:00:33 2009
From: vincent.barat at ubikod.com (Vincent BARAT)
Date: Mon, 20 Apr 2009 11:00:33 +0200
Subject: [Standards] How to handle send_last_published_items /
 on_sub_and_presence for PEP nodes?
Message-ID: <49EC39B1.1070909@ubikod.com>

Hello,

It appears that the specification of the handling of the 
send_last_published_items / on_sub_and_presence option (default 
option) on PEP nodes is not clear: people understand it in different 
ways.

To clarify, I have one simple question:

When a user become available, should he receive the last items 
published on all PEP nodes belonging to ALL of his contacts 
(provided he asked for them through his caps) or should he receive 
the last items published on all PEP nodes belonging to his CURRENTLY 
ONLINE contacts only?

Thanks to clarify.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vincent_barat.vcf
Type: text/x-vcard
Size: 347 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090420/21c8c1f0/attachment.vcf>

From dave at cridland.net  Mon Apr 20 05:56:19 2009
From: dave at cridland.net (Dave Cridland)
Date: Mon, 20 Apr 2009 11:56:19 +0100
Subject: [Standards] How to handle send_last_published_items /
 on_sub_and_presence for PEP nodes?
In-Reply-To: <49EC39B1.1070909@ubikod.com>
References: <49EC39B1.1070909@ubikod.com>
Message-ID: <25456.1240224979.384542@puncture>

On Mon Apr 20 10:00:33 2009, Vincent BARAT wrote:
> It appears that the specification of the handling of the  
> send_last_published_items / on_sub_and_presence option (default  
> option) on PEP nodes is not clear: people understand it in  
> different ways.
> 
> 
Coincidentally, I noticed this the other day while testing some PEP  
edge cases in our server, too.

> When a user become available, should he receive the last items  
> published on all PEP nodes belonging to ALL of his contacts  
> (provided he asked for them through his caps) or should he receive  
> the last items published on all PEP nodes belonging to his  
> CURRENTLY ONLINE contacts only?

There's also a related issue. Gajim, at least, ignores PEP events for  
offline contacts. Foolish Gajim, because if the answer is "ALL", then  
it won't get a new event when the contact comes online - unless,  
mind, a contact coming online itself causes a rebroadcast of the last  
event. So, should a last_published rebroadcast happen when a resource  
for an account comes online, and (optionally) this is the only such  
resource?

FWIW, I looked through XEP-0060 section 9, and concluded that the  
correct behaviour appears to be:

a) ALL contacts have a PEP service, which will send out last  
published events, whether or not the owner of that service is online  
or not.

b) There is no mention of any resending of last events for when the  
owner comes online.

However, Gajim (at least, and possibly other clients) appear to rely  
on different behaviour.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Mon Apr 20 06:16:00 2009
From: dave at cridland.net (Dave Cridland)
Date: Mon, 20 Apr 2009 12:16:00 +0100
Subject: [Standards] XEP-0060
Message-ID: <25456.1240226160.239319@puncture>

I noticed there's been some activity on XEP-0060, so here's a minor  
niggle to consider:

The second pargraph of Section 9 reads:

Note: Because the account owner's bare JID functions as a virtual  
pubsub service, it is OPTIONAL for the owner to include a 'to'  
address when sending publish requests and completing other publisher  
and owner use cases. That is, when the IM server receives a  
pubsub-related IQ stanza of type "get" or "set" from one of the  
account owner's resources, the server MUST consider the stanza to be  
addressed to the account owner's bare JID even if the IQ stanza does  
not include a 'to' address.

I've a couple of problems with this.

1) It's respecifying the base spec. Normative language about a  
particular issue needs to be only in one place, to avoid any possible  
confusion over which specification is normative on the issue.

2) It's confusing, as it refers to "a pubsub-related IQ stanzas of  
type [...]" whereas any C2S stanza, at all, with no to attribute has  
a default destination of the bare jid.

Can we replace this with something that sounds more advisory, such as:

Note: Because the account owner's bare jid is the default destination  
address, clients typically omit the "to" attribute on such stanzas;  
see RFC 3921.

What a lot of words I've written for something so small. :-)

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From vincent.barat at ubikod.com  Mon Apr 20 06:37:01 2009
From: vincent.barat at ubikod.com (Vincent BARAT)
Date: Mon, 20 Apr 2009 13:37:01 +0200
Subject: [Standards] How to handle send_last_published_items /
 on_sub_and_presence for PEP nodes?
In-Reply-To: <25456.1240224979.384542@puncture>
References: <49EC39B1.1070909@ubikod.com> <25456.1240224979.384542@puncture>
Message-ID: <49EC5E5D.9000205@ubikod.com>

I fully agree. That's also my conclusion.

Dave Cridland a ?crit :

> FWIW, I looked through XEP-0060 section 9, and concluded that the 
> correct behaviour appears to be:
> 
> a) ALL contacts have a PEP service, which will send out last published 
> events, whether or not the owner of that service is online or not.
> 
> b) There is no mention of any resending of last events for when the 
> owner comes online.
> 
> However, Gajim (at least, and possibly other clients) appear to rely on 
> different behaviour.
> 
> Dave.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vincent_barat.vcf
Type: text/x-vcard
Size: 334 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090420/fafcd9d2/attachment.vcf>

From js-xmpp-standards at webkeks.org  Mon Apr 20 06:43:02 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Mon, 20 Apr 2009 13:43:02 +0200
Subject: [Standards] How to handle send_last_published_items /
	on_sub_and_presence for PEP nodes?
In-Reply-To: <25456.1240224979.384542@puncture>
References: <49EC39B1.1070909@ubikod.com> <25456.1240224979.384542@puncture>
Message-ID: <E642BE76-CEE6-4826-A8DA-19718788121D@webkeks.org>

Wouldn't make it more sense to only get the PEP events of users who  
are online and get the last event of a user as soon as he signs in?  
IMO, this would make more sense and this is also how ejabberd handles  
it.

--
Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 801 bytes
Desc: Signierter Teil der Nachricht
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090420/397acef6/attachment.pgp>

From dave at cridland.net  Mon Apr 20 07:04:23 2009
From: dave at cridland.net (Dave Cridland)
Date: Mon, 20 Apr 2009 13:04:23 +0100
Subject: [Standards] How to handle send_last_published_items /
 on_sub_and_presence for PEP nodes?
In-Reply-To: <E642BE76-CEE6-4826-A8DA-19718788121D@webkeks.org>
References: <49EC39B1.1070909@ubikod.com> <25456.1240224979.384542@puncture>
	<E642BE76-CEE6-4826-A8DA-19718788121D@webkeks.org>
Message-ID: <25456.1240229063.684086@puncture>

On Mon Apr 20 12:43:02 2009, Jonathan Schleifer wrote:
> Wouldn't make it more sense to only get the PEP events of users who  
>  are online and get the last event of a user as soon as he signs  
> in?  IMO, this would make more sense and this is also how ejabberd  
> handles  it.

Well, no, not really.

Lots of "rich presence" states persist even when the user is offline.  
The <status/> field, for instance, we can even set *when* we go  
offline, and lots of clients (include Gajim) can make use of this. If  
I go offline so I can, for example, play games, or because I've gone  
on holiday, I think that my contacts should get the backdated PEP  
event telling them so when I'm offline.

And plenty of PEP items unrelated to online/offline state exist, too,  
so to limit PEP to only cases when the contacts are online is simply  
broken.

So again, I'd say:

1) The spec says that you get PEP events for ALL contacts, online or  
not.

2) The spec doesn't say you get events for newly online contacts.

3) Some client mistakenly rely on odd server behaviour, particular in  
the case of (2).

4) (1) and (2) are not only what the specification says, but also the  
desired behaviour.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From vincent.barat at ubikod.com  Mon Apr 20 07:04:50 2009
From: vincent.barat at ubikod.com (Vincent BARAT)
Date: Mon, 20 Apr 2009 14:04:50 +0200
Subject: [Standards] How to handle send_last_published_items
 /	on_sub_and_presence for PEP nodes?
In-Reply-To: <E642BE76-CEE6-4826-A8DA-19718788121D@webkeks.org>
References: <49EC39B1.1070909@ubikod.com> <25456.1240224979.384542@puncture>
	<E642BE76-CEE6-4826-A8DA-19718788121D@webkeks.org>
Message-ID: <49EC64E2.40205@ubikod.com>

This is the point: ejabberd has changed its way of handling this 
(2.0.2 was doing right), and my guess is that this is not compliant 
to the specification.

Furthermore, our BuddyMob service makes a big use of this (for 
example to get the last known geoloc of offline contacts).

This also means that you never get the avatar of your offline 
contacts (as long as they stay offline).

Jonathan Schleifer a ?crit :
> Wouldn't make it more sense to only get the PEP events of users who are 
> online and get the last event of a user as soon as he signs in? IMO, 
> this would make more sense and this is also how ejabberd handles it.
> 
> -- 
> Jonathan
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vincent_barat.vcf
Type: text/x-vcard
Size: 334 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090420/ddaf1301/attachment.vcf>

From js-xmpp-standards at webkeks.org  Mon Apr 20 07:34:36 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Mon, 20 Apr 2009 14:34:36 +0200
Subject: [Standards] How to handle send_last_published_items /
	on_sub_and_presence for PEP nodes?
In-Reply-To: <25456.1240229063.684086@puncture>
References: <49EC39B1.1070909@ubikod.com> <25456.1240224979.384542@puncture>
	<E642BE76-CEE6-4826-A8DA-19718788121D@webkeks.org>
	<25456.1240229063.684086@puncture>
Message-ID: <5337CB98-8ACE-4463-A30F-5550FAC0D144@webkeks.org>

Am 20.04.2009 um 14:04 schrieb Dave Cridland:

> Lots of "rich presence" states persist even when the user is  
> offline. The <status/> field, for instance, we can even set *when*  
> we go offline, and lots of clients (include Gajim) can make use of  
> this. If I go offline so I can, for example, play games, or because  
> I've gone on holiday, I think that my contacts should get the  
> backdated PEP event telling them so when I'm offline.

Makes sense.

> And plenty of PEP items unrelated to online/offline state exist,  
> too, so to limit PEP to only cases when the contacts are online is  
> simply broken.
>
> So again, I'd say:
>
> 1) The spec says that you get PEP events for ALL contacts, online or  
> not.
>
> 2) The spec doesn't say you get events for newly online contacts.
>
> 3) Some client mistakenly rely on odd server behaviour, particular  
> in the case of (2).

We remove the PEP event when a user signs off because it would be  
inconsistent to what you'd get when you sign in again. You wouldn't  
get the PEP events of offline users then. But as we cleared now that  
this is an ejabberd bug, I'm happy to change that once ejabberd is  
fixed.

> 4) (1) and (2) are not only what the specification says, but also  
> the desired behaviour.

--
Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 801 bytes
Desc: Signierter Teil der Nachricht
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090420/062a3722/attachment.pgp>

From stpeter at stpeter.im  Mon Apr 20 09:05:05 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 20 Apr 2009 08:05:05 -0600
Subject: [Standards] How to handle send_last_published_items /
 on_sub_and_presence for PEP nodes?
In-Reply-To: <25456.1240229063.684086@puncture>
References: <49EC39B1.1070909@ubikod.com>
	<25456.1240224979.384542@puncture>	<E642BE76-CEE6-4826-A8DA-19718788121D@webkeks.org>
	<25456.1240229063.684086@puncture>
Message-ID: <49EC8111.4070607@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/20/09 6:04 AM, Dave Cridland wrote:
> On Mon Apr 20 12:43:02 2009, Jonathan Schleifer wrote:
>> Wouldn't make it more sense to only get the PEP events of users who
>>  are online and get the last event of a user as soon as he signs in? 
>> IMO, this would make more sense and this is also how ejabberd handles 
>> it.
> 
> Well, no, not really.
> 
> Lots of "rich presence" states persist even when the user is offline.
> The <status/> field, for instance, we can even set *when* we go offline,
> and lots of clients (include Gajim) can make use of this. If I go
> offline so I can, for example, play games, or because I've gone on
> holiday, I think that my contacts should get the backdated PEP event
> telling them so when I'm offline.
> 
> And plenty of PEP items unrelated to online/offline state exist, too, so
> to limit PEP to only cases when the contacts are online is simply broken.

Right. The on_sub_and_presence setting relates to the *subscriber's*
presence, not the *publisher's* presence.

> So again, I'd say:
> 
> 1) The spec says that you get PEP events for ALL contacts, online or not.
> 
> 2) The spec doesn't say you get events for newly online contacts.

Which is consistent with the meaning of on_sub_and_presence. I'll
clarify this point further in XEP-0060 and XEP-0163.

/psa

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknsgREACgkQNL8k5A2w/vw5cQCgorITHZydzmOY+HvgYIPQs/Wj
c/kAn1pcNpsJFmmaWBsY+xKtE4d3NJDT
=O9vV
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Mon Apr 20 09:09:42 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 20 Apr 2009 08:09:42 -0600
Subject: [Standards] XEP-0060
In-Reply-To: <25456.1240226160.239319@puncture>
References: <25456.1240226160.239319@puncture>
Message-ID: <49EC8226.1000206@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/20/09 5:16 AM, Dave Cridland wrote:
> I noticed there's been some activity on XEP-0060, 

As I previously noted, I am sending all posts about this to the
pubsub at xmpp.org list. Once I have finished processing all of the bug
reports I've received over the past 6 months (I've now done so through
sometime in February), I will send out a message to both pubsub@ and
standards@ about the fixes.

> so here's a minor
> niggle to consider:
> 
> The second pargraph of Section 9 reads:
> 
> Note: Because the account owner's bare JID functions as a virtual pubsub
> service, it is OPTIONAL for the owner to include a 'to' address when
> sending publish requests and completing other publisher and owner use
> cases. That is, when the IM server receives a pubsub-related IQ stanza
> of type "get" or "set" from one of the account owner's resources, the
> server MUST consider the stanza to be addressed to the account owner's
> bare JID even if the IQ stanza does not include a 'to' address.

First of all, this "implicit to" functionality has been made more
explicit in rfc3920bis/rfc3921bis, and that is where it needs to be
defined. So I think it needs to be deleted here.

> I've a couple of problems with this.
> 
> 1) It's respecifying the base spec. Normative language about a
> particular issue needs to be only in one place, to avoid any possible
> confusion over which specification is normative on the issue.

Right.

> 2) It's confusing, as it refers to "a pubsub-related IQ stanzas of type
> [...]" whereas any C2S stanza, at all, with no to attribute has a
> default destination of the bare jid.
> 
> Can we replace this with something that sounds more advisory, such as:
> 
> Note: Because the account owner's bare jid is the default destination
> address, clients typically omit the "to" attribute on such stanzas; see
> RFC 3921.
> 
> What a lot of words I've written for something so small. :-)

But it's good to be clear on this kind of thing. Thanks.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknsgiYACgkQNL8k5A2w/vzQxgCeMRBt5g5SoAPMhWMun2fuoLk+
5MwAoOE3D243SncfhMoK6OflDCJFDHOm
=CUjF
-----END PGP SIGNATURE-----

From editor at xmpp.org  Mon Apr 20 12:04:39 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Mon, 20 Apr 2009 12:04:39 -0500
Subject: [Standards] UPDATED: XEP-0166 (Jingle)
Message-ID: <E1Lvwv9-0001vw-00@apollo>

Version 0.37 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 pluggable model that enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat, file transfer) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).

Changelog: Specified tie-breaking for session-initiate action; incremented errors namespace to match core namespace; clarified some ambiguities in the text, examples, and state machine. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0166.xml?%40diffMode=u&%40diffWrap=s&r1=2870&r2=3058&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0166.html


From editor at xmpp.org  Mon Apr 20 20:47:39 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Mon, 20 Apr 2009 20:47:39 -0500
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
Message-ID: <E1Lw55H-00062q-00@apollo>

Version 0.8 of XEP-0237 (Roster Versioning) has been released.

Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not changed, thus saving bandwidth during session establishment.

Changelog: Defined schema for stream feature; adjusted some wording for improved clarity. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0237.xml?%40diffMode=u&%40diffWrap=s&r1=3055&r2=3061&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0237.html


From dave at cridland.net  Tue Apr 21 08:07:59 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 21 Apr 2009 14:07:59 +0100
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <E1LuvE5-0003v3-00@apollo>
References: <E1LuvE5-0003v3-00@apollo>
Message-ID: <6293.1240319279.632312@puncture>

On Fri Apr 17 22:03:57 2009, XMPP Extensions Editor wrote:
> Version 0.7 of XEP-0237 (Roster Versioning) has been released.

A couple of minor points.

1) Roster pushes sent by the server MUST be sent in order of the ver  
attribute.

There's a whole horrible mess that occurs if any pushes are sent out  
of order, so we'd need an alternate mechanism to signal "You have  
received all pushes up to and including this sequence point".

I'm equally happy to have that distinct signal, and I'd be interested  
particular by implementors of clustered servers on whether this would  
be useful, as sending pushes out of sequence may reduce  
synchronization between cluster nodes.

An example of a protocol doing this is ACAP, RFC 2244, which contains  
an earlier form of the CONDSTORE pattern we've stolen from RFC 4551.  
(See the UPDATECONTEXT command and the untagged MODTIME response).

2) There are cases where the sequence numbering can be known to have  
broken, for example, if the account is destroyed and recreated, or in  
the case of detectable data loss.

In these instances, a client may ask for an old sequence number which  
is in fact from a previous regime, meaning it will remain out of sync.

This is not always a soluble problem - there are cases where the data  
loss event is undetectable - if this is known to often be the case,  
I'd advise avoiding the specification entirely.

But for those cases where it's possible to detect a data loss event,  
it may be useful to signal the sequence regime change.

RFC 2244 provides no such mechanism - this isn't a tremendously good  
thing, but it's hard to say how this affects real-world usage, given  
there's only one ACAP server in existence, and I'm the only one who  
uses it.

RFC 4551 does, obliquely, because the UIDVALIDITY of an IMAP mailbox  
controls the validity of the entire mailbox, including the MODSEQ  
values (as well as all content). It's my impression that many  
existing mail clients ignore this value, and don't suffer much as a  
result.

We can either provide some similar mechanism, or we can advise  
implementors of the risk, and advise them to have an option somewhere  
to "blow away the cache".

3) We borrow text from RFC 4551, which has IPR implications. To the  
best of my knowledge, the text was written by Alexey Melnikov, and as  
such, the copyright is owned by Isode Ltd, and Isode's default policy  
WRT SDOs applies - ie, Isode will grant whatever permission, license,  
disclaimer, or assignment is required.

I'll try to remember to ask Alexey for confirmation next Monday, when  
he's back from holidays.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Tue Apr 21 08:53:27 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 07:53:27 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <6293.1240319279.632312@puncture>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
Message-ID: <49EDCFD7.5080406@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 7:07 AM, Dave Cridland wrote:
> On Fri Apr 17 22:03:57 2009, XMPP Extensions Editor wrote:
>> Version 0.7 of XEP-0237 (Roster Versioning) has been released.
> 
> A couple of minor points.
> 
> 1) Roster pushes sent by the server MUST be sent in order of the ver
> attribute.

I think we already say this:

"When roster versioning is enabled, the server MUST include the updated
roster sequence number with each roster push. Roster pushes MUST occur
in sequence order and the sequence number contained in a roster push
MUST be unique."

> 2) There are cases where the sequence numbering can be known to have
> broken, for example, if the account is destroyed and recreated, or in
> the case of detectable data loss.
> 
> In these instances, a client may ask for an old sequence number which is
> in fact from a previous regime, meaning it will remain out of sync.
> 
> This is not always a soluble problem - there are cases where the data
> loss event is undetectable - if this is known to often be the case, I'd
> advise avoiding the specification entirely.
> 
> But for those cases where it's possible to detect a data loss event, it
> may be useful to signal the sequence regime change.
> 
> RFC 2244 provides no such mechanism - this isn't a tremendously good
> thing, but it's hard to say how this affects real-world usage, given
> there's only one ACAP server in existence, and I'm the only one who uses
> it.
> 
> RFC 4551 does, obliquely, because the UIDVALIDITY of an IMAP mailbox
> controls the validity of the entire mailbox, including the MODSEQ values
> (as well as all content). It's my impression that many existing mail
> clients ignore this value, and don't suffer much as a result.
> 
> We can either provide some similar mechanism, or we can advise
> implementors of the risk, and advise them to have an option somewhere to
> "blow away the cache".

I think that in our context blowing away the cache would mean setting
ver='0' on a roster get. It's not clear to me what our cases of
detectable data loss are (and how the client would detect it). In the
case of the account being destroyed and re-created, or of the server
simply losing its knowledge of the sequencing because of a catastrophic
failure, perhaps the server could return ver='0' on a roster result?

> 3) We borrow text from RFC 4551, which has IPR implications. 

I think that we borrow a concept from 4551 but perhaps not exact text.
I'll check on that.

> To the best
> of my knowledge, the text was written by Alexey Melnikov, and as such,
> the copyright is owned by Isode Ltd, 

IANAL but the Copyright Notice on RFC 4551 says:

   Copyright (C) The Internet Society (2006).

> and Isode's default policy WRT SDOs
> applies - ie, Isode will grant whatever permission, license, disclaimer,
> or assignment is required.

OK, great.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkntz9cACgkQNL8k5A2w/vzGpwCcC2eTlogR4akrZzvagoLstXp0
N74AoLVTl6OqQNG4rasOz/Ywbk+DLxZd
=aI6J
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 21 09:47:16 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 08:47:16 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EDCFD7.5080406@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
	<49EDCFD7.5080406@stpeter.im>
Message-ID: <49EDDC74.2030308@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 7:53 AM, Peter Saint-Andre wrote:
> On 4/21/09 7:07 AM, Dave Cridland wrote:
>
>> 3) We borrow text from RFC 4551, which has IPR implications. 
> 
> I think that we borrow a concept from 4551 but perhaps not exact text.
> I'll check on that.

RFC 4551 defines CONDSTORE as follows:

   An IMAP server that supports this extension MUST associate a positive
   unsigned 64-bit value called a modification sequence (mod-sequence)
   with every IMAP message.  This is an opaque value updated by the
   server whenever a metadata item is modified.  The server MUST
   guarantee that each STORE command performed on the same mailbox
   (including simultaneous stores to different metadata items from
   different connections) will get a different mod-sequence value.
   Also, for any two successful STORE operations performed in the same
   session on the same mailbox, the mod-sequence of the second completed
   operation MUST be greater than the mod-sequence of the first
   completed.  Note that the latter rule disallows the use of the system
   clock as a mod-sequence, because if system time changes (e.g., an NTP
   [NTP] client adjusting the time), the next generated value might be
   less than the previous one.

XEP-0237 defines 'ver' as follows:

   The 'ver' attribute is a strictly increasing sequence number that
   is increased (but not necessarily incremented-by-one) with any
   modification to the roster data. The value of the attribute MUST be
   a non-negative 64-bit integer, MUST be changed only by the server,
   and MUST be treated by the client as opaque. The server MUST ensure
   that each change to the roster data will result in a different
   sequence number and that the sequence number associated with a given
   roster modification will be greater than the sequence number
   associated with any previous roster modification. (Note: This rule
   effectively disallows the use of the system clock as a sequence
   number, since if the system time changes, e.g. because of an
   adjustment based on an NTP update (see RFC 958 [4]), the next
   generated value might be less than the previous one.)

The borrowed text (as opposed to reformulated concept) is the
informational note about the the definition of 'ver' disallowing the use
of the system clock as a sequence number. I'd be just as happy to remove
that note entirely or to reword it in order to avoid any possible IPR
issues.

On a separate note, the phrase "any previous roster modification" might
be problematic (what if the server needs to reset the sequence number
back to zero?). I propose that we change it to "any previous roster
modification for this session" (where the definition of a session is
borrowed from RFC 3921 / rfc3921bis).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknt3HQACgkQNL8k5A2w/vzDIgCgx6nSupMMVSqgBwjlsHUP2Y3I
woAAnA7gALSMaHyHqNRIvYakAPRUCPcp
=ubVs
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Tue Apr 21 10:04:24 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 09:04:24 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EDDC74.2030308@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo>
	<6293.1240319279.632312@puncture>	<49EDCFD7.5080406@stpeter.im>
	<49EDDC74.2030308@stpeter.im>
Message-ID: <49EDE078.3040802@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 8:47 AM, Peter Saint-Andre wrote:
> On 4/21/09 7:53 AM, Peter Saint-Andre wrote:
>> On 4/21/09 7:07 AM, Dave Cridland wrote:
> 
>>> 3) We borrow text from RFC 4551, which has IPR implications. 
>> I think that we borrow a concept from 4551 but perhaps not exact text.
>> I'll check on that.
> 
> RFC 4551 defines CONDSTORE as follows:
> 
>    An IMAP server that supports this extension MUST associate a positive
>    unsigned 64-bit value called a modification sequence (mod-sequence)
>    with every IMAP message.  This is an opaque value updated by the
>    server whenever a metadata item is modified.  The server MUST
>    guarantee that each STORE command performed on the same mailbox
>    (including simultaneous stores to different metadata items from
>    different connections) will get a different mod-sequence value.
>    Also, for any two successful STORE operations performed in the same
>    session on the same mailbox, the mod-sequence of the second completed
>    operation MUST be greater than the mod-sequence of the first
>    completed.  Note that the latter rule disallows the use of the system
>    clock as a mod-sequence, because if system time changes (e.g., an NTP
>    [NTP] client adjusting the time), the next generated value might be
>    less than the previous one.
> 
> XEP-0237 defines 'ver' as follows:
> 
>    The 'ver' attribute is a strictly increasing sequence number that
>    is increased (but not necessarily incremented-by-one) with any
>    modification to the roster data. The value of the attribute MUST be
>    a non-negative 64-bit integer, MUST be changed only by the server,
>    and MUST be treated by the client as opaque. The server MUST ensure
>    that each change to the roster data will result in a different
>    sequence number and that the sequence number associated with a given
>    roster modification will be greater than the sequence number
>    associated with any previous roster modification. (Note: This rule
>    effectively disallows the use of the system clock as a sequence
>    number, since if the system time changes, e.g. because of an
>    adjustment based on an NTP update (see RFC 958 [4]), the next
>    generated value might be less than the previous one.)
> 
> The borrowed text (as opposed to reformulated concept) is the
> informational note about the the definition of 'ver' disallowing the use
> of the system clock as a sequence number. I'd be just as happy to remove
> that note entirely or to reword it in order to avoid any possible IPR
> issues.

I propose that we add an implementation note that reads as follows (this
really doesn't belong in the definition of the 'ver' attribute):

   An XMPP server cannot guarantee that a timestamp will be strictly
   increasing (e.g., the system time might change because of an
   adjustment based on an update triggered by the user of the Network
   Time Protocol (RFC 958 [4]); therefore, because the 'ver' attribute
   is defined as a strictly increasing sequence number, server
   implementations are advised to employ a method other than timestamps
   for generation of the 'ver' attribute.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknt4HgACgkQNL8k5A2w/vzf5wCfV+Hr7ywqB8ye7xN3IQh41y/c
obsAn2gG3o0lTj6ygFkmeQ+6RZrOKfwL
=LIMy
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 21 10:05:28 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 09:05:28 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EDCFD7.5080406@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
	<49EDCFD7.5080406@stpeter.im>
Message-ID: <49EDE0B8.20006@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 7:53 AM, Peter Saint-Andre wrote:
> On 4/21/09 7:07 AM, Dave Cridland wrote:
>> On Fri Apr 17 22:03:57 2009, XMPP Extensions Editor wrote:
> 
>> 2) There are cases where the sequence numbering can be known to have
>> broken, for example, if the account is destroyed and recreated, or in
>> the case of detectable data loss.
> 
>> In these instances, a client may ask for an old sequence number which is
>> in fact from a previous regime, meaning it will remain out of sync.
> 
>> This is not always a soluble problem - there are cases where the data
>> loss event is undetectable - if this is known to often be the case, I'd
>> advise avoiding the specification entirely.
> 
>> But for those cases where it's possible to detect a data loss event, it
>> may be useful to signal the sequence regime change.
> 
>> RFC 2244 provides no such mechanism - this isn't a tremendously good
>> thing, but it's hard to say how this affects real-world usage, given
>> there's only one ACAP server in existence, and I'm the only one who uses
>> it.
> 
>> RFC 4551 does, obliquely, because the UIDVALIDITY of an IMAP mailbox
>> controls the validity of the entire mailbox, including the MODSEQ values
>> (as well as all content). It's my impression that many existing mail
>> clients ignore this value, and don't suffer much as a result.
> 
>> We can either provide some similar mechanism, or we can advise
>> implementors of the risk, and advise them to have an option somewhere to
>> "blow away the cache".
> 
> I think that in our context blowing away the cache would mean setting
> ver='0' on a roster get. It's not clear to me what our cases of
> detectable data loss are (and how the client would detect it). In the
> case of the account being destroyed and re-created, or of the server
> simply losing its knowledge of the sequencing because of a catastrophic
> failure, perhaps the server could return ver='0' on a roster result?

I propose the following implementation note:

   In some conditions, an XMPP client or server might know that the
   sequence numbering is invalid (e.g., because of a catastrophic server
   failure). In these cases, the entity that discovers the problem
   SHOULD return a roster version of zero (in the case of the server) or
   request a roster version of zero (in the case of the client).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknt4LcACgkQNL8k5A2w/vwB/gCgsCBH5LyCVPn1FrweZqMb1mdq
ZpQAn3rEbrMcriqPzm7IhyHM2jhTJNxG
=qObE
-----END PGP SIGNATURE-----

From zarevucky.jiri at gmail.com  Tue Apr 21 13:57:25 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 21 Apr 2009 20:57:25 +0200
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EDE0B8.20006@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
	<49EDCFD7.5080406@stpeter.im> <49EDE0B8.20006@stpeter.im>
Message-ID: <e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>

2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
> I propose the following implementation note:
>
> ? In some conditions, an XMPP client or server might know that the
> ? sequence numbering is invalid (e.g., because of a catastrophic server
> ? failure). In these cases, the entity that discovers the problem
> ? SHOULD return a roster version of zero (in the case of the server) or
> ? request a roster version of zero (in the case of the client).
>
> Peter
>

That doesn't seem very clear to me. And what if the roster was already
modified with another client? I think that better formulation would be
something like:

   If client announces it's version number to be bigger than the
version of currently server-side stored roster (for example because a
catastrophic server failure erased all roster information), the server
MUST return the whole current roster as if client announced it's
version to be zero, thus bootstrapping client's local cache.

The local corrupted cache scenario is already in the spec (under
request example). No need to include it again.

From stpeter at stpeter.im  Tue Apr 21 14:08:18 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 13:08:18 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>
References: <E1LuvE5-0003v3-00@apollo>
	<6293.1240319279.632312@puncture>	<49EDCFD7.5080406@stpeter.im>
	<49EDE0B8.20006@stpeter.im>
	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>
Message-ID: <49EE19A2.7040104@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 12:57 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
>> I propose the following implementation note:
>>
>>   In some conditions, an XMPP client or server might know that the
>>   sequence numbering is invalid (e.g., because of a catastrophic server
>>   failure). In these cases, the entity that discovers the problem
>>   SHOULD return a roster version of zero (in the case of the server) or
>>   request a roster version of zero (in the case of the client).
>>
>> Peter
>>
> 
> That doesn't seem very clear to me. And what if the roster was already
> modified with another client? I think that better formulation would be
> something like:
> 
>    If client announces it's version number to be bigger than the
> version of currently server-side stored roster (for example because a
> catastrophic server failure erased all roster information), the server
> MUST return the whole current roster as if client announced it's
> version to be zero, thus bootstrapping client's local cache.

Something like that is good for the case when the client sends a roster
request with a version number greater than what the server has on hand.
But are there other cases of corrupted / invalid sequence numbering on
server side? Or do we say that in such cases the server needs to in
essence reset its sequence number back to zero?

> The local corrupted cache scenario is already in the spec (under
> request example). No need to include it again.

Good point.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknuGaIACgkQNL8k5A2w/vwEnQCgzxKvgn5d6zSH4yXEZabQczRG
eAgAnRb+fhfG3nOeh/qbODoX0aIKZWiZ
=pwq3
-----END PGP SIGNATURE-----

From zarevucky.jiri at gmail.com  Tue Apr 21 15:58:59 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 21 Apr 2009 22:58:59 +0200
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EE19A2.7040104@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
	<49EDCFD7.5080406@stpeter.im> <49EDE0B8.20006@stpeter.im>
	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>
	<49EE19A2.7040104@stpeter.im>
Message-ID: <e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>

2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 4/21/09 12:57 PM, Ji?? Z?rev?ck? wrote:
>> 2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
>>> I propose the following implementation note:
>>>
>>> ? In some conditions, an XMPP client or server might know that the
>>> ? sequence numbering is invalid (e.g., because of a catastrophic server
>>> ? failure). In these cases, the entity that discovers the problem
>>> ? SHOULD return a roster version of zero (in the case of the server) or
>>> ? request a roster version of zero (in the case of the client).
>>>
>>> Peter
>>>
>>
>> That doesn't seem very clear to me. And what if the roster was already
>> modified with another client? I think that better formulation would be
>> something like:
>>
>> ? ?If client announces it's version number to be bigger than the
>> version of currently server-side stored roster (for example because a
>> catastrophic server failure erased all roster information), the server
>> MUST return the whole current roster as if client announced it's
>> version to be zero, thus bootstrapping client's local cache.
>
> Something like that is good for the case when the client sends a roster
> request with a version number greater than what the server has on hand.

That's the general idea.

> But are there other cases of corrupted / invalid sequence numbering on
> server side? Or do we say that in such cases the server needs to in
> essence reset its sequence number back to zero?
>

I the server's database gets corrupted or lost, it doesn't know the
correct roster for that sequence number anyway, so it is pretty
implicit to revert it to the last known uncorrupted version (if any
exists.. backup for example? does not necessarily need to be zero).
But it doesn't hurt to make it explicit, too.


There could be another problem, though. If the roster got reverted,
some client could update it up to the original sequence number or
further. Then if some client that wasn't used for long time came
online, it could receive wrong updates.

Is such scenario worth attention? I don't know how often could
something like that happen. The only way to fix it (I can think of)
would be including some identifier of roster (another number?) that
server would have to reset in case of any failure/reverting. The
client would then send requests based on both roster's ID and sequence
number. But I don't like the idea much.

From stpeter at stpeter.im  Tue Apr 21 17:07:37 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 16:07:37 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>
References: <E1LuvE5-0003v3-00@apollo>
	<6293.1240319279.632312@puncture>	<49EDCFD7.5080406@stpeter.im>
	<49EDE0B8.20006@stpeter.im>	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>	<49EE19A2.7040104@stpeter.im>
	<e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>
Message-ID: <49EE43A9.8000905@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 2:58 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 4/21/09 12:57 PM, Ji?? Z?rev?ck? wrote:
>>> 2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
>>>> I propose the following implementation note:
>>>>
>>>>   In some conditions, an XMPP client or server might know that the
>>>>   sequence numbering is invalid (e.g., because of a catastrophic server
>>>>   failure). In these cases, the entity that discovers the problem
>>>>   SHOULD return a roster version of zero (in the case of the server) or
>>>>   request a roster version of zero (in the case of the client).
>>>>
>>>> Peter
>>>>
>>> That doesn't seem very clear to me. And what if the roster was already
>>> modified with another client? I think that better formulation would be
>>> something like:
>>>
>>>    If client announces it's version number to be bigger than the
>>> version of currently server-side stored roster (for example because a
>>> catastrophic server failure erased all roster information), the server
>>> MUST return the whole current roster as if client announced it's
>>> version to be zero, thus bootstrapping client's local cache.
>> Something like that is good for the case when the client sends a roster
>> request with a version number greater than what the server has on hand.
> 
> That's the general idea.

OK, I will adjust the text a bit further, then.

>> But are there other cases of corrupted / invalid sequence numbering on
>> server side? Or do we say that in such cases the server needs to in
>> essence reset its sequence number back to zero?
>>
> 
> I the server's database gets corrupted or lost, it doesn't know the
> correct roster for that sequence number anyway, so it is pretty
> implicit to revert it to the last known uncorrupted version (if any
> exists.. backup for example? does not necessarily need to be zero).
> But it doesn't hurt to make it explicit, too.
> 
> There could be another problem, though. If the roster got reverted,
> some client could update it up to the original sequence number or
> further. Then if some client that wasn't used for long time came
> online, it could receive wrong updates.

I think it is up to the server to return the complete roster in this case.

> Is such scenario worth attention? I don't know how often could
> something like that happen. The only way to fix it (I can think of)
> would be including some identifier of roster (another number?) that
> server would have to reset in case of any failure/reverting. The
> client would then send requests based on both roster's ID and sequence
> number. But I don't like the idea much.

Yeah, I don't like that, either. Perhaps the solution is to use a better
server. :)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknuQ6kACgkQNL8k5A2w/vxijACg29Q5py/6xqkqrJ5nsBrzi5/t
3w8AniYQzciq9ISL8rgQNrkfNarjw5fJ
=dX4b
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 21 17:27:26 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 16:27:26 -0600
Subject: [Standards] gaming@xmpp.org
Message-ID: <49EE484E.6050105@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've created a new list for discussions related to gaming applications
of XMPP technologies. Subscribe here:

http://mail.jabber.org/mailman/listinfo/gaming

mailto:gaming-subscribe at xmpp.org

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknuSE4ACgkQNL8k5A2w/vzovwCcCwZR92qZi5MgTFfJoDlslHVu
ZmgAnR0hMr8bH3hBL7LEZI3ShR/WzT3j
=9IxI
-----END PGP SIGNATURE-----

From zarevucky.jiri at gmail.com  Tue Apr 21 17:31:28 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 22 Apr 2009 00:31:28 +0200
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EE43A9.8000905@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
	<49EDCFD7.5080406@stpeter.im> <49EDE0B8.20006@stpeter.im>
	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>
	<49EE19A2.7040104@stpeter.im>
	<e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>
	<49EE43A9.8000905@stpeter.im>
Message-ID: <e962983d0904211531s1c92ed33ne8d4abe239b2a515@mail.gmail.com>

2009/4/22 Peter Saint-Andre <stpeter at stpeter.im>:
>>
>> There could be another problem, though. If the roster got reverted,
>> some client could update it up to the original sequence number or
>> further. Then if some client that wasn't used for long time came
>> online, it could receive wrong updates.
>
> I think it is up to the server to return the complete roster in this case.
>

There would be no difference from an ordinary request. In this case
the server has no way of knowing that the client's cache differs from
the real current state.

>
>> Is such scenario worth attention? I don't know how often could
>> something like that happen. The only way to fix it (I can think of)
>> would be including some identifier of roster (another number?) that
>> server would have to reset in case of any failure/reverting. The
>> client would then send requests based on both roster's ID and sequence
>> number. But I don't like the idea much.
>
> Yeah, I don't like that, either. Perhaps the solution is to use a better
> server. :)
>

Well... that's probably truth :) But I don't think something like
fail-proof server really exists... I'll need to think about it
further.

From arcriley at gmail.com  Tue Apr 21 17:52:04 2009
From: arcriley at gmail.com (Arc Riley)
Date: Tue, 21 Apr 2009 18:52:04 -0400
Subject: [Standards] Proposed XMPP Extension: Multi-User Gaming
In-Reply-To: <20090417060310.GA5493@aiken.home.pappanoa.de>
References: <E1LsN5Z-0004AK-00@apollo>
	<bad82a80904151422r6772d0c7sb2a7c3cb698e3944@mail.gmail.com>
	<5975.1239833139.632280@puncture>
	<bad82a80904152006t576113fdt543c0be56cc04dc0@mail.gmail.com>
	<20090417060310.GA5493@aiken.home.pappanoa.de>
Message-ID: <bad82a80904211552i12a8b178v5500acd87b9bcb0f@mail.gmail.com>

> But if several people don't expect that under the title "Multi-User
> Gaming" then we should look for a more appropriate title.


Cool, we're in agreement then.  I think the key point here is to contrast it
with multiuser games where players use XMPP for chat and negotiate server
connections via XMPP Jingle.

Lets move this discussion to the new gaming list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090421/ece6211a/attachment.htm>

From stpeter at stpeter.im  Tue Apr 21 20:21:09 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 19:21:09 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904211531s1c92ed33ne8d4abe239b2a515@mail.gmail.com>
References: <E1LuvE5-0003v3-00@apollo>
	<6293.1240319279.632312@puncture>	<49EDCFD7.5080406@stpeter.im>
	<49EDE0B8.20006@stpeter.im>	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>	<49EE19A2.7040104@stpeter.im>	<e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>	<49EE43A9.8000905@stpeter.im>
	<e962983d0904211531s1c92ed33ne8d4abe239b2a515@mail.gmail.com>
Message-ID: <49EE7105.5000600@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 4:31 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/22 Peter Saint-Andre <stpeter at stpeter.im>:
>>> There could be another problem, though. If the roster got reverted,
>>> some client could update it up to the original sequence number or
>>> further. Then if some client that wasn't used for long time came
>>> online, it could receive wrong updates.
>> I think it is up to the server to return the complete roster in this case.
>>
> 
> There would be no difference from an ordinary request. In this case
> the server has no way of knowing that the client's cache differs from
> the real current state.

We don't design our protocols based on catastrophic software failures.
Maybe the server has an internal flag that anything before version X of
roster Y might be invalid. That's why the server developers get paid
lots of money.

>>> Is such scenario worth attention? I don't know how often could
>>> something like that happen. The only way to fix it (I can think of)
>>> would be including some identifier of roster (another number?) that
>>> server would have to reset in case of any failure/reverting. The
>>> client would then send requests based on both roster's ID and sequence
>>> number. But I don't like the idea much.
>> Yeah, I don't like that, either. Perhaps the solution is to use a better
>> server. :)
>>
> 
> Well... that's probably truth :) But I don't think something like
> fail-proof server really exists... I'll need to think about it
> further.

If the client says it has roster version X and the server returns only a
few roster pushes, which are inconsistent with the roster version that
the human user sees in another client, then perhaps the user suspects
that there is something very wrong and calls the sysadmin. I see this
problem as quite rare. Perhaps we don't need to solve it in our protocol
and instead deal with it at the human layer. Not everything needs a
technical solution.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknucQQACgkQNL8k5A2w/vxcogCg+ptsmND6JxFfD3UAbw4TIaRk
EXUAoPLOqYIEq+NgPDXD9XJ3W108Sibo
=DP0x
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Tue Apr 21 20:34:29 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 19:34:29 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EE43A9.8000905@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo>	<6293.1240319279.632312@puncture>	<49EDCFD7.5080406@stpeter.im>	<49EDE0B8.20006@stpeter.im>	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>	<49EE19A2.7040104@stpeter.im>	<e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>
	<49EE43A9.8000905@stpeter.im>
Message-ID: <49EE7425.5050001@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/21/09 4:07 PM, Peter Saint-Andre wrote:
> On 4/21/09 2:58 PM, JiY? Z?rev?ck? wrote:
>> 2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 4/21/09 12:57 PM, JiY? Z?rev?ck? wrote:
>>>> 2009/4/21 Peter Saint-Andre <stpeter at stpeter.im>:
>>>>> I propose the following implementation note:
>>>>>
>>>>>   In some conditions, an XMPP client or server might know that the
>>>>>   sequence numbering is invalid (e.g., because of a catastrophic server
>>>>>   failure). In these cases, the entity that discovers the problem
>>>>>   SHOULD return a roster version of zero (in the case of the server) or
>>>>>   request a roster version of zero (in the case of the client).
>>>>>
>>>>> Peter
>>>>>
>>>> That doesn't seem very clear to me. And what if the roster was already
>>>> modified with another client? I think that better formulation would be
>>>> something like:
>>>>
>>>>    If client announces it's version number to be bigger than the
>>>> version of currently server-side stored roster (for example because a
>>>> catastrophic server failure erased all roster information), the server
>>>> MUST return the whole current roster as if client announced it's
>>>> version to be zero, thus bootstrapping client's local cache.
>>> Something like that is good for the case when the client sends a roster
>>> request with a version number greater than what the server has on hand.
>> That's the general idea.
> 
> OK, I will adjust the text a bit further, then.

Done. Currently I have this in my working copy:

***

2.3 Server Response

Whether or not the roster has changed since the version enumerated by
the client, the server MUST either return the complete roster as
described in RFC 3921 or return an empty IQ-result (thus indicating that
any roster modifications will be sent via roster pushes, as described
below). In general, unless returning the complete roster would use less
bandwidth than sending individual roster pushes to the client (e.g., if
the roster contains only a few items), the server SHOULD send an empty
IQ-result and then send the modifications (if any) via roster pushes. In
addition, if the client signals a sequence number that is greater than
the sequence number currently on file at the server for that JID, the
server MUST return the whole current roster as if client announced its
version to be zero, thus bootstrapping the client's local cache.

***

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknudCUACgkQNL8k5A2w/vyPYACglqiCfSaCgapClp6P6JzVmR6e
iuIAoPPfOcyMGOR77M7ZifG8qkbNrSQ6
=Ebjh
-----END PGP SIGNATURE-----


From zarevucky.jiri at gmail.com  Wed Apr 22 08:12:56 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 22 Apr 2009 15:12:56 +0200
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EE7105.5000600@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
	<49EDCFD7.5080406@stpeter.im> <49EDE0B8.20006@stpeter.im>
	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>
	<49EE19A2.7040104@stpeter.im>
	<e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>
	<49EE43A9.8000905@stpeter.im>
	<e962983d0904211531s1c92ed33ne8d4abe239b2a515@mail.gmail.com>
	<49EE7105.5000600@stpeter.im>
Message-ID: <e962983d0904220612s777b5923q2dab5480f5550efd@mail.gmail.com>

2009/4/22 Peter Saint-Andre <stpeter at stpeter.im>:
>
> If the client says it has roster version X and the server returns only a
> few roster pushes, which are inconsistent with the roster version that
> the human user sees in another client, then perhaps the user suspects
> that there is something very wrong and calls the sysadmin. I see this
> problem as quite rare. Perhaps we don't need to solve it in our protocol
> and instead deal with it at the human layer. Not everything needs a
> technical solution.
>

Yeah, you are right. All the user has to do is to delete clients
cache, in case he notices any inconsistency. Compared to the
difficulty of solving such rare cases on the protocol level, it is not
so much problematic I guess.

From zarevucky.jiri at gmail.com  Wed Apr 22 08:15:21 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 22 Apr 2009 15:15:21 +0200
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49EE7425.5050001@stpeter.im>
References: <E1LuvE5-0003v3-00@apollo> <6293.1240319279.632312@puncture>
	<49EDCFD7.5080406@stpeter.im> <49EDE0B8.20006@stpeter.im>
	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>
	<49EE19A2.7040104@stpeter.im>
	<e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>
	<49EE43A9.8000905@stpeter.im> <49EE7425.5050001@stpeter.im>
Message-ID: <e962983d0904220615t322800d3m4aececd3b9aa93d3@mail.gmail.com>

2009/4/22 Peter Saint-Andre <stpeter at stpeter.im>:
>
> Done. Currently I have this in my working copy:
>
> ***
>
> 2.3 Server Response
>
> Whether or not the roster has changed since the version enumerated by
> the client, the server MUST either return the complete roster as
> described in RFC 3921 or return an empty IQ-result (thus indicating that
> any roster modifications will be sent via roster pushes, as described
> below). In general, unless returning the complete roster would use less
> bandwidth than sending individual roster pushes to the client (e.g., if
> the roster contains only a few items), the server SHOULD send an empty
> IQ-result and then send the modifications (if any) via roster pushes. In
> addition, if the client signals a sequence number that is greater than
> the sequence number currently on file at the server for that JID, the
> server MUST return the whole current roster as if client announced its
> version to be zero, thus bootstrapping the client's local cache.
>
> ***
>
> Peter
>

I like it. Thanks :)

From asterix at lagaule.org  Wed Apr 22 09:55:35 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Wed, 22 Apr 2009 16:55:35 +0200
Subject: [Standards] XEP-0145 (Annotations)
Message-ID: <49EF2FE7.1040701@lagaule.org>

Hi,

This XEP is maked as historical, why? Is it replaced by something else?
Shouldn't it be updated to use pubsub instead of XML storage?

-- 
Yann

From stpeter at stpeter.im  Wed Apr 22 10:10:35 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Apr 2009 09:10:35 -0600
Subject: [Standards] XEP-0145 (Annotations)
In-Reply-To: <49EF2FE7.1040701@lagaule.org>
References: <49EF2FE7.1040701@lagaule.org>
Message-ID: <49EF336B.4090205@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/22/09 8:55 AM, Yann Leboulanger wrote:
> Hi,
> 
> This XEP is maked as historical, why? Is it replaced by something else?
> Shouldn't it be updated to use pubsub instead of XML storage?

I think it is historical because of the dependency on XEP-0049. Whether
XEP-0049 deserves to be historical is another question. :)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvM2sACgkQNL8k5A2w/vwfhwCgoObRqV2KkiSlPcgFKeaCTbLd
JjoAnjk2uFzE0IxhTlQH5bXLO/YZ6R9n
=jpgK
-----END PGP SIGNATURE-----

From kevin at kismith.co.uk  Wed Apr 22 10:18:15 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Wed, 22 Apr 2009 16:18:15 +0100
Subject: [Standards] XEP-0145 (Annotations)
In-Reply-To: <49EF336B.4090205@stpeter.im>
References: <49EF2FE7.1040701@lagaule.org> <49EF336B.4090205@stpeter.im>
Message-ID: <f5aae3ec0904220818p20401137v502c3800f6be1435@mail.gmail.com>

>> This XEP is maked as historical, why? Is it replaced by something else?
>> Shouldn't it be updated to use pubsub instead of XML storage?

Well, I think really we want the ability to hang arbitrary data off
roster items.
At least, that's what I'd like :)

/K

From stpeter at stpeter.im  Wed Apr 22 10:19:42 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Apr 2009 09:19:42 -0600
Subject: [Standards] XEP-0145 (Annotations)
In-Reply-To: <f5aae3ec0904220818p20401137v502c3800f6be1435@mail.gmail.com>
References: <49EF2FE7.1040701@lagaule.org> <49EF336B.4090205@stpeter.im>
	<f5aae3ec0904220818p20401137v502c3800f6be1435@mail.gmail.com>
Message-ID: <49EF358E.4010906@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/22/09 9:18 AM, Kevin Smith wrote:
>>> This XEP is maked as historical, why? Is it replaced by something else?
>>> Shouldn't it be updated to use pubsub instead of XML storage?
> 
> Well, I think really we want the ability to hang arbitrary data off
> roster items.
> At least, that's what I'd like :)

I think you're not alone. So let's get to work on that!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvNY4ACgkQNL8k5A2w/vzWqQCgnlHfdRUVLahTefWNof8cqW2R
wOMAoPgChvh0ds7VH4eCF1I7iXVQ0T9i
=+sMb
-----END PGP SIGNATURE-----

From leon at darkk.net.ru  Wed Apr 22 11:25:49 2009
From: leon at darkk.net.ru (Leonid Evdokimov)
Date: Wed, 22 Apr 2009 23:25:49 +0700
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904220612s777b5923q2dab5480f5550efd@mail.gmail.com>
References: <E1LuvE5-0003v3-00@apollo>
	<6293.1240319279.632312@puncture>	<49EDCFD7.5080406@stpeter.im>
	<49EDE0B8.20006@stpeter.im>	<e962983d0904211157q31a20414n9e675c036a5ffbbf@mail.gmail.com>	<49EE19A2.7040104@stpeter.im>	<e962983d0904211358x451b9d05mce7e6d11cf82d114@mail.gmail.com>	<49EE43A9.8000905@stpeter.im>	<e962983d0904211531s1c92ed33ne8d4abe239b2a515@mail.gmail.com>	<49EE7105.5000600@stpeter.im>
	<e962983d0904220612s777b5923q2dab5480f5550efd@mail.gmail.com>
Message-ID: <49EF450D.6050708@darkk.net.ru>

Ji?? Z?rev?ck? wrote:
> All the user has to do is to delete clients cache, in case he notices
> any inconsistency. Compared to the difficulty of solving such rare
> cases on the protocol level, it is not so much problematic I guess.

The only "easy" solution I see is to have separate "base" version, e.g.
date of creation version='0' or just random number that will create
roster collision improbable. Anyway, I don't think that it worth do.

I see following possible cases of version "collision":

1. Server crash

If server has lost the roster the only thing that the client MAY do on
receiving empty roster with ver="0" is to ask user if the user wants to
save local cache instead of purging it.

I really don't want to lose the roster because of server crash and I
really would like to be able to restore it from local cache.

Anyway, I'm not sure if the case should be mentioned in the XEP as it
purely implementation-specific feature.


2. Same user unregister account and register it again.

I see the only sane reason to do that ? user wants to purge the roster
and has no shortcut for that. I don't think that it is real-world case.


3. One user unregisters his account and another one registers one with
same JID and password. The first user logs in with stale cache then.

IMHO, this case is sort of soap opera scenario :-)


-- 
WBRBW, Leonid Evdokimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090422/6e4847f4/attachment.pgp>

From editor at xmpp.org  Wed Apr 22 12:08:31 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 22 Apr 2009 12:08:31 -0500
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
Message-ID: <E1Lwfvz-0007cQ-00@apollo>

Version 0.9 of XEP-0237 (Roster Versioning) has been released.

Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not changed, thus saving bandwidth during session establishment.

Changelog: Further clarified several implementation notes. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0237.xml?%40diffMode=u&%40diffWrap=s&r1=3061&r2=3074&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0237.html


From stpeter at stpeter.im  Wed Apr 22 14:40:34 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Apr 2009 13:40:34 -0600
Subject: [Standards] dialback, refactored
Message-ID: <49EF72B2.6020800@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp Hancke has been working to refactor XEP-0220 so that it is
easier to read, more accurate, and closer to what's in RFC 3920 than to
what is now in XEP-0220. In the XMPP Council meeting just now several
participants indicated that they like the approach Philipp has taken, so
I've posted the document here for wider review:

http://xmpp.org/extensions/tmp/xep-0220-refactored.html

Please have a look and chime in!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvcrIACgkQNL8k5A2w/vzovACfRDwbBdZvXJ5MfnqWgef/A7zH
1poAnj92zHkrK06K8eOenNLBpv6cGlsP
=iU79
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Wed Apr 22 14:59:06 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Apr 2009 13:59:06 -0600
Subject: [Standards] [Fwd: [Council] meeting minutes, 2009-04-22]
Message-ID: <49EF770A.6000507@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Council] meeting minutes, 2009-04-22
Date: Wed, 22 Apr 2009 13:57:56 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Council <council at xmpp.org>
To: XMPP Council <council at xmpp.org>

Results of the XMPP Council meeting held 2009-04-22...

Agenda:

http://xmpp.org/council/agendas/2009-04-22.html

Log:

http://logs.jabber.org/council at conference.jabber.org/2009-04-22.html

Scribe: Peter Saint-Andre

0. Roll call

Present: Dave Cridland, Ralph Meijer, Peter Saint-Andre, Kevin Smith.

Absent: Jack Moffitt.

Quorum achieved.

1. Agenda bashing

None.

2. Software Information

Advance to Draft?

Lack of consensus as to whether there is still a problem to be solved
here, or (if so) whether this is the right solution.

3. Roster Versioning

Advance to Draft?

Consensus to postpone a vote until the list discussion has quieted down
(perhaps at the next meeting).

4. BOSH

Approve version 1.8?

Dave, Kevin, and Peter voted +1 in the meeting. Ralph and Jack to vote
on the list.

5. Last Activity in Presence

Last Call?

No objections to issuing a Last Call.

6. Advancing XEPs to Final

Consensus that XEP-0138 (Stream Compression) and XEP-0199 (XMPP Ping)
could be advanced to Final in the near future.

Rough consensus that the BOSH XEPs (124 and 206) might be ready for
advancement to Final before the end of the Council term in early September.

Rough consenus that XEP-0045 needs a bit of work before it will be
ready. Peter to post to the muc at xmpp.org list in order to gather open
issues.

7. Server Dialback

Several participants like the approach taken by Philipp Hancke in his
rewrite of XEP-0220:

http://xmpp.org/extensions/tmp/xep-0220-refactored.html

To be discussed on the standards at xmpp.org list.

8. Any other business?

Peter pointed out the gaming proposals:

http://xmpp.org/extensions/inbox/instant-gaming.html

http://xmpp.org/extensions/inbox/multi-user_gaming.html

http://xmpp.org/extensions/inbox/tictactoe.html

http://xmpp.org/extensions/inbox/tictactoe-mug.html

These were not discussed. To be on the agenda for the next meeting.

9. Next meeting.

April 29.

Peter



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvdwoACgkQNL8k5A2w/vwWqACfbpt4vt+pd1u/9Ktm0+7ALo7R
tBsAnRqYL3dL7oMCvbCd4CGPgUsK9Zd0
=6JvH
-----END PGP SIGNATURE-----

From editor at xmpp.org  Wed Apr 22 15:04:39 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Wed, 22 Apr 2009 15:04:39 -0500
Subject: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)
Message-ID: <E1LwigR-0000dN-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0256 (Last Activity in Presence).

Abstract: This specification defines a way to use the Last Activity extension in XMPP presence notifications.

URL: http://www.xmpp.org/extensions/xep-0256.html

This Last Call begins today and shall end at the close of business on 2009-05-05.

Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

From ml at update.uu.se  Wed Apr 22 15:45:11 2009
From: ml at update.uu.se (Marcus Lundblad)
Date: Wed, 22 Apr 2009 22:45:11 +0200
Subject: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)
In-Reply-To: <E1LwigR-0000dN-00@apollo>
References: <E1LwigR-0000dN-00@apollo>
Message-ID: <1240433111.5014.17.camel@sagittarius>

ons 2009-04-22 klockan 15:04 -0500 skrev XMPP Extensions Editor:
> This message constitutes notice of a Last Call for comments on XEP-0256 (Last Activity in Presence).
> 
> Abstract: This specification defines a way to use the Last Activity extension in XMPP presence notifications.
> 
> URL: http://www.xmpp.org/extensions/xep-0256.html
> 
> This Last Call begins today and shall end at the close of business on 2009-05-05.
> 
> Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

Yes, since it allows clients to specify the amount of time they have
been "idle" allowing those on their roster to see their idleness without
polling using a "last" query.

> 2. Does the specification solve the problem stated in the introduction and requirements?
Yes.

> 3. Do you plan to implement this specification in your code? If not, why not?
I have already implemented this client-side.

> 4. Do you have any security concerns related to this specification?
I wouldn't say I have, since clients can opt to not do presence updates
at all for "auto idle" or have it configurable, as we do in Pidgin,
where you can choose idle reporting based on "mouse and keyboard", "last
message sent" and "none", which turns off auto-away entirely

> 5. Is the specification accurate and clearly written?

Yes and it's a very small spec. too :)
> 
> Your feedback is appreciated!

//Marcus



From stpeter at stpeter.im  Wed Apr 22 15:53:09 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Apr 2009 14:53:09 -0600
Subject: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)
In-Reply-To: <1240433111.5014.17.camel@sagittarius>
References: <E1LwigR-0000dN-00@apollo> <1240433111.5014.17.camel@sagittarius>
Message-ID: <49EF83B5.4000703@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/22/09 2:45 PM, Marcus Lundblad wrote:
> ons 2009-04-22 klockan 15:04 -0500 skrev XMPP Extensions Editor:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0256 (Last Activity in Presence).
>> 
>> Abstract: This specification defines a way to use the Last Activity
>> extension in XMPP presence notifications.
>> 
>> URL: http://www.xmpp.org/extensions/xep-0256.html
>> 
>> This Last Call begins today and shall end at the close of business
>> on 2009-05-05.
>> 
>> Please consider the following questions during this Last Call and
>> send your feedback to the standards at xmpp.org discussion list:
>> 
>> 1. Is this specification needed to fill gaps in the XMPP protocol
>> stack or to clarify an existing protocol?
> 
> Yes, since it allows clients to specify the amount of time they have 
> been "idle" allowing those on their roster to see their idleness
> without polling using a "last" query.

Yes, that seems quite helpful.

>> 2. Does the specification solve the problem stated in the
>> introduction and requirements?
> Yes.

Agreed.

>> 3. Do you plan to implement this specification in your code? If
>> not, why not?
> I have already implemented this client-side.

Nifty.

>> 4. Do you have any security concerns related to this specification?
>> 
> I wouldn't say I have, since clients can opt to not do presence
> updates at all for "auto idle" or have it configurable, as we do in
> Pidgin, where you can choose idle reporting based on "mouse and
> keyboard", "last message sent" and "none", which turns off auto-away
> entirely

Perhaps the security considerations need to say that clients MUST
provide a way for a user to disable this feature.

>> 5. Is the specification accurate and clearly written?
> 
> Yes and it's a very small spec. too :)

Yes, that's a definite virtue. I've been working on XEP-0060 lately and
it's a pleasant break to read something that's short and sweet. ;-)

>> Your feedback is appreciated!

Thanks for posting!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvg7UACgkQNL8k5A2w/vwxZwCfR3kBr0kmEWxika3JOgxR8iGH
Q6kAoKgCV9Nv6FwFrfvVunvCeo/ll4Cm
=VjGI
-----END PGP SIGNATURE-----

From zarevucky.jiri at gmail.com  Wed Apr 22 15:55:10 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 22 Apr 2009 22:55:10 +0200
Subject: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)
In-Reply-To: <E1LwigR-0000dN-00@apollo>
References: <E1LwigR-0000dN-00@apollo>
Message-ID: <e962983d0904221355q28b13d61g1f3427a97facfca6@mail.gmail.com>

Seems fine, but it looks to me more like a best practice then a
standards track protocol... :)

From dave at cridland.net  Wed Apr 22 16:01:31 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 22 Apr 2009 22:01:31 +0100
Subject: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)
In-Reply-To: <e962983d0904221355q28b13d61g1f3427a97facfca6@mail.gmail.com>
References: <E1LwigR-0000dN-00@apollo>
	<e962983d0904221355q28b13d61g1f3427a97facfca6@mail.gmail.com>
Message-ID: <3965.1240434091.460771@puncture>

On Wed Apr 22 21:55:10 2009, Ji?? Z?rev?ck? wrote:
> Seems fine, but it looks to me more like a best practice then a
> standards track protocol... :)

No, it needs a defined meaning to work between clients - it's  
standards-track work.

I'm entirely happy with it. But then again, I'm server-side, I don't  
have to do anything. :-)

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From zarevucky.jiri at gmail.com  Wed Apr 22 16:06:59 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 22 Apr 2009 23:06:59 +0200
Subject: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)
In-Reply-To: <3965.1240434091.460771@puncture>
References: <E1LwigR-0000dN-00@apollo>
	<e962983d0904221355q28b13d61g1f3427a97facfca6@mail.gmail.com>
	<3965.1240434091.460771@puncture>
Message-ID: <e962983d0904221406i1e523324s621e9b71762182b0@mail.gmail.com>

2009/4/22 Dave Cridland <dave at cridland.net>:
>
> I'm entirely happy with it. But then again, I'm server-side, I don't have to
> do anything. :-)
>

Not exactly. Server has to add the delay element to probe responses ;)

From standards at xmpp.org  Thu Apr 23 01:34:03 2009
From: standards at xmpp.org (VIAGRA Inc.)
Date: Thu, 23 Apr 2009 11:34:03 +0500
Subject: [Standards] Pharmacy Online Sale 81% OFF!
Message-ID: <20090423163403.2961.qmail@k-e7e3104e76214>

An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090423/41e48252/attachment-0001.htm>
-------------- next part --------------


New from WebMD: Dear standards at xmpp.org!. Sign-up today! 



You are subscribed as standards at xmpp.org.
View and manage your WebMD newsletter preferences.
Subscribe to more newsletters. Change/update  your email address. 

WebMD Privacy Policy 
WebMD Office of Privacy
1175 Peachtree Street, Suite 2400, Atlanta, GA 30361
? 2009 WebMD, LLC. All rights reserved.

From will.thompson at collabora.co.uk  Thu Apr 23 12:42:35 2009
From: will.thompson at collabora.co.uk (Will Thompson)
Date: Thu, 23 Apr 2009 18:42:35 +0100
Subject: [Standards] more candidates for Final?
In-Reply-To: <49E536A3.7050200@stpeter.im>
References: <49E536A3.7050200@stpeter.im>
Message-ID: <49F0A88B.40501@collabora.co.uk>

Peter Saint-Andre wrote:
> XEP-0012: Last Activity

This XEP requires you to poll your contacts for their idle time. That
seems like a *really* bad idea.

Regards,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090423/69832042/attachment.pgp>

From stpeter at stpeter.im  Thu Apr 23 12:49:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 23 Apr 2009 11:49:22 -0600
Subject: [Standards] more candidates for Final?
In-Reply-To: <49F0A88B.40501@collabora.co.uk>
References: <49E536A3.7050200@stpeter.im> <49F0A88B.40501@collabora.co.uk>
Message-ID: <49F0AA22.8090006@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/23/09 11:42 AM, Will Thompson wrote:
> Peter Saint-Andre wrote:
>> XEP-0012: Last Activity
> 
> This XEP requires you to poll your contacts for their idle time. 

Not if used as described in XEP-0256. At that point XEP-0012 is simply a
data format, and how it is transported is open to the using application.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknwqiIACgkQNL8k5A2w/vyGBACeN1wwpyAsAbnjMX4+pbo5dRXK
+mUAoOJ0dTlX6WZrzgwzEqyvJkPscjnS
=LQUE
-----END PGP SIGNATURE-----

From will.thompson at collabora.co.uk  Thu Apr 23 12:50:42 2009
From: will.thompson at collabora.co.uk (Will Thompson)
Date: Thu, 23 Apr 2009 18:50:42 +0100
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
Message-ID: <49F0AA72.8050909@collabora.co.uk>

Hi,

I was just glancing over XEP-0186, and I noticed the following section:

> 3.1.2 Client Handling

> While the client is in invisible mode, the client:

>     * MUST maintain a temporary list of entities with which communication is allowed, and prompt the user before adding any entity to that "communicants list" for this invisibility session; the list MAY be auto-populated with trusted entities if so configured by the user.

>     * MUST prompt the user before sending any outbound traffic (message, presence, or IQ stanza) to a contact even if the user generated such traffic; upon receiving authorization from the user, the client SHOULD add the authorized entity to the communicants list for this invisibility session.

This UI seems ridiculous to me: if my client did this, it would really
annoy me. If I'm invisible but want to message a contact, that's my
choice. My client shouldn't get in the way (unless I want it to, which I
don't). Unfortunately, per the XEP a client that behaves how I want
rather than as above is buggy.

Perhaps this section could be removed, or rephrased as one possible UI?
XEPs mandating particular UI behaviour seems like a bad idea in general,
especially when the mandated behaviour is undesirable. :)

Regards,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090423/18258d50/attachment.pgp>

From will.thompson at collabora.co.uk  Thu Apr 23 12:56:59 2009
From: will.thompson at collabora.co.uk (Will Thompson)
Date: Thu, 23 Apr 2009 18:56:59 +0100
Subject: [Standards] more candidates for Final?
In-Reply-To: <49F0AA22.8090006@stpeter.im>
References: <49E536A3.7050200@stpeter.im> <49F0A88B.40501@collabora.co.uk>
	<49F0AA22.8090006@stpeter.im>
Message-ID: <49F0ABEB.60005@collabora.co.uk>

Peter Saint-Andre wrote:
> On 4/23/09 11:42 AM, Will Thompson wrote:
>> Peter Saint-Andre wrote:
>>> XEP-0012: Last Activity
>> This XEP requires you to poll your contacts for their idle time. 
> 
> Not if used as described in XEP-0256. At that point XEP-0012 is simply a
> data format, and how it is transported is open to the using application.

Ah, I see!

Wouldn't it be clearer if the two XEPs were combined, or if XEP-0012
referenced XEP-0256?

Regards,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090423/5fe67cf5/attachment.pgp>

From stpeter at stpeter.im  Thu Apr 23 13:01:44 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 23 Apr 2009 12:01:44 -0600
Subject: [Standards] more candidates for Final?
In-Reply-To: <49F0ABEB.60005@collabora.co.uk>
References: <49E536A3.7050200@stpeter.im>
	<49F0A88B.40501@collabora.co.uk>	<49F0AA22.8090006@stpeter.im>
	<49F0ABEB.60005@collabora.co.uk>
Message-ID: <49F0AD08.7040704@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/23/09 11:56 AM, Will Thompson wrote:
> Peter Saint-Andre wrote:
>> On 4/23/09 11:42 AM, Will Thompson wrote:
>>> Peter Saint-Andre wrote:
>>>> XEP-0012: Last Activity
>>> This XEP requires you to poll your contacts for their idle time. 
>> Not if used as described in XEP-0256. At that point XEP-0012 is simply a
>> data format, and how it is transported is open to the using application.
> 
> Ah, I see!
> 
> Wouldn't it be clearer if the two XEPs were combined, or if XEP-0012
> referenced XEP-0256?

I tried to sneak the use case from XEP-0256 into XEP-0012 but the XMPP
Council didn't like that idea, thus the separate spec. :P But yes, some
cross-references would be good...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknwrQgACgkQNL8k5A2w/vxcNQCgxGwiTWu8yIEm1F2hlTIs8H6/
wEYAoNYbe+LHc4EnUExPxkaDfgftW/SI
=nvjI
-----END PGP SIGNATURE-----

From zarevucky.jiri at gmail.com  Thu Apr 23 13:02:24 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Thu, 23 Apr 2009 20:02:24 +0200
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <49F0AA72.8050909@collabora.co.uk>
References: <49F0AA72.8050909@collabora.co.uk>
Message-ID: <e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>

2009/4/23 Will Thompson <will.thompson at collabora.co.uk>:
> Hi,
>
> I was just glancing over XEP-0186, and I noticed the following section:
>
>> 3.1.2 Client Handling
>
>> While the client is in invisible mode, the client:
>
>> ? ? * MUST maintain a temporary list of entities with which communication is allowed, and prompt the user before adding any entity to that "communicants list" for this invisibility session; the list MAY be auto-populated with trusted entities if so configured by the user.
>
>> ? ? * MUST prompt the user before sending any outbound traffic (message, presence, or IQ stanza) to a contact even if the user generated such traffic; upon receiving authorization from the user, the client SHOULD add the authorized entity to the communicants list for this invisibility session.
>
> This UI seems ridiculous to me: if my client did this, it would really
> annoy me. If I'm invisible but want to message a contact, that's my
> choice. My client shouldn't get in the way (unless I want it to, which I
> don't). Unfortunately, per the XEP a client that behaves how I want
> rather than as above is buggy.
>
> Perhaps this section could be removed, or rephrased as one possible UI?
> XEPs mandating particular UI behaviour seems like a bad idea in general,
> especially when the mandated behaviour is undesirable. :)
>
> Regards,
> --
> Will
>
>

I don't think it's ridiculous. I guards against accidental leaking of presence.
You can leak for example by requesting users client's version or
service discovery information. I can imagine very little ordinary
users realize it.

You can still add some sort of checkbox saying "Don't ask again".
That's not against the rules IMO, as this way the user configures the
client to autopopulate trusted list with any contacts he interacts
with. It's all just implementation details.

From stpeter at stpeter.im  Thu Apr 23 13:13:47 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 23 Apr 2009 12:13:47 -0600
Subject: [Standards] XEP-0237: version == sequence number?
Message-ID: <49F0AFDB.8000005@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just chatted with Jonas Lindberg via IM about the requirement in
XEP-0237 that the value of the 'ver' attribute is a strictly increasing
sequence number. Other than the similarity to IMAP CONDSTORE, is there
any strong reason why this is (or seems to be) a MUST?

His argument was that the server might make the 'ver' attribute
something like a hash of the roster, which would be opaque to the client
but meaningful to the server so that it could figure out if it would
return an empty IQ-result or the full roster (leaving aside the roster
push for now). That seems like a perfectly acceptable approach to me as
a minimal implementation, so I'm wondering if we want to say that the
'ver' value needs to be opaque to the user but meaningful to the server,
and that one possible implementation is a strictly increasing sequence
number.

(Side note: I can definitely envision "smart" clients thinking that the
strictly increasing sequence numbers have semantic meaning and trying to
second-guess the server, so it's not clear to me how opaque such a
number really is...)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknwr9sACgkQNL8k5A2w/vz37ACfQTS3ti07ZUWOlFZxPuKN+PNr
0egAnRD/fQvVaaqVBpf9vpTS3zlWCSP+
=er/b
-----END PGP SIGNATURE-----

From mwild1 at gmail.com  Thu Apr 23 13:30:29 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Thu, 23 Apr 2009 19:30:29 +0100
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <49F0AFDB.8000005@stpeter.im>
References: <49F0AFDB.8000005@stpeter.im>
Message-ID: <4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>

On Thu, Apr 23, 2009 at 7:13 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I just chatted with Jonas Lindberg via IM about the requirement in
> XEP-0237 that the value of the 'ver' attribute is a strictly increasing
> sequence number. Other than the similarity to IMAP CONDSTORE, is there
> any strong reason why this is (or seems to be) a MUST?
>

I'm in favour of it being opaque. I don't see any reason the client
needs to know the sequence number, and it would help server-side
implementations a lot. At the end of the day it is simply a token to
mark for the server the current revision stored by the client. Failing
to recognise the revision the server can simply send the full roster
anyway.

We would need to decide what to do where we currently set ver='0' though.

Matthew

From stpeter at stpeter.im  Thu Apr 23 13:36:18 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 23 Apr 2009 12:36:18 -0600
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
References: <49F0AFDB.8000005@stpeter.im>
	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
Message-ID: <49F0B522.7010600@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/23/09 12:30 PM, Matthew Wild wrote:
> On Thu, Apr 23, 2009 at 7:13 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I just chatted with Jonas Lindberg via IM about the requirement in
>> XEP-0237 that the value of the 'ver' attribute is a strictly increasing
>> sequence number. Other than the similarity to IMAP CONDSTORE, is there
>> any strong reason why this is (or seems to be) a MUST?
>>
> 
> I'm in favour of it being opaque. I don't see any reason the client
> needs to know the sequence number, and it would help server-side
> implementations a lot. At the end of the day it is simply a token to
> mark for the server the current revision stored by the client. Failing
> to recognise the revision the server can simply send the full roster
> anyway.

Yes that seems sensible to me.

> We would need to decide what to do where we currently set ver='0' though.

Yeah, I was thinking about that too. I suppose it could still be zero or
some non-opaque string (bad), or that we could add another attribute
(bootstrap="true"?) rather than overload 'ver'.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknwtSIACgkQNL8k5A2w/vyOPwCfX74ShygoD0PlifVMJ/PGxM6O
wKoAnRDBkJ79ySmTo9JcQU6JrEchj81p
=aZm+
-----END PGP SIGNATURE-----

From editor at xmpp.org  Thu Apr 23 18:28:28 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 23 Apr 2009 18:28:28 -0500
Subject: [Standards] UPDATED: XEP-0266 (Codecs for Jingle RTP Sessions)
Message-ID: <E1Lx8LE-0005C5-00@apollo>

Version 0.2 of XEP-0266 (Codecs for Jingle RTP Sessions) has been released.

Abstract: This document describes implementation considerations related to voice and video codecs for use in Jingle RTP sessions.

Changelog: Added information about the Dirac video codec. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0266.xml?%40diffMode=u&%40diffWrap=s&r1=3065&r2=3092&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0266.html


From editor at xmpp.org  Thu Apr 23 18:57:03 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 23 Apr 2009 18:57:03 -0500
Subject: [Standards] DEFERRED: XEP-0238 (XMPP Protocol Flows for
	Inter-Domain Federation)
Message-ID: <E1Lx8mt-0005QE-00@apollo>

XEP-0238 (XMPP Protocol Flows for Inter-Domain Federation) has been Deferred because of inactivity.

Abstract: This specification provides detailed protocol flows for the establishment of communication between domains that provide XMPP services, including permutations for a wide variety of possible federation policies.

URL: http://www.xmpp.org/extensions/xep-0238.html

If and when a new revision of this XEP is published, its status will be changed back to Experimental.

From editor at xmpp.org  Thu Apr 23 18:58:43 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 23 Apr 2009 18:58:43 -0500
Subject: [Standards] DEFERRED: XEP-0154 (User Profile)
Message-ID: <E1Lx8oV-0005Qc-00@apollo>

XEP-0154 (User Profile) has been Deferred because of inactivity.

Abstract: This document specifies how to represent and manage profile data about IM users and other XMPP entities using the XMPP Data Forms extension.

URL: http://www.xmpp.org/extensions/xep-0154.html

If and when a new revision of this XEP is published, its status will be changed back to Experimental.

From stpeter at stpeter.im  Thu Apr 23 19:09:51 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 23 Apr 2009 18:09:51 -0600
Subject: [Standards] DEFERRED: XEP-0154 (User Profile)
In-Reply-To: <E1Lx8oV-0005Qc-00@apollo>
References: <E1Lx8oV-0005Qc-00@apollo>
Message-ID: <49F1034F.6050700@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/23/09 5:58 PM, XMPP Extensions Editor wrote:
> XEP-0154 (User Profile) has been Deferred because of inactivity.
> 
> Abstract: This document specifies how to represent and manage profile
> data about IM users and other XMPP entities using the XMPP Data Forms
> extension.
> 
> URL: http://www.xmpp.org/extensions/xep-0154.html
> 
> If and when a new revision of this XEP is published, its status will
> be changed back to Experimental.

I'm not saying that XEP-0154 is dead in the water, but I do think it
would be productive to have a discussion about perhaps using the
revamped vCard and vCard XML formats being produced by the IETF:

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev

http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml

I plan to review those soon. It should be fairly straightforward to
write our own extensions once the core format is in XML (or work with
other interested parties to do so).

Thoughts?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknxA08ACgkQNL8k5A2w/vw+lACgsxExVpvX+JtI4KXsz9WRMnod
wL0AoPNWK44H9DIe/Ik68smWeZxQbmxf
=CQLV
-----END PGP SIGNATURE-----

From fabio.forno at gmail.com  Fri Apr 24 03:37:57 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Fri, 24 Apr 2009 10:37:57 +0200
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <49F0B522.7010600@stpeter.im>
References: <49F0AFDB.8000005@stpeter.im>
	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
	<49F0B522.7010600@stpeter.im>
Message-ID: <2fd53c3a0904240137j39ac90b0t32f72c0bd4f678f7@mail.gmail.com>

On Thu, Apr 23, 2009 at 8:36 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>
>> We would need to decide what to do where we currently set ver='0' though.
>
> Yeah, I was thinking about that too. I suppose it could still be zero or
> some non-opaque string (bad), or that we could add another attribute
> (bootstrap="true"?) rather than overload 'ver'.
>

Sorry but I don't get the purpose of this. Isn't sufficient to omit
ver for bootstrapping?

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From dave at cridland.net  Fri Apr 24 04:10:20 2009
From: dave at cridland.net (Dave Cridland)
Date: Fri, 24 Apr 2009 10:10:20 +0100
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <2fd53c3a0904240137j39ac90b0t32f72c0bd4f678f7@mail.gmail.com>
References: <49F0AFDB.8000005@stpeter.im>
	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
	<49F0B522.7010600@stpeter.im>
	<2fd53c3a0904240137j39ac90b0t32f72c0bd4f678f7@mail.gmail.com>
Message-ID: <2966.1240564220.185290@puncture>

On Fri Apr 24 09:37:57 2009, Fabio Forno wrote:
> Sorry but I don't get the purpose of this. Isn't sufficient to omit
> ver for bootstrapping?

Not quite, since you wouldn't get the ver attribute added onto the  
pushes.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Fri Apr 24 04:22:34 2009
From: dave at cridland.net (Dave Cridland)
Date: Fri, 24 Apr 2009 10:22:34 +0100
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
References: <49F0AFDB.8000005@stpeter.im>
	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
Message-ID: <2966.1240564954.512131@puncture>

On Thu Apr 23 19:30:29 2009, Matthew Wild wrote:
> On Thu, Apr 23, 2009 at 7:13 PM, Peter Saint-Andre  
> <stpeter at stpeter.im> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I just chatted with Jonas Lindberg via IM about the requirement in
> > XEP-0237 that the value of the 'ver' attribute is a strictly  
> increasing
> > sequence number. Other than the similarity to IMAP CONDSTORE, is  
> there
> > any strong reason why this is (or seems to be) a MUST?
> >
> 
> I'm in favour of it being opaque. I don't see any reason the client
> needs to know the sequence number, and it would help server-side
> implementations a lot. At the end of the day it is simply a token to
> mark for the server the current revision stored by the client.  
> Failing
> to recognise the revision the server can simply send the full roster
> anyway.

The only reason I prefer a strictly increasing number is that it  
makes things much easier to debug, from a client authors perspective.  
But I'm not going to object if the consensus is to go for something  
much more opaque.

> We would need to decide what to do where we currently set ver='0'  
> though.

We just need to stick with some ver value which is special. An empty  
string works.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From fabio.forno at gmail.com  Fri Apr 24 04:25:52 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Fri, 24 Apr 2009 11:25:52 +0200
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <2966.1240564220.185290@puncture>
References: <49F0AFDB.8000005@stpeter.im>
	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
	<49F0B522.7010600@stpeter.im>
	<2fd53c3a0904240137j39ac90b0t32f72c0bd4f678f7@mail.gmail.com>
	<2966.1240564220.185290@puncture>
Message-ID: <2fd53c3a0904240225v3bf5f0d6oa4d13afe70c46e85@mail.gmail.com>

On Fri, Apr 24, 2009 at 11:10 AM, Dave Cridland <dave at cridland.net> wrote:
> On Fri Apr 24 09:37:57 2009, Fabio Forno wrote:
>>
>> Sorry but I don't get the purpose of this. Isn't sufficient to omit
>> ver for bootstrapping?
>
> Not quite, since you wouldn't get the ver attribute added onto the pushes.

oh yes, stupid me. perhaps an empty ver is the best alternative to a
new attribute

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From mwild1 at gmail.com  Fri Apr 24 06:27:33 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Fri, 24 Apr 2009 12:27:33 +0100
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <2966.1240564954.512131@puncture>
References: <49F0AFDB.8000005@stpeter.im>
	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>
	<2966.1240564954.512131@puncture>
Message-ID: <4db9cacb0904240427w133b7e5cp8ab240511162e3d2@mail.gmail.com>

On Fri, Apr 24, 2009 at 10:22 AM, Dave Cridland <dave at cridland.net> wrote:
> On Thu Apr 23 19:30:29 2009, Matthew Wild wrote:
>> We would need to decide what to do where we currently set ver='0' though.
>
> We just need to stick with some ver value which is special. An empty string
> works.
>

I'm happy with that.

From mail at seark.de  Fri Apr 24 07:02:44 2009
From: mail at seark.de (Christoph Terwelp)
Date: Fri, 24 Apr 2009 14:02:44 +0200
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <49F0AFDB.8000005@stpeter.im>
References: <49F0AFDB.8000005@stpeter.im>
Message-ID: <6ED28185-9389-444E-BE18-5FA82DD92022@seark.de>


Am 23.04.2009 um 20:13 schrieb Peter Saint-Andre:
> His argument was that the server might make the 'ver' attribute
> something like a hash of the roster, which would be opaque to the  
> client
> but meaningful to the server so that it could figure out if it would
> return an empty IQ-result or the full roster (leaving aside the roster
> push for now). That seems like a perfectly acceptable approach to me  
> as
> a minimal implementation, so I'm wondering if we want to say that the
> 'ver' value needs to be opaque to the user but meaningful to the  
> server,
> and that one possible implementation is a strictly increasing sequence
> number.

If the ver attribute is some kind of a hash of the roster, a  
additional feature could be added, to inform the client which method  
was used to generate the hash. So the client can check the current  
roster. This way corrupted rosters can be detected and no user  
interaction is required.

Christoph

From mwild1 at gmail.com  Fri Apr 24 07:10:10 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Fri, 24 Apr 2009 13:10:10 +0100
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <6ED28185-9389-444E-BE18-5FA82DD92022@seark.de>
References: <49F0AFDB.8000005@stpeter.im>
	<6ED28185-9389-444E-BE18-5FA82DD92022@seark.de>
Message-ID: <4db9cacb0904240510n70b2a083wb68191b7170bb91a@mail.gmail.com>

On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp <mail at seark.de> wrote:
>
> Am 23.04.2009 um 20:13 schrieb Peter Saint-Andre:
>>
>> His argument was that the server might make the 'ver' attribute
>> something like a hash of the roster, which would be opaque to the client
>> but meaningful to the server so that it could figure out if it would
>> return an empty IQ-result or the full roster (leaving aside the roster
>> push for now). That seems like a perfectly acceptable approach to me as
>> a minimal implementation, so I'm wondering if we want to say that the
>> 'ver' value needs to be opaque to the user but meaningful to the server,
>> and that one possible implementation is a strictly increasing sequence
>> number.
>
> If the ver attribute is some kind of a hash of the roster, a additional
> feature could be added, to inform the client which method was used to
> generate the hash. So the client can check the current roster. This way
> corrupted rosters can be detected and no user interaction is required.
>

I'd rather keep it opaque to the client. Rosters shouldn't get
corrupted during transfer, that's what TCP is for :)

If we /did/ want any such corruption detection then it belongs in
another XEP in my opinion, rosters aren't the only thing you want to
check.

The hashing algorithm of each server would be different anyway, and I
don't see that clients would want to support each and every one
individually.

Matthew.

From mail at seark.de  Fri Apr 24 07:15:31 2009
From: mail at seark.de (Christoph Terwelp)
Date: Fri, 24 Apr 2009 14:15:31 +0200
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <4db9cacb0904240510n70b2a083wb68191b7170bb91a@mail.gmail.com>
References: <49F0AFDB.8000005@stpeter.im>
	<6ED28185-9389-444E-BE18-5FA82DD92022@seark.de>
	<4db9cacb0904240510n70b2a083wb68191b7170bb91a@mail.gmail.com>
Message-ID: <043C3C8F-4205-415F-84B8-381E0E8EA21A@seark.de>


Am 24.04.2009 um 14:10 schrieb Matthew Wild:

> On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp <mail at seark.de>  
> wrote:
>>
>> If the ver attribute is some kind of a hash of the roster, a  
>> additional
>> feature could be added, to inform the client which method was used to
>> generate the hash. So the client can check the current roster. This  
>> way
>> corrupted rosters can be detected and no user interaction is  
>> required.
>>
>
> I'd rather keep it opaque to the client. Rosters shouldn't get
> corrupted during transfer, that's what TCP is for :)

I don't suggest they could get corrupted during transfer, but because  
of a client malfunction or a system crash.


> The hashing algorithm of each server would be different anyway, and I
> don't see that clients would want to support each and every one
> individually.

Maybe, but choosing a hashing algorithm in the XEP would improve the  
chances that client and server do use the same one.


Christoph

From pendleto at movsoftware.com  Fri Apr 24 10:21:49 2009
From: pendleto at movsoftware.com (Stephen Pendleton)
Date: Fri, 24 Apr 2009 11:21:49 -0400
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <49F0AA72.8050909@collabora.co.uk>
Message-ID: <2E515E0119EA4448BBB8AD12D716AC33@movsoftware.com>



-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On
Behalf Of Will Thompson
Sent: 04/23/2009 1:51 PM
To: XMPP Standards
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI


Hi,

I was just glancing over XEP-0186, and I noticed the following section:

> 3.1.2 Client Handling
This UI seems ridiculous to me: if my client did this, it would really annoy
me. If I'm invisible but want to message a contact, that's my choice. My
client shouldn't get in the way (unless I want it to, which I don't).
Unfortunately, per the XEP a client that behaves how I want rather than as
above is buggy.

Perhaps this section could be removed, or rephrased as one possible UI? XEPs
mandating particular UI behaviour seems like a bad idea in general,
especially when the mandated behaviour is undesirable. :)
--------------
I agree with you. XEP's should not be mandating client behavior, except for
client protocol behavior. I would for sure never implement it this way
either. I would vote for removing section 3.1.2.

Thanks



From hildjj at gmail.com  Fri Apr 24 10:31:20 2009
From: hildjj at gmail.com (Joe Hildebrand)
Date: Fri, 24 Apr 2009 11:31:20 -0400
Subject: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
In-Reply-To: <E1LhsJk-0003KK-00@apollo>
References: <E1LhsJk-0003KK-00@apollo>
Message-ID: <82777bea0904240831s43bd1502k61ce9ea9f09adfc7@mail.gmail.com>

Sorry I'm so far behind.  Any chance XEP-265 could have a framing
parameter in the Jingle portion?  Some folks might like to just use
BEEP instead of the framing mechanism specified in the XEP.


On Thu, Mar 12, 2009 at 5:19 PM, XMPP Extensions Editor <editor at xmpp.org> wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: OutOfBand Stream Data
>
> Abstract: This specification defines how to send parts of an XML stream over a direct connection between peers. This allows to send large stanzas or binary data without blocking the XML stream for other stanzas.
>
> URL: http://www.xmpp.org/extensions/inbox/outofband.html
>
> The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
>
>

-- 
Joe Hildebrand

From dave at cridland.net  Fri Apr 24 10:36:45 2009
From: dave at cridland.net (Dave Cridland)
Date: Fri, 24 Apr 2009 16:36:45 +0100
Subject: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
In-Reply-To: <82777bea0904240831s43bd1502k61ce9ea9f09adfc7@mail.gmail.com>
References: <E1LhsJk-0003KK-00@apollo>
	<82777bea0904240831s43bd1502k61ce9ea9f09adfc7@mail.gmail.com>
Message-ID: <2966.1240587405.398325@puncture>

On Fri Apr 24 16:31:20 2009, Joe Hildebrand wrote:
> Sorry I'm so far behind.  Any chance XEP-265 could have a framing
> parameter in the Jingle portion?  Some folks might like to just use
> BEEP instead of the framing mechanism specified in the XEP.

Or at least a BEEP-lite - we (Isode) may actually produce a spec for  
the MPP protocol that is, more or less, that - we use it for internal  
fast comms in our products already.

But in any case, yes, a framing mechanism sounds great.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From zarevucky.jiri at gmail.com  Fri Apr 24 10:49:48 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Fri, 24 Apr 2009 17:49:48 +0200
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <043C3C8F-4205-415F-84B8-381E0E8EA21A@seark.de>
References: <49F0AFDB.8000005@stpeter.im>
	<6ED28185-9389-444E-BE18-5FA82DD92022@seark.de>
	<4db9cacb0904240510n70b2a083wb68191b7170bb91a@mail.gmail.com>
	<043C3C8F-4205-415F-84B8-381E0E8EA21A@seark.de>
Message-ID: <e962983d0904240849v3c163ccdrab4c8bd28ce8b0c5@mail.gmail.com>

2009/4/24 Christoph Terwelp <mail at seark.de>:
>
> Am 24.04.2009 um 14:10 schrieb Matthew Wild:
>
>> On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp <mail at seark.de> wrote:
>>>
>>> If the ver attribute is some kind of a hash of the roster, a additional
>>> feature could be added, to inform the client which method was used to
>>> generate the hash. So the client can check the current roster. This way
>>> corrupted rosters can be detected and no user interaction is required.
>>>
>>
>> I'd rather keep it opaque to the client. Rosters shouldn't get
>> corrupted during transfer, that's what TCP is for :)
>
> I don't suggest they could get corrupted during transfer, but because of a
> client malfunction or a system crash.
>


I think you are complicating things way too much. If the client's
cache gets corrupted, it probably isn't loadable anyway.

I would let the ver be opaque for client. The implementation notes
would then simply explain the ideas behind minimal implementation with
hashes and more sophisticated implementation with integer numbers.

From Lastwebpage.3r6sgb at no-mx.jabberforum.org  Sat Apr 25 01:58:27 2009
From: Lastwebpage.3r6sgb at no-mx.jabberforum.org (Lastwebpage)
Date: Sat, 25 Apr 2009 08:58:27 +0200
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
References: <49F0AA72.8050909@collabora.co.uk>
	<e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>
Message-ID: <Lastwebpage.3r6sgb@no-mx.jabberforum.org>


Only my two cents...

You should not forget the other side and for e.g. the popular protocols
ICQ and MSN.

In a nutshell both protocols support the Invisible mode (in MSN it's
named "appear off-line") and this is only annoying in both protocols.
Take a look at the other side, you have a list full of off-line
contacts, but many contacts write you messages. What's the sense of it?
It's annoying!

"... that's my choice", sorry, but I am not agree, stay off-line if you
don't want to chat or keep the possibility that the user from the other
side can see you and make sure "Invisible" is not a "normal" mode.

Therefore, in my opinion, 3.1.2. makes sense.

Peter


-- 
Lastwebpage
------------------------------------------------------------------------
Lastwebpage's Profile: http://www.jabberforum.org/member.php?userid=41
View this thread: http://www.jabberforum.org/showthread.php?t=1903


From paul at darkrain42.org  Sat Apr 25 11:12:15 2009
From: paul at darkrain42.org (Paul Aurich)
Date: Sat, 25 Apr 2009 09:12:15 -0700
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>
References: <49F0AA72.8050909@collabora.co.uk>
	<e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>
Message-ID: <49F3365F.7030204@darkrain42.org>

And Ji?? Z?rev?ck? spoke on 04/23/2009 11:02 AM, saying:
> I don't think it's ridiculous. I guards against accidental leaking of presence.
> You can leak for example by requesting users client's version or
> service discovery information. I can imagine very little ordinary
> users realize it.
> 
> You can still add some sort of checkbox saying "Don't ask again".
> That's not against the rules IMO, as this way the user configures the
> client to autopopulate trusted list with any contacts he interacts
> with. It's all just implementation details.
> 


I think it's critical to distinguish user-generated traffic from
client-generated outgoing stanzas.  I agree with Will that, for the former,
this is a really frustrating UI and I'd hate my client for doing it.

For client-generated stanzas, it's still overly restrictive (again, I'd
hate my client for *double prompting me* if I try to establish a voice call
with someone while I'm invisible); IMHO, the XEP should say that clients
only send responses to parties to whom the user has already revealed
presence (or previously whitelisted) and respond to all other stanzas as if
the server were responding on behalf of an offline resource. If I start
messaging someone, my client should treat that as implicit authorization to
respond to IQs from or send IQs to that client.

~Paul


From zarevucky.jiri at gmail.com  Sat Apr 25 12:42:49 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Sat, 25 Apr 2009 19:42:49 +0200
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <49F3365F.7030204@darkrain42.org>
References: <49F0AA72.8050909@collabora.co.uk>
	<e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>
	<49F3365F.7030204@darkrain42.org>
Message-ID: <e962983d0904251042h1c9e2501yf06128d893ba9471@mail.gmail.com>

2009/4/25 Paul Aurich <paul at darkrain42.org>:
>
> I think it's critical to distinguish user-generated traffic from
> client-generated outgoing stanzas. ?I agree with Will that, for the former,
> this is a really frustrating UI and I'd hate my client for doing it.
>

I think that's exactly the problem in question. User can explicitly
generate traffic without him knowing. You generate traffic by opening
a window. You generate it by displaying your contact's information.
You can even generate it by hovering mouse over your contact in
roster. Ordinary users don't understand the technology and should be
warned. I still think it is implementation and configuration issue.
The "don't ask again" checkbox is really a no-brainer.

From will.thompson at collabora.co.uk  Sat Apr 25 12:51:50 2009
From: will.thompson at collabora.co.uk (Will Thompson)
Date: Sat, 25 Apr 2009 18:51:50 +0100
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <e962983d0904251042h1c9e2501yf06128d893ba9471@mail.gmail.com>
References: <49F0AA72.8050909@collabora.co.uk>	<e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>	<49F3365F.7030204@darkrain42.org>
	<e962983d0904251042h1c9e2501yf06128d893ba9471@mail.gmail.com>
Message-ID: <49F34DB6.7070506@collabora.co.uk>

I think the examples you give are arguably client bugs.

Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAck=C3=BD wrote:
> You generate traffic by opening a window.

You don't need to.

> You generate it by displaying your contact's information.

Then don't do so unless the contact's already whitelisted (because you
sent them an IM) and have a "show more information (may reveal your
existence" button.

> You can even generate it by hovering mouse over your contact in
> roster.

Your client really shouldn't generate traffic then.

Obviously the client should try not to expose the user without them
doing something that obviously exposes them, so prompting them if they
wouldn't expect to be exposed is reasonable. I think that's what the XEP
was trying to ensure, but I think it goes too far.


--=20
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090425/7bb15891/attachment.pgp>

From zarevucky.jiri at gmail.com  Sat Apr 25 15:28:12 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Sat, 25 Apr 2009 22:28:12 +0200
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <49F34DB6.7070506@collabora.co.uk>
References: <49F0AA72.8050909@collabora.co.uk>
	<e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>
	<49F3365F.7030204@darkrain42.org>
	<e962983d0904251042h1c9e2501yf06128d893ba9471@mail.gmail.com>
	<49F34DB6.7070506@collabora.co.uk>
Message-ID: <e962983d0904251328s76ccff8bh9f31a2377788bed1@mail.gmail.com>

2009/4/25 Will Thompson <will.thompson at collabora.co.uk>:
>
> Obviously the client should try not to expose the user without them
> doing something that obviously exposes them, so prompting them if they
> wouldn't expect to be exposed is reasonable. I think that's what the XEP
> was trying to ensure, but I think it goes too far.
>
>

The XEP says that based on configuration, client can auto-populate
communication list with trusted entities. You can (for the purposes of
end-user implementation) say that everyone in your roster, who you
explicitly start communicating with, is a trusted entity and as such
can be automatically (without prompting) added to the white-list, if
your configuration allows it.

Or am I understanding something incorrectly?

From zarevucky.jiri at gmail.com  Sat Apr 25 17:01:20 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Sun, 26 Apr 2009 00:01:20 +0200
Subject: [Standards] Unclarified behavior in XEP-0047 (in-band bytestreams)
Message-ID: <e962983d0904251501y7bb581a7k660fe6a8aba7836d@mail.gmail.com>

"Upon receiving notice that a data packet is cannot be processed by
the recipient, the sender SHOULD consider the bytestream to be closed
and invalid but MAY attempt to correct the error and re-send the
offending data packet using the same sequence number (the recipient
MUST NOT consider a sequence number to have been used until the data
packet has been successfully processed)."

The sender must either resend data or explicitly close the stream by
sending the "close" query. Otherwise the recipient doesn't know
whether the sender wants to resend or not. Right?

What confuses me it that in the case of invalid sequence number, the
one responsible for closing of the stream is the receiver:

"The recipient MUST NOT process the data of such an out-of-sequence
packet, nor any that follow it within the same bytestream; instead,
the recipient MUST consider the bytestream invalid and SHOULD close
the bytestream as described in the next section."

But that's also "SHOULD", not "MUST"... what happens if the recipient
doesn't close it?


Can this part be clarified and made sure that stream invalidation is
in all cases obvious to both entities? Thanks :)

From stpeter at stpeter.im  Mon Apr 27 16:41:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Apr 2009 15:41:21 -0600
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <4db9cacb0904240427w133b7e5cp8ab240511162e3d2@mail.gmail.com>
References: <49F0AFDB.8000005@stpeter.im>	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>	<2966.1240564954.512131@puncture>
	<4db9cacb0904240427w133b7e5cp8ab240511162e3d2@mail.gmail.com>
Message-ID: <49F62681.2000400@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/24/09 5:27 AM, Matthew Wild wrote:
> On Fri, Apr 24, 2009 at 10:22 AM, Dave Cridland <dave at cridland.net> wrote:
>> On Thu Apr 23 19:30:29 2009, Matthew Wild wrote:
>>> We would need to decide what to do where we currently set ver='0' though.
>> We just need to stick with some ver value which is special. An empty string
>> works.
>>
> 
> I'm happy with that.

So do we have consensus on the following?

(1) 'ver' is opaque

(2) empty 'ver' means bootstrap

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn2JoEACgkQNL8k5A2w/vyNSgCgy72tTMlglGIkUn0H5Y1B54Ij
AbQAoIPpy1TfQ9GxW49swOsnidYOwReC
=w8O+
-----END PGP SIGNATURE-----

From editor at xmpp.org  Mon Apr 27 17:20:34 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Mon, 27 Apr 2009 17:20:34 -0500
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
Message-ID: <E1LyZBi-0004ej-00@apollo>

Version 0.10 of XEP-0237 (Roster Versioning) has been released.

Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not been modified, thus saving bandwidth during session establishment.

Changelog: Modified ver attribute to be an opaque identifier instead of (necessarily) a strictly-increasing sequence number; specified that an empty version ID indicates that the client wishes to bootstrap the use of roster versioning. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0237.xml?%40diffMode=u&%40diffWrap=s&r1=3074&r2=3097&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0237.html


From stpeter at stpeter.im  Mon Apr 27 10:18:46 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Apr 2009 09:18:46 -0600
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <e962983d0904251042h1c9e2501yf06128d893ba9471@mail.gmail.com>
References: <49F0AA72.8050909@collabora.co.uk>	<e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>	<49F3365F.7030204@darkrain42.org>
	<e962983d0904251042h1c9e2501yf06128d893ba9471@mail.gmail.com>
Message-ID: <49F5CCD6.9070202@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/25/09 11:42 AM, Ji?? Z?rev?ck? wrote:
> 2009/4/25 Paul Aurich <paul at darkrain42.org>:
>> I think it's critical to distinguish user-generated traffic from
>> client-generated outgoing stanzas.  I agree with Will that, for the former,
>> this is a really frustrating UI and I'd hate my client for doing it.
>>
> 
> I think that's exactly the problem in question. User can explicitly
> generate traffic without him knowing. You generate traffic by opening
> a window. You generate it by displaying your contact's information.
> You can even generate it by hovering mouse over your contact in
> roster. 

That's one of the many reasons why invisibility is so stupid.

> Ordinary users don't understand the technology and should be
> warned. I still think it is implementation and configuration issue.
> The "don't ask again" checkbox is really a no-brainer.

Sure, that's fine.

Before we can productively argue (?) about XEP-0186, we'd need to see
some implementations of it in clients and servers. Do we have those?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn1zNYACgkQNL8k5A2w/vwwaQCgsCiKNvFGdPHeGlBQiGubjE3e
7qUAoOgSn9d47YYpz2iOskh3rokqHHor
=pNHH
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Mon Apr 27 10:19:16 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Apr 2009 09:19:16 -0600
Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
In-Reply-To: <e962983d0904251328s76ccff8bh9f31a2377788bed1@mail.gmail.com>
References: <49F0AA72.8050909@collabora.co.uk>	<e962983d0904231102j1cd4440aq40995e8a2b3c4d26@mail.gmail.com>	<49F3365F.7030204@darkrain42.org>	<e962983d0904251042h1c9e2501yf06128d893ba9471@mail.gmail.com>	<49F34DB6.7070506@collabora.co.uk>
	<e962983d0904251328s76ccff8bh9f31a2377788bed1@mail.gmail.com>
Message-ID: <49F5CCF4.7020203@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/25/09 2:28 PM, Ji?? Z?rev?ck? wrote:
> 2009/4/25 Will Thompson <will.thompson at collabora.co.uk>:
>> Obviously the client should try not to expose the user without them
>> doing something that obviously exposes them, so prompting them if they
>> wouldn't expect to be exposed is reasonable. I think that's what the XEP
>> was trying to ensure, but I think it goes too far.
>>
>>
> 
> The XEP says that based on configuration, client can auto-populate
> communication list with trusted entities. You can (for the purposes of
> end-user implementation) say that everyone in your roster, who you
> explicitly start communicating with, is a trusted entity and as such
> can be automatically (without prompting) added to the white-list, if
> your configuration allows it.
> 
> Or am I understanding something incorrectly?

That is correct.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn1zPQACgkQNL8k5A2w/vwzNACeKbVHvvUCy3+TBA4m3mvDjSGS
V68AninpAtZckD94neG8NVyrnl2sEkkq
=aEdM
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Mon Apr 27 18:01:35 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Apr 2009 17:01:35 -0600
Subject: [Standards] s2s discussion
Message-ID: <49F6394F.3010008@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We will hold a special meeting about server-to-server improvements next
Tuesday, May 5, at 20:00 UTC in the jdev at conference.jabber.org room. If
you have ideas about requirements, spec fixes, problems, solutions,
etc., please join the meeting next week. Expect some posts to this list
before then so we can define some of the issues. I'll try to post more
about it soon.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn2OU8ACgkQNL8k5A2w/vw2CACg0LSeM7gJ/EArtvRiwCOH5XqK
djYAoN0EROTvxofggQTu3LPY1y4LefIT
=95Vm
-----END PGP SIGNATURE-----


From zarevucky.jiri at gmail.com  Mon Apr 27 18:27:55 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Tue, 28 Apr 2009 01:27:55 +0200
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <E1LyZBi-0004ej-00@apollo>
References: <E1LyZBi-0004ej-00@apollo>
Message-ID: <e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>

I've noticed change in this part:

> the server MUST consider the item to have been modified and therefore MUST send the item to the client (typically via a roster push as described below).

You changed the MUSTs to MAY, which again introduces several possible
problems. You can find reasons in one of previous threads.

In addition, this passage doesn't make any sense after the change:

> In addition, if the client signals a version ID that is different from the version currently on file at the server for that JID, the server MUST return the whole current roster as if client announced its version to be the empty string, thus bootstrapping the client's local cache.

If the server uses incremental numbering and client returns a lesser
ver, it will always bootstrap, never sending incremental pushes. Maybe
it need rephrasing to something like "if server can't associate the
request to any previous version".

Also, I think the examples should still have the sequence numbers
(which is I believe preferred implementation). Use of hashes can be
noted in implementation notes.

Oh... and a typo:

> During that time, the client might have received roster pushes related to *varous* roster versions.



Regards, George

From stpeter at stpeter.im  Mon Apr 27 18:36:12 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Apr 2009 17:36:12 -0600
Subject: [Standards] Unclarified behavior in XEP-0047 (in-band
	bytestreams)
In-Reply-To: <e962983d0904251501y7bb581a7k660fe6a8aba7836d@mail.gmail.com>
References: <e962983d0904251501y7bb581a7k660fe6a8aba7836d@mail.gmail.com>
Message-ID: <49F6416C.2040603@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/25/09 4:01 PM, Ji?? Z?rev?ck? wrote:
> "Upon receiving notice that a data packet is cannot be processed by
> the recipient, the sender SHOULD consider the bytestream to be closed
> and invalid but MAY attempt to correct the error and re-send the
> offending data packet using the same sequence number (the recipient
> MUST NOT consider a sequence number to have been used until the data
> packet has been successfully processed)."
> 
> The sender must either resend data or explicitly close the stream by
> sending the "close" query. Otherwise the recipient doesn't know
> whether the sender wants to resend or not. Right?

That is my understanding.

> What confuses me it that in the case of invalid sequence number, the
> one responsible for closing of the stream is the receiver:
> 
> "The recipient MUST NOT process the data of such an out-of-sequence
> packet, nor any that follow it within the same bytestream; instead,
> the recipient MUST consider the bytestream invalid and SHOULD close
> the bytestream as described in the next section."
> 
> But that's also "SHOULD", not "MUST"... what happens if the recipient
> doesn't close it?

I think it would be best to change that last SHOULD to MUST.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn2QWwACgkQNL8k5A2w/vxehwCfRUL8U116rpp629gC3r+6IHa2
t6sAniNyx1iI0mU9Oh2VUi0/OoLVVA8R
=AjaZ
-----END PGP SIGNATURE-----


From editor at xmpp.org  Mon Apr 27 20:32:17 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Mon, 27 Apr 2009 20:32:17 -0500
Subject: [Standards] Proposed XMPP Extension: Incident Reporting
Message-ID: <E1LycBF-00064s-00@apollo>

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Incident Reporting

Abstract: This specification defines methods for incident reporting among XMPP server deployments.

URL: http://www.xmpp.org/extensions/inbox/incident-reporting.html

The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.


From stpeter at stpeter.im  Mon Apr 27 21:12:27 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Apr 2009 20:12:27 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>
References: <E1LyZBi-0004ej-00@apollo>
	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>
Message-ID: <49F6660B.80509@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/27/09 5:27 PM, Ji?? Z?rev?ck? wrote:
> I've noticed change in this part:
> 
>> the server MUST consider the item to have been modified and
>> therefore MUST send the item to the client (typically via a roster
>> push as described below).
> 
> You changed the MUSTs to MAY, which again introduces several possible
>  problems. You can find reasons in one of previous threads.

Not everything needs to be a MUST. Please pay attention to the context.
I take it that the text you refer to is this:

***

If a series of roster modifications result in a roster item that does
not differ from the version cached by the client (e.g., a modification
to the item's 'name' attribute and then a modification back to the
original value), the server MAY consider the item to have been modified
and therefore MAY send the item to the client (typically via a roster
push as described below).

***

Now, what this means is that perhaps the roster hasn't "really" changed
at all as a result of these modifications. If the server generates its
version IDs based on a hash of the roster, then if I change a 'name'
attribute and change it back the roster in fact hasn't changed at all
(the version IDs are the same). Why would the server send a roster push
to the client at that point? The roster is the same!

Please try to formulate the appropriate text using MUST instead of MAY
or SHOULD.

> In addition, this passage doesn't make any sense after the change:
> 
>> In addition, if the client signals a version ID that is different
>> from the version currently on file at the server for that JID, the
>> server MUST return the whole current roster as if client announced
>> its version to be the empty string, thus bootstrapping the client's
>> local cache.
> 
> If the server uses incremental numbering and client returns a lesser 
> ver, it will always bootstrap, never sending incremental pushes.
> Maybe it need rephrasing to something like "if server can't associate
> the request to any previous version".

You're right, that is nonsensical -- I must not have been paying close
attention when I made that edit. I've changed it as follows:

***

In general, unless returning the complete roster would (1) use less
bandwidth than sending individual roster pushes to the client (e.g., if
the roster contains only a few items) or (2) the server cannot associate
the version ID with any previous version it has on file, the server
SHOULD send an empty IQ-result and then send the modifications (if any)
via roster pushes.

***

> Also, I think the examples should still have the sequence numbers 
> (which is I believe preferred implementation). Use of hashes can be 
> noted in implementation notes.

I disagree. The spec says that the version ID is opaque. If the examples
include only version IDs that are *not* opaque, developers will ignore
the text and focus only on the examples.

> Oh... and a typo:
> 
>> During that time, the client might have received roster pushes
>> related to *varous* roster versions.

Fixed.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn2ZgsACgkQNL8k5A2w/vyR0wCgwB+GbAcjc98ht38yDqnEJvtS
3QwAmwTaO+fzTJOkb/cUNXBRMjq3mfIw
=VP5o
-----END PGP SIGNATURE-----

From fippo at goodadvice.pages.de  Tue Apr 28 00:48:04 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Tue, 28 Apr 2009 07:48:04 +0200
Subject: [Standards] Proposed XMPP Extension: Incident Reporting
In-Reply-To: <E1LycBF-00064s-00@apollo>
References: <E1LycBF-00064s-00@apollo>
Message-ID: <49F69894.5040204@goodadvice.pages.de>

> Title: Incident Reporting
> 
> Abstract: This specification defines methods for incident reporting among XMPP server deployments.
> 
> URL: http://www.xmpp.org/extensions/inbox/incident-reporting.html

the purpose is to enhance the information flow so that attack patterns
become visible earlier?

I somehow expected GLINE functionality :-)

From nicolas.verite at gmail.com  Tue Apr 28 02:38:18 2009
From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=)
Date: Tue, 28 Apr 2009 09:38:18 +0200
Subject: [Standards] Proposed XMPP Extension: Incident Reporting
In-Reply-To: <E1LycBF-00064s-00@apollo>
References: <E1LycBF-00064s-00@apollo>
Message-ID: <6e2f977f0904280038x6d16eb25q275832ce243d95f9@mail.gmail.com>

On Tue, Apr 28, 2009 at 03:32, XMPP Extensions Editor <editor at xmpp.org> wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Incident Reporting
>
> Abstract: This specification defines methods for incident reporting among XMPP server deployments.
>
> URL: http://www.xmpp.org/extensions/inbox/incident-reporting.html
>
> The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.

I read rapidly:

"relateds"? I'm a bit surprised by the plural...

3. Incident Reports
Original:
Multiple <text/> elements MAY be included, each with a different
'xml:lang' value.
Proposal:
Multiple <text/> elements MAY be included, each MUST have a different
'xml:lang' value.

N?co
-- 
Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com
Jabber ID : xmpp:nyco at jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adh?rez ? l'April : http://april.org/

From dave at cridland.net  Tue Apr 28 04:26:40 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 28 Apr 2009 10:26:40 +0100
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49F6660B.80509@stpeter.im>
References: <E1LyZBi-0004ej-00@apollo>
	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>
	<49F6660B.80509@stpeter.im>
Message-ID: <6610.1240910800.235191@puncture>

On Tue Apr 28 03:12:27 2009, Peter Saint-Andre wrote:
> > Also, I think the examples should still have the sequence numbers
> > (which is I believe preferred implementation). Use of hashes can  
> be
> > noted in implementation notes.
> 
> I disagree. The spec says that the version ID is opaque. If the  
> examples
> include only version IDs that are *not* opaque, developers will  
> ignore
> the text and focus only on the examples.
> 
> 
I think he's right - it's impossible to order two hashes, so "real"  
implementations - those capable of producing intermediate pushes -  
are going to use some form of "ver" with strict ordering properties,  
and the simplest way to demonstrate this is with a strictly  
increasing integer sequence, which leaves the examples clear (for  
instance, in the point 3 explanatory text of example 3)

Having other examples which use a hash is also useful, for the  
minimal implementation guidelines.

FWIW, I'd also suggest adding some text guiding implementors, and in  
particular reinstating some text warning against using timestamps.

I'll write a section for you, possibly even today.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Tue Apr 28 04:52:38 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 28 Apr 2009 10:52:38 +0100
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <6610.1240910800.235191@puncture>
References: <E1LyZBi-0004ej-00@apollo>
	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>
	<49F6660B.80509@stpeter.im> <6610.1240910800.235191@puncture>
Message-ID: <6610.1240912358.605677@puncture>

On Tue Apr 28 10:26:40 2009, Dave Cridland wrote:
> FWIW, I'd also suggest adding some text guiding implementors, and  
> in  particular reinstating some text warning against using  
> timestamps.
> 
> I'll write a section for you, possibly even today.

<section1 topic="Implementation Guidelines">
	<p>This specification is specifically designed to allow for a wide  
range of implementation choices. These range from highly simplistic  
but inefficient, to very efficient but quite complex.</p>
	<p>This section provides suggestions, rather than instructions, on  
some lightweight approaches to conforming with the specification.</p>
	<section2 topic="Syntactic Conformance">
		<p>A server can conform to this specification by accepting and  
ignoring the "ver" element in requests, and providing an empty "ver"  
attribute in each roster push.</p>
		<p>This provides no efficiency savings for clients.</p>
	</section2>
	<section2 topic="Exact-match Conformance">
		<p>Using some digest (hash) of the roster, a server can identify  
unchanged rosters, and handle the case where the client sends a ver  
corresponding to the current roster state.</p>
		<p>This will account for the majority of cases, and represents a  
substantial saving. Server implementors should be careful to  
canonicalize the form and ordering of roster items prior to applying  
the hash function. This hash function need not be cryptographically  
secure, merely resistent to collisions, and it is advisable to pick  
one that is fast to compute.</p>
		<p>No additional data need be stored, although storing the current  
hash will yield some performance advantage. This strategy is thought  
to be relatively safe in the face of data loss on the server.</p>
	</section2>
	<section2 topic="Add-only Conformance">
		<p>Using a strictly increasing sequence for the "ver" attribute, a  
server can "stamp" each roster item with its last change, and the  
roster as a whole with its last deletion. The server either the  
entire roster - if a deletion has occured since the client's ver  
value - or those changed items.</p>
		<p>Deletions are thought to be rare compared to additions and  
modifications, and as such this approach captures almost all changes.  
The additional storage cost is also low.</p>
		<p>Implementors could combine this strategy with the previous one,  
detecting a sequence of modifications yielding the same roster as the  
client has cached already, by constructing a ver attribute containing  
both a hash and sequence value. This may provide some resilience in  
the case of data loss.</p>
		<p>Implementors should note that a pure timestamp is not suitable  
for this approach, since under some circumstances system clocks may  
go backwards.</p>
	</section2>
	<section2 topic="Client Implementation Guidlines">
		<p>Client implementors are reminded that the value of the "ver"  
attribute is entirely opaque, and they should behave identically with  
each strategy described above by simply conforming to the  
specification - the only storage requirement for this specification  
is the last seen "ver" attribute.</p>
	</section2>
</section1>

Useful?
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From leon at darkk.net.ru  Tue Apr 28 06:04:54 2009
From: leon at darkk.net.ru (Leonid Evdokimov)
Date: Tue, 28 Apr 2009 18:04:54 +0700
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <6610.1240910800.235191@puncture>
References: <E1LyZBi-0004ej-00@apollo>	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>	<49F6660B.80509@stpeter.im>
	<6610.1240910800.235191@puncture>
Message-ID: <49F6E2D6.5040501@darkk.net.ru>

Dave Cridland wrote:
>> I disagree. The spec says that the version ID is opaque. If the examples
>> include only version IDs that are *not* opaque, developers will ignore
>> the text and focus only on the examples.
>>
> I think he's right - it's impossible to order two hashes, so "real"
> implementations - those capable of producing intermediate pushes - are
> going to use some form of "ver" with strict ordering properties

Using pure roster hash introduces collisions that are not rare at all:

Roster v10: [1 at example.com]
Roster v20: [1 at example.com, 2 at example.org]
Roster v30: [1 at example.com]

Hash(Roster v10) == Hash(Roster v30)

I think, this collision contradicts with the letter of the XEP:

| The server MUST ensure that each roster modification will result in
| a different version and that the version associated with a given
| roster modification will be different from version associated with any
| previous roster modification for this session

So, `Hash(Roster)` recommendation in `Implementation Guidelines` should
be replaced with something like `Hash(Nonce || Roster)` to follow the
letter of the XEP. And I see no good reason to use `Hash` if `Nonce` is
used.

-- 
WBRBW, Leonid Evdokimov


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090428/029e15b2/attachment.pgp>

From melo at simplicidade.org  Tue Apr 28 06:15:19 2009
From: melo at simplicidade.org (Pedro Melo)
Date: Tue, 28 Apr 2009 12:15:19 +0100
Subject: [Standards] XEP-0237: version == sequence number?
In-Reply-To: <49F62681.2000400@stpeter.im>
References: <49F0AFDB.8000005@stpeter.im>	<4db9cacb0904231130k47ec9c55o8166bfd98a3781b4@mail.gmail.com>	<2966.1240564954.512131@puncture>
	<4db9cacb0904240427w133b7e5cp8ab240511162e3d2@mail.gmail.com>
	<49F62681.2000400@stpeter.im>
Message-ID: <115806A5-F68B-40F6-858E-2D08E86B42F2@simplicidade.org>


On Apr 27, 2009, at 10:41 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 4/24/09 5:27 AM, Matthew Wild wrote:
>> On Fri, Apr 24, 2009 at 10:22 AM, Dave Cridland <dave at cridland.net>  
>> wrote:
>>> On Thu Apr 23 19:30:29 2009, Matthew Wild wrote:
>>>> We would need to decide what to do where we currently set ver='0'  
>>>> though.
>>> We just need to stick with some ver value which is special. An  
>>> empty string
>>> works.
>>>
>>
>> I'm happy with that.
>
> So do we have consensus on the following?
>
> (1) 'ver' is opaque
>
> (2) empty 'ver' means bootstrap

+1 from me. Sane, and simple.

Best regards,

>
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkn2JoEACgkQNL8k5A2w/vyNSgCgy72tTMlglGIkUn0H5Y1B54Ij
> AbQAoIPpy1TfQ9GxW49swOsnidYOwReC
> =w8O+
> -----END PGP SIGNATURE-----

-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!



From dave at cridland.net  Tue Apr 28 06:51:17 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 28 Apr 2009 12:51:17 +0100
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49F6E2D6.5040501@darkk.net.ru>
References: <E1LyZBi-0004ej-00@apollo>
	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>
	<49F6660B.80509@stpeter.im> <6610.1240910800.235191@puncture>
	<49F6E2D6.5040501@darkk.net.ru>
Message-ID: <6610.1240919477.285205@puncture>

On Tue Apr 28 12:04:54 2009, Leonid Evdokimov wrote:
> Roster v10: [1 at example.com]
> Roster v20: [1 at example.com, 2 at example.org]
> Roster v30: [1 at example.com]
> 
> Hash(Roster v10) == Hash(Roster v30)
> 
> 
And this is okay, since a client that says "I have Hash(Roster v10)"  
has the correct roster even if it's actually "Hash(Roster v30)" that  
the server has.


> I think, this collision contradicts with the letter of the XEP:
> 
> | The server MUST ensure that each roster modification will result  
> in
> | a different version and that the version associated with a given
> | roster modification will be different from version associated  
> with any
> | previous roster modification for this session
> 
> 
Yes...


> So, `Hash(Roster)` recommendation in `Implementation Guidelines`  
> should
> be replaced with something like `Hash(Nonce || Roster)` to follow  
> the
> letter of the XEP. And I see no good reason to use `Hash` if  
> `Nonce` is
> used.

No, I think the text you quote above is wrong.

Once you allow for Hash(Roster), it's possible to basically drop the  
requirement for unique "ver" for each roster modification, within a  
session or otherwise.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Tue Apr 28 07:05:25 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Apr 2009 06:05:25 -0600
Subject: [Standards] Proposed XMPP Extension: Incident Reporting
In-Reply-To: <49F69894.5040204@goodadvice.pages.de>
References: <E1LycBF-00064s-00@apollo> <49F69894.5040204@goodadvice.pages.de>
Message-ID: <49F6F105.7060408@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/27/09 11:48 PM, Philipp Hancke wrote:
>> Title: Incident Reporting
>>
>> Abstract: This specification defines methods for incident reporting
>> among XMPP server deployments.
>>
>> URL: http://www.xmpp.org/extensions/inbox/incident-reporting.html
> 
> the purpose is to enhance the information flow so that attack patterns
> become visible earlier?

Yes.

> I somehow expected GLINE functionality :-)

That might be part of the solution, yes. It depends on the nature of
incident/attack/problem.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn28QUACgkQNL8k5A2w/vxaDQCg9TaHRLHj5KAHzy0HaS8YgP7q
QigAn1f9GMxa7dxcn8nO8GEEVJin+Pet
=udlb
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 28 07:06:50 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Apr 2009 06:06:50 -0600
Subject: [Standards] Proposed XMPP Extension: Incident Reporting
In-Reply-To: <6e2f977f0904280038x6d16eb25q275832ce243d95f9@mail.gmail.com>
References: <E1LycBF-00064s-00@apollo>
	<6e2f977f0904280038x6d16eb25q275832ce243d95f9@mail.gmail.com>
Message-ID: <49F6F15A.4080900@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/28/09 1:38 AM, Nicolas V?rit? wrote:
> On Tue, Apr 28, 2009 at 03:32, XMPP Extensions Editor <editor at xmpp.org> wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Incident Reporting
>>
>> Abstract: This specification defines methods for incident reporting among XMPP server deployments.
>>
>> URL: http://www.xmpp.org/extensions/inbox/incident-reporting.html
>>
>> The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
> 
> I read rapidly:
> 
> "relateds"? I'm a bit surprised by the plural...

Yes, that's a bit awkward. We could change it to:

<related_incidents>

or

<rels>

I'm fine with either.

> 3. Incident Reports
> Original:
> Multiple <text/> elements MAY be included, each with a different
> 'xml:lang' value.
> Proposal:
> Multiple <text/> elements MAY be included, each MUST have a different
> 'xml:lang' value.

Good point.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn28VoACgkQNL8k5A2w/vzQ/wCgguIV2Vjzl/rQQoL8js+VA8f3
iJAAnivhtwcRZQUDBjO+/hcm6/5xPaMH
=D0N/
-----END PGP SIGNATURE-----

From florian.zeitz at gmx.de  Tue Apr 28 07:25:14 2009
From: florian.zeitz at gmx.de (Florian Zeitz)
Date: Tue, 28 Apr 2009 14:25:14 +0200
Subject: [Standards] Unclarified behavior in XEP-0047
	(in-band	bytestreams)
In-Reply-To: <49F6416C.2040603@stpeter.im>
References: <e962983d0904251501y7bb581a7k660fe6a8aba7836d@mail.gmail.com>
	<49F6416C.2040603@stpeter.im>
Message-ID: <49F6F5AA.7020304@gmx.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Saint-Andre wrote:
> On 4/25/09 4:01 PM, JiY? Z?rev?ck? wrote:
>> "Upon receiving notice that a data packet is cannot be processed by
>> the recipient, the sender SHOULD consider the bytestream to be closed
>> and invalid but MAY attempt to correct the error and re-send the
>> offending data packet using the same sequence number (the recipient
>> MUST NOT consider a sequence number to have been used until the data
>> packet has been successfully processed)."
> 
>> The sender must either resend data or explicitly close the stream by
>> sending the "close" query. Otherwise the recipient doesn't know
>> whether the sender wants to resend or not. Right?
> 
> That is my understanding.
> 
In that case I would suggest changing the text a bit for clarity.
IMHO "consider the bytestream to be closed" != "should close the bytestream"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn29aIACgkQ0JXcdjR+9YT1lQCgzPwugwLwZaMo91wSNdxwvtuf
YLUAniop1yPuNMIz95WLyqMT5ZY+9KK2
=tbyw
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 28 08:25:30 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Apr 2009 07:25:30 -0600
Subject: [Standards] Unclarified behavior in
	XEP-0047	(in-band	bytestreams)
In-Reply-To: <49F6F5AA.7020304@gmx.de>
References: <e962983d0904251501y7bb581a7k660fe6a8aba7836d@mail.gmail.com>	<49F6416C.2040603@stpeter.im>
	<49F6F5AA.7020304@gmx.de>
Message-ID: <49F703CA.5040804@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/28/09 6:25 AM, Florian Zeitz wrote:
> Peter Saint-Andre wrote:
>> On 4/25/09 4:01 PM, JiY? Z?rev?ck? wrote:
>>> "Upon receiving notice that a data packet is cannot be processed by
>>> the recipient, the sender SHOULD consider the bytestream to be closed
>>> and invalid but MAY attempt to correct the error and re-send the
>>> offending data packet using the same sequence number (the recipient
>>> MUST NOT consider a sequence number to have been used until the data
>>> packet has been successfully processed)."
>>> The sender must either resend data or explicitly close the stream by
>>> sending the "close" query. Otherwise the recipient doesn't know
>>> whether the sender wants to resend or not. Right?
>> That is my understanding.
> 
> In that case I would suggest changing the text a bit for clarity.
> IMHO "consider the bytestream to be closed" != "should close the bytestream"

Yes, I will clean up the text. I'm currently reviewing XEP-0065 (SOCKS5
Bytestreams), too, as well as the related Jingle specs, so I'll work on
them all at once.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn3A8oACgkQNL8k5A2w/vx6NwCg66JdE40sXOWZ04PZqnIhErGn
akAAn2fRclpk/sgFwj4I4/kXTDBRMAH1
=4wx6
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 28 14:01:02 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Apr 2009 13:01:02 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <6610.1240910800.235191@puncture>
References: <E1LyZBi-0004ej-00@apollo>	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>	<49F6660B.80509@stpeter.im>
	<6610.1240910800.235191@puncture>
Message-ID: <49F7526E.2000608@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/28/09 3:26 AM, Dave Cridland wrote:
> On Tue Apr 28 03:12:27 2009, Peter Saint-Andre wrote:
>> > Also, I think the examples should still have the sequence numbers
>> > (which is I believe preferred implementation). Use of hashes can be
>> > noted in implementation notes.
>>
>> I disagree. The spec says that the version ID is opaque. If the examples
>> include only version IDs that are *not* opaque, developers will ignore
>> the text and focus only on the examples.
>>
>>
> I think he's right - it's impossible to order two hashes, so "real"
> implementations - those capable of producing intermediate pushes - are
> going to use some form of "ver" with strict ordering properties, and the
> simplest way to demonstrate this is with a strictly increasing integer
> sequence, which leaves the examples clear (for instance, in the point 3
> explanatory text of example 3)
> 
> Having other examples which use a hash is also useful, for the minimal
> implementation guidelines.

I'm skeptical about this. People will look at the examples, not the text.

> FWIW, I'd also suggest adding some text guiding implementors, and in
> particular reinstating some text warning against using timestamps.

We already had that text. It's easy enough for me to add it back.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn3Um4ACgkQNL8k5A2w/vxYqgCeI4SDd5yIskxRV7bfRaLhO3nc
H2gAnjieSotfT2wecD+2PuD5cCUjIqL7
=2bM3
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 28 14:05:13 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Apr 2009 13:05:13 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <6610.1240919477.285205@puncture>
References: <E1LyZBi-0004ej-00@apollo>	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>	<49F6660B.80509@stpeter.im>
	<6610.1240910800.235191@puncture>	<49F6E2D6.5040501@darkk.net.ru>
	<6610.1240919477.285205@puncture>
Message-ID: <49F75369.8050205@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/28/09 5:51 AM, Dave Cridland wrote:
> On Tue Apr 28 12:04:54 2009, Leonid Evdokimov wrote:
>> Roster v10: [1 at example.com]
>> Roster v20: [1 at example.com, 2 at example.org]
>> Roster v30: [1 at example.com]
>>
>> Hash(Roster v10) == Hash(Roster v30)
>>
>>
> And this is okay, since a client that says "I have Hash(Roster v10)" has
> the correct roster even if it's actually "Hash(Roster v30)" that the
> server has.

Correct. The client has the same roster that the server has, so the
client now knows that it is up to date. Which is the whole point.

>> I think, this collision contradicts with the letter of the XEP:
>>
>> | The server MUST ensure that each roster modification will result in
>> | a different version and that the version associated with a given
>> | roster modification will be different from version associated with any
>> | previous roster modification for this session
>>
>>
> Yes...

That text now doesn't apply to all implementations -- it was tied to the
strictly-increasing sequence number approach.

>> So, `Hash(Roster)` recommendation in `Implementation Guidelines` should
>> be replaced with something like `Hash(Nonce || Roster)` to follow the
>> letter of the XEP. And I see no good reason to use `Hash` if `Nonce` is
>> used.
> 
> No, I think the text you quote above is wrong.
> 
> Once you allow for Hash(Roster), it's possible to basically drop the
> requirement for unique "ver" for each roster modification, within a
> session or otherwise.

Agreed.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn3U2kACgkQNL8k5A2w/vw28gCg+dOFYeWzzvvLHqtEp5Svbr95
TFwAn1oAcPQfJFlWAbjO/gqQ3yGmzYQA
=dRQr
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Tue Apr 28 15:17:50 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Apr 2009 14:17:50 -0600
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
In-Reply-To: <49F7526E.2000608@stpeter.im>
References: <E1LyZBi-0004ej-00@apollo>	<e962983d0904271627l7000f686g52fa68299ed2616e@mail.gmail.com>	<49F6660B.80509@stpeter.im>	<6610.1240910800.235191@puncture>
	<49F7526E.2000608@stpeter.im>
Message-ID: <49F7646E.2020701@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/28/09 1:01 PM, Peter Saint-Andre wrote:
> On 4/28/09 3:26 AM, Dave Cridland wrote:
>
>> FWIW, I'd also suggest adding some text guiding implementors, and in
>> particular reinstating some text warning against using timestamps.
> 
> We already had that text. It's easy enough for me to add it back.

The previous text was this:

***

An XMPP server cannot guarantee that a timestamp will be strictly
increasing (e.g., the system time might change because of an adjustment
based on an update triggered by the user of the Network Time Protocol
(RFC 958); therefore, because the 'ver' attribute is defined as a
strictly increasing sequence number, server implementations are advised
to employ a method other than timestamps for generation of the 'ver'
attribute.

***

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn3ZG4ACgkQNL8k5A2w/vwewQCggzzMtwyVNPWNAKEkkbI7I1rJ
bQcAniM60ib03OktomsidvhpIuNZXaA3
=ibBR
-----END PGP SIGNATURE-----

From zarevucky.jiri at gmail.com  Tue Apr 28 17:22:46 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 29 Apr 2009 00:22:46 +0200
Subject: [Standards] IBB filetransfer implementations?
Message-ID: <e962983d0904281522p1f835032ie4fa549c33239619@mail.gmail.com>

Well... I don't know whether this is the right place to ask this
question, but is there ANY client that support SI filetransfer via IBB
correctly in the spec's current revision? The closest I found to
functional is Tkabber's unannounced use of messages instead of IQ's
and I'm really tired of devising workarounds for crappy
implementations... I just want to test and debug my implementation
with something working. Is there any?

From will.thompson at collabora.co.uk  Tue Apr 28 18:08:09 2009
From: will.thompson at collabora.co.uk (Will Thompson)
Date: Wed, 29 Apr 2009 00:08:09 +0100
Subject: [Standards] IBB filetransfer implementations?
In-Reply-To: <e962983d0904281522p1f835032ie4fa549c33239619@mail.gmail.com>
References: <e962983d0904281522p1f835032ie4fa549c33239619@mail.gmail.com>
Message-ID: <49F78C59.4000405@collabora.co.uk>

Ji?? Z?rev?ck? wrote:
> Well... I don't know whether this is the right place to ask this
> question, but is there ANY client that support SI filetransfer via IBB
> correctly in the spec's current revision? The closest I found to
> functional is Tkabber's unannounced use of messages instead of IQ's
> and I'm really tired of devising workarounds for crappy
> implementations... I just want to test and debug my implementation
> with something working. Is there any?

telepathy-gabble does IBB as the final fallback if it can't do SOCKS5
with or without a relay.

-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090429/a910a9b7/attachment.pgp>

From zarevucky.jiri at gmail.com  Tue Apr 28 19:28:51 2009
From: zarevucky.jiri at gmail.com (=?ISO-8859-2?B?Smn47SBa4XJldvpja/0=?=)
Date: Wed, 29 Apr 2009 02:28:51 +0200
Subject: [Standards] IBB filetransfer implementations?
In-Reply-To: <49F78C59.4000405@collabora.co.uk>
References: <e962983d0904281522p1f835032ie4fa549c33239619@mail.gmail.com>
	<49F78C59.4000405@collabora.co.uk>
Message-ID: <e962983d0904281728kc3b6b83m3b8c34d9f9e4a454@mail.gmail.com>

2009/4/29 Will Thompson <will.thompson at collabora.co.uk>:
> Ji?? Z?rev?ck? wrote:
>> Well... I don't know whether this is the right place to ask this
>> question, but is there ANY client that support SI filetransfer via IBB
>> correctly in the spec's current revision? The closest I found to
>> functional is Tkabber's unannounced use of messages instead of IQ's
>> and I'm really tired of devising workarounds for crappy
>> implementations... I just want to test and debug my implementation
>> with something working. Is there any?
>
> telepathy-gabble does IBB as the final fallback if it can't do SOCKS5
> with or without a relay.
>

Hmm... Empathy can't connect at all and there is no debug output
whatsoever... any other ideas?

From ml at update.uu.se  Tue Apr 28 23:54:45 2009
From: ml at update.uu.se (Marcus Lundblad)
Date: Wed, 29 Apr 2009 06:54:45 +0200
Subject: [Standards] IBB filetransfer implementations?
In-Reply-To: <e962983d0904281522p1f835032ie4fa549c33239619@mail.gmail.com>
References: <e962983d0904281522p1f835032ie4fa549c33239619@mail.gmail.com>
Message-ID: <1240980885.27728.2.camel@sagittarius>

ons 2009-04-29 klockan 00:22 +0200 skrev Ji?? Z?rev?ck?:
> Well... I don't know whether this is the right place to ask this
> question, but is there ANY client that support SI filetransfer via IBB
> correctly in the spec's current revision? The closest I found to
> functional is Tkabber's unannounced use of messages instead of IQ's
> and I'm really tired of devising workarounds for crappy
> implementations... I just want to test and debug my implementation
> with something working. Is there any?

Pidgin (and other libpurple-based clients) will support it from version
2.6.0.

//Marcus


From nicolas.verite at gmail.com  Wed Apr 29 03:02:48 2009
From: nicolas.verite at gmail.com (=?ISO-8859-1?Q?Nicolas_V=E9rit=E9?=)
Date: Wed, 29 Apr 2009 10:02:48 +0200
Subject: [Standards] XEP-0191: Simple Communications Blocking
Message-ID: <6e2f977f0904290102k623a20edq6905fbc8b533a7aa@mail.gmail.com>

Hi,

XEP-0191: Simple Communications Blocking
http://xmpp.org/extensions/xep-0191.html

IMHO, as a non-english native (o not), the mapping with Privacy lists
(XEP-0016) needs a little bit of clarification:

"A service SHOULD map the blocklist to the default privacy list, where
each blocked JID is represented as a privacy list item of type "jid"
and action "deny". [4] If this is done and none of the user's clients
ever use the privacy lists protocol, then the blocklist will always
apply."

"The priority of blocked (jid+deny) items in the privacy list SHOULD
be such that they come first in the privacy list."

Is it a question of message, presence (in/out) or iq? Or all stanza types?

N?co
-- 
Nicolas V?rit? (N?co) mailto:nicolas.verite at gmail.com
Jabber ID : xmpp:nyco at jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adh?rez ? l'April : http://april.org/

From remko at el-tramo.be  Wed Apr 29 03:23:17 2009
From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=)
Date: Wed, 29 Apr 2009 10:23:17 +0200
Subject: [Standards] XEP-0191: Simple Communications Blocking
In-Reply-To: <6e2f977f0904290102k623a20edq6905fbc8b533a7aa@mail.gmail.com>
References: <6e2f977f0904290102k623a20edq6905fbc8b533a7aa@mail.gmail.com>
Message-ID: <133fd4c60904290123n3b46e8d8pfdf64574f51043d2@mail.gmail.com>

> Is it a question of message, presence (in/out) or iq? Or all stanza types?

Well, it should behave the same as the rules described in the XEP, so
that means all stanza types (see 5.3). I'm not sure repeating the
rules helps much in clarifying that.

cheers,
Remko

From mwild1 at gmail.com  Wed Apr 29 09:51:17 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Wed, 29 Apr 2009 15:51:17 +0100
Subject: [Standards] [Operators] [Fwd: Proposed XMPP Extension: Incident
	Reporting]
In-Reply-To: <49F7DAB1.7070903@stpeter.im>
References: <49F7DAB1.7070903@stpeter.im>
Message-ID: <4db9cacb0904290751l1e3e54fel1ebd2a672a5183d1@mail.gmail.com>

On Wed, Apr 29, 2009 at 5:42 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> FYI. This proposal emerged from discussions among some operators and
> server vendors at XMPP Summit #6 in February...
>

The current proposal doesn't look bad. A few notes follow.

The <solution> and <suggestion> elements should most certainly contain
<ip> elements, the reporter in most cases won't know the IP, except in
the case of suspicious registrations.

Waqas also told me he had reservations about using the server's roster
this way, and overloading presence subscriptions with something they
are not. I'm not really fussed either way, but it would be interesting
to know what others think of this.

It would also be useful to have a way of forwarding reports on to
other servers, perhaps including the originator. Otherwise perhaps we
need a way to ask a "friend" server who they trust, as a means of
bootstrapping our own list.

Suggestion and solution elements could also be present in the initial
report, not sure if the XEP is allowing this, but it should probably
be said explicitly.

One question is whether servers accept reports from unknown servers
when the report relates to users on that server. For reasoning, see
the blog post I wrote a while back at
http://matthewstechnologyblog.blogspot.com/2008/05/jabber-abuse-handling.html
- The idea is that the abuser's login server collects reports from
anyone, and once satisfied that there really is a problem it can act
(either automatically or by notifying the admin).

Matthew.

From stpeter at stpeter.im  Wed Apr 29 10:19:15 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 29 Apr 2009 09:19:15 -0600
Subject: [Standards] secure s2s multiplexing
Message-ID: <49F86FF3.3000000@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe Hildebrand and I have started working on an Internet-Draft that
describes at least the requirements and possibly proposed solutions to
the challenge of securely multiplexing multiple domains over the same
XML stream.

The deployment scenario we have in mind is for a hosting provider or
application service provider to service multiple domains on the same
machine or machines. With the increasing popularity of so-called "cloud
computing", some of these providers service thousands of domains (e.g.,
Google Apps). Because RFC 3920 specifies that each domain-to-domain
"link" shall use two XML streams (one in each direction) and because
currently XMPP has no method by which an existing stream can be re-used
for additional domains, establishing connectivity between two XMPP
"clouds" can quickly necessitate a large number of TCP connections. This
is true even if the clouds have authenticated to each other using TLS
and SASL with digital certificates issued by trusted roots. Therefore we
think it would be desirable to define a method by which two XMPP clouds
could optionally multiplex communications between themselves, so that an
existing domain-to-domain stream could be re-used for additional domains.

We see the following requirements:

    * The multiplexing method must be backwards-compatible with existing
server-to-server connection methods.

    * Each party to a server-to-server communication must be able to
determine if the other party supports multiplexing.

    * If the addition of a new domain to an existing domain-to-domain
stream fails, the existing stream must not be terminated.

    * Multiplexing shall depend on presentation of a valid digital
certificate for the multiplexed domain.

    * The certificate for a multiplexed domain should not be the same
(i.e., have the same subject) as a certificate that has previously been
accepted for the stream; however, if it is the same then it shall
replace the previous certificate with the same subject (e.g., to present
a new certificate with a different expiry time).

    * When a multiplexed domain is accepted for the stream, each name on
the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for
the stream.

    * The protocol used accept the initial certificate for a stream may
be different from the protocol used to accept subsequent ("multiplexed")
domains for the stream.

    * The process of adding a subsequent domain shall not affect
transmission of application data over the stream.

    * If the stream is resumed, all of the certificates that were
accepted for the previous session apply to the resumed session.

    * It is a security violation to proceed with transmission of
application data between two domains if multiplexing for those domains
failed (however, this does not affect domains that have already been
accepted for the stream).

Is that list accurate and complete?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn4b/MACgkQNL8k5A2w/vyJFACgy8MRHFPwHKYIyt46qfPyS7mO
FxIAn37bp7hHvWzImbVAHoIxtv+G8iPD
=5hZ/
-----END PGP SIGNATURE-----


From fippo at goodadvice.pages.de  Wed Apr 29 11:41:16 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Wed, 29 Apr 2009 18:41:16 +0200
Subject: [Standards] secure s2s multiplexing
In-Reply-To: <49F86FF3.3000000@stpeter.im>
References: <49F86FF3.3000000@stpeter.im>
Message-ID: <49F8832C.8010400@goodadvice.pages.de>

Peter Saint-Andre wrote:
> Joe Hildebrand and I have started working on an Internet-Draft that
> describes at least the requirements and possibly proposed solutions to
> the challenge of securely multiplexing multiple domains over the same
> XML stream.

Btw, could you remove the other usage of 'multiplex' from RFC 3921bis?

> The deployment scenario we have in mind is for a hosting provider or
> application service provider to service multiple domains on the same
> machine or machines. With the increasing popularity of so-called "cloud
> computing", some of these providers service thousands of domains (e.g.,
> Google Apps). Because RFC 3920 specifies that each domain-to-domain
> "link" shall use two XML streams (one in each direction) and because
> currently XMPP has no method by which an existing stream can be re-used
> for additional domains, establishing connectivity between two XMPP

The 'd' word.

> "clouds" can quickly necessitate a large number of TCP connections. This
> is true even if the clouds have authenticated to each other using TLS
> and SASL with digital certificates issued by trusted roots. Therefore we
> think it would be desirable to define a method by which two XMPP clouds
> could optionally multiplex communications between themselves, so that an
> existing domain-to-domain stream could be re-used for additional domains.
> 
> We see the following requirements:
> 
>     * The multiplexing method must be backwards-compatible with existing
> server-to-server connection methods.
>     * Each party to a server-to-server communication must be able to
> determine if the other party supports multiplexing.

unidirectional or bidirectional s2s for this? For bidi we need a
reverse-stream:features feature anyway.

>     * If the addition of a new domain to an existing domain-to-domain
> stream fails, the existing stream must not be terminated.

if the addition of a new domain to an existing stream fails, is it
allowed to retry after x minutes?

>     * Multiplexing shall depend on presentation of a valid digital
> certificate for the multiplexed domain.
> 
>     * The certificate for a multiplexed domain should not be the same
> (i.e., have the same subject) as a certificate that has previously been
> accepted for the stream; however, if it is the same then it shall
> replace the previous certificate with the same subject (e.g., to present
> a new certificate with a different expiry time).
> 
>     * When a multiplexed domain is accepted for the stream, each name on
> the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for
> the stream.

This could be nasty with wildcard certificates. Explicit negotiation or
no wildcards?

>     * The protocol used accept the initial certificate for a stream may
> be different from the protocol used to accept subsequent ("multiplexed")
> domains for the stream.

You're mixing up 'certificate' and 'domain'.
* The protocol used [to] exchange(?) the certificate for the initial
   domain on(?) a stream may be different from the protocol to exchange
   the certificates for subsequent ("multiplexed") domains on the stream.

>     * The process of adding a subsequent domain shall not affect
> transmission of application data over the stream.
> 
>     * If the stream is resumed, all of the certificates that were
> accepted for the previous session apply to the resumed session.
> 
>     * It is a security violation to proceed with transmission of
> application data between two domains if multiplexing for those domains
> failed (however, this does not affect domains that have already been
> accepted for the stream).

I think it is ok to kill the stream.

> Is that list accurate and complete?

looks good.

philipp

From alexey.melnikov at isode.com  Wed Apr 29 15:30:12 2009
From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Wed, 29 Apr 2009 21:30:12 +0100
Subject: [Standards] secure s2s multiplexing
In-Reply-To: <49F8832C.8010400@goodadvice.pages.de>
References: <49F86FF3.3000000@stpeter.im>
	<49F8832C.8010400@goodadvice.pages.de>
Message-ID: <49F8B8D4.5000105@isode.com>

Philipp Hancke wrote:

> Peter Saint-Andre wrote:
>
>> Joe Hildebrand and I have started working on an Internet-Draft that
>> describes at least the requirements and possibly proposed solutions to
>> the challenge of securely multiplexing multiple domains over the same
>> XML stream.
>
>
> Btw, could you remove the other usage of 'multiplex' from RFC 3921bis?
>
>> The deployment scenario we have in mind is for a hosting provider or
>> application service provider to service multiple domains on the same
>> machine or machines. With the increasing popularity of so-called "cloud
>> computing", some of these providers service thousands of domains (e.g.,
>> Google Apps). Because RFC 3920 specifies that each domain-to-domain
>> "link" shall use two XML streams (one in each direction) and because
>> currently XMPP has no method by which an existing stream can be re-used
>> for additional domains, establishing connectivity between two XMPP
>
>
> The 'd' word.
>
>> "clouds" can quickly necessitate a large number of TCP connections. This
>> is true even if the clouds have authenticated to each other using TLS
>> and SASL with digital certificates issued by trusted roots. Therefore we
>> think it would be desirable to define a method by which two XMPP clouds
>> could optionally multiplex communications between themselves, so that an
>> existing domain-to-domain stream could be re-used for additional 
>> domains.
>>
>> We see the following requirements:
>>
>>     * The multiplexing method must be backwards-compatible with existing
>> server-to-server connection methods.
>>     * Each party to a server-to-server communication must be able to
>> determine if the other party supports multiplexing.
>
> unidirectional or bidirectional s2s for this? For bidi we need a
> reverse-stream:features feature anyway.

I think this should make the stream bidirectional.

>>     * If the addition of a new domain to an existing domain-to-domain
>> stream fails, the existing stream must not be terminated.
>
> if the addition of a new domain to an existing stream fails, is it
> allowed to retry after x minutes?

Sure, why not.

>>     * Multiplexing shall depend on presentation of a valid digital
>> certificate for the multiplexed domain.
>>
>>     * The certificate for a multiplexed domain should not be the same
>> (i.e., have the same subject) as a certificate that has previously been
>> accepted for the stream; however, if it is the same then it shall
>> replace the previous certificate with the same subject (e.g., to present
>> a new certificate with a different expiry time).
>
PSA: I am not sure why this is a requirement. I think this is a part of 
the solution you and Joe have in mind.

>>     * When a multiplexed domain is accepted for the stream, each name on
>> the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for
>> the stream.
>
> This could be nasty with wildcard certificates. Explicit negotiation or
> no wildcards?

Good question!

>>     * The protocol used accept the initial certificate for a stream may
>> be different from the protocol used to accept subsequent ("multiplexed")
>> domains for the stream.
>
> You're mixing up 'certificate' and 'domain'.
> * The protocol used [to] exchange(?) the certificate for the initial
>   domain on(?) a stream may be different from the protocol to exchange
>   the certificates for subsequent ("multiplexed") domains on the stream.

Right.

>>     * The process of adding a subsequent domain shall not affect
>> transmission of application data over the stream.
>>
>>     * If the stream is resumed, all of the certificates that were
>> accepted for the previous session apply to the resumed session.
>
Hmm, Ok.

>>     * It is a security violation to proceed with transmission of
>> application data between two domains if multiplexing for those domains
>> failed (however, this does not affect domains that have already been
>> accepted for the stream).
>
> I think it is ok to kill the stream.

Agreed.

>> Is that list accurate and complete?
>
> looks good.

Looks good to me too.


From stpeter at stpeter.im  Wed Apr 29 22:13:35 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 29 Apr 2009 21:13:35 -0600
Subject: [Standards] [Fwd: [Council] meeting minutes, 2009-04-29]
Message-ID: <49F9175F.8010209@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Council] meeting minutes, 2009-04-29
Date: Wed, 29 Apr 2009 21:12:30 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Council <council at xmpp.org>
To: XMPP Council <council at xmpp.org>

Results of the XMPP Council meeting held 2009-04-29...

Agenda:

http://mail.jabber.org/pipermail/council/2009-April/002551.html

Log:

http://logs.jabber.org/council at conference.jabber.org/2009-04-29.html

Scribe: Peter Saint-Andre

0. Roll call

Present: Dave Cridland, Ralph Meijer, Jack Moffitt, Peter Saint-Andre,
Kevin Smith.

Absent: None.

Quorum achieved.

1. Agenda bashing

Peter pointed out that Ralph and Jack still need to vote on approving
version 1.8 of XEP-0124.

2. Roster Versioning

Consensus to issue a second Last Call.

3. Advance XEP-0138 (Stream Compression) to Final?

Consensus to issue a Call for Experience.

4. Advance XEP-0199 (XMPP Ping) to Final?

Consensus to issue a Call for Experience.

5. http://xmpp.org/extensions/inbox/instant-gaming.html
6. http://xmpp.org/extensions/inbox/multi-user_gaming.html
7. http://xmpp.org/extensions/inbox/tictactoe.html
8. http://xmpp.org/extensions/inbox/tictactoe-mug.html

Several Council members would like to review these further before
publication, but no major objections were voiced.

9. http://xmpp.org/extensions/inbox/incident-reporting.html

Consensus to publish after the authors split the "server buddies"
functionality into a separate proposal.

10. Other business.

Ralph and Jack voted +1 on XEP-0124 v1.8.

Peter mentioned the XMPP Summit (July 20-21 in San Jose, California) and
IETF 75 (July 26-31 in Stockholm).

11. Next meeting.

May 6, 2009, in xmpp:council at conference.jabber.org -- for reminders,
load http://xmpp.org/xsf/XSF.ics

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn5F18ACgkQNL8k5A2w/vyvqQCgtqMRS4FCExUXj5zZ/VydDg0k
GAsAnj/veiUWUdgp6s1P25k56lY8kZb/
=qKBt
-----END PGP SIGNATURE-----

From fippo at goodadvice.pages.de  Thu Apr 30 08:46:44 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Thu, 30 Apr 2009 15:46:44 +0200
Subject: [Standards] secure s2s multiplexing
In-Reply-To: <49F8B8D4.5000105@isode.com>
References: <49F86FF3.3000000@stpeter.im>	<49F8832C.8010400@goodadvice.pages.de>
	<49F8B8D4.5000105@isode.com>
Message-ID: <49F9ABC4.9010707@goodadvice.pages.de>

Alexey Melnikov wrote:
[snip]
>>> We see the following requirements:

One prerequisite: when to multiplex? This might be possible both
out-of-band (same ho:po via SRV) and in-band (subject contained in
certificate).

>>>     * The multiplexing method must be backwards-compatible with existing
>>> server-to-server connection methods.
>>>     * Each party to a server-to-server communication must be able to
>>> determine if the other party supports multiplexing.
>>
>> unidirectional or bidirectional s2s for this? For bidi we need a
>> reverse-stream:features feature anyway.
> 
> I think this should make the stream bidirectional.

If it is bidirectional, who can add new domains? But that is probably
digging too deep already :-)

>>>     * If the addition of a new domain to an existing domain-to-domain
>>> stream fails, the existing stream must not be terminated.
>>
>> if the addition of a new domain to an existing stream fails, is it
>> allowed to retry after x minutes?
> 
> Sure, why not.

An alternative would be that a failure is considered permanent -
blocking communication with that domain - and the remote end notifies
the initiator if this situation changes.

>>>     * Multiplexing shall depend on presentation of a valid digital
>>> certificate for the multiplexed domain.
>>>
>>>     * The certificate for a multiplexed domain should not be the same
>>> (i.e., have the same subject) as a certificate that has previously been
>>> accepted for the stream; however, if it is the same then it shall
>>> replace the previous certificate with the same subject (e.g., to present
>>> a new certificate with a different expiry time).
>>
> PSA: I am not sure why this is a requirement. I think this is a part of 
> the solution you and Joe have in mind.

Might be alternatively solved by removing the domain and re-adding it
with a new certificate? Domain removal is missing from the list btw.

philipp

From editor at xmpp.org  Thu Apr 30 10:46:45 2009
From: editor at xmpp.org (Betsy Chacon)
Date: Thu, 30 Apr 2009 10:46:45 -0500
Subject: [Standards] Patek Phillipe watch models from 2009!
Message-ID: <01444wtnx986AIAQGeditor@xmpp.org>

Why waste your hard-earned money on an expensive watch when you can have the next best thing for a tenth of its price?
http://zokoyotok.cn

So, come visit Diam0nd Reps, the famous watch-portal where thousands of satisfied customers have already found that superb imitation time piece for just a few hundred dollars. 
http://zokoyotok.cn

Get ready to feel like a kid in a candy store when you see our incredible collection of fine reproduction timepieces at Diam0nd Reps! Come on, get started now!






From dave at cridland.net  Thu Apr 30 09:53:36 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 15:53:36 +0100
Subject: [Standards] Patek Phillipe watch models from 2009!
In-Reply-To: <01444wtnx986AIAQGeditor@xmpp.org>
References: <01444wtnx986AIAQGeditor@xmpp.org>
Message-ID: <27992.1241103216.739049@puncture>

On Thu Apr 30 16:46:45 2009, Betsy Chacon wrote:
> Why waste your hard-earned money on an expensive watch when you can  
> have the next best thing for a tenth of its price?

This new XEP Editor isn't as good as the old one. Come back, Peter!  
All is forgiven!

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Thu Apr 30 10:05:34 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 09:05:34 -0600
Subject: [Standards] Patek Phillipe watch models from 2009!
In-Reply-To: <27992.1241103216.739049@puncture>
References: <01444wtnx986AIAQGeditor@xmpp.org>
	<27992.1241103216.739049@puncture>
Message-ID: <49F9BE3E.8060607@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/30/09 8:53 AM, Dave Cridland wrote:
> On Thu Apr 30 16:46:45 2009, Betsy Chacon wrote:
>> Why waste your hard-earned money on an expensive watch when you can
>> have the next best thing for a tenth of its price?
> 
> This new XEP Editor isn't as good as the old one. Come back, Peter! All
> is forgiven!

Sigh, now I've had to mod editor at xmpp.org. What is the world coming to?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn5vj4ACgkQNL8k5A2w/vz3ggCggT2sZY+IsS1kS1TDHouiH36g
264An2FOqclTtimmhpAwtfxxfRzE43jR
=KAiT
-----END PGP SIGNATURE-----

From dave at cridland.net  Thu Apr 30 10:26:43 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 16:26:43 +0100
Subject: [Standards] Patek Phillipe watch models from 2009!
In-Reply-To: <49F9BE3E.8060607@stpeter.im>
References: <01444wtnx986AIAQGeditor@xmpp.org>
	<27992.1241103216.739049@puncture> <49F9BE3E.8060607@stpeter.im>
Message-ID: <27992.1241105203.547099@puncture>

On Thu Apr 30 16:05:34 2009, Peter Saint-Andre wrote:
> Sigh, now I've had to mod editor at xmpp.org. What is the world coming  
> to?

Well, Betsy was a nice enough girl, but I for one am glad you're back.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter at stpeter.im  Thu Apr 30 11:13:27 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:13:27 -0600
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
Message-ID: <49F9CE27.3030500@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0138 (Stream Compression), in preparation for
perhaps advancing this specification from Draft to Final in the XSF's
standards process. To help the Council decide whether this XEP is ready
to advance to a status of Final, the Council would like to gather the
following information:

1. Who has implemented XEP-0138? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0138? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0138 clear and unambiguous? Are more examples
necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0138 from Draft to Final in
the XSF's standards process, please provide them by the close of
business on Friday, May 22, 2009. After the Call for Experience, this
XEP might undergo revisions to address feedback received, after which it
will be presented to the XMPP Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0138.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn5zicACgkQNL8k5A2w/vwJfQCgtw5FKjjRcaunBXdpJ845VA75
w1gAoOxr8rg37H9W3dWwT2PkqObQ+AFi
=tbSK
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Thu Apr 30 11:16:40 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:16:40 -0600
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
Message-ID: <49F9CEE8.8090603@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0199 (XMPP Ping), in preparation for perhaps
advancing this specification from Draft to Final in the XSF's standards
process. To help the Council decide whether this XEP is ready to advance
to a status of Final, the Council would like to gather the following
information:

1. Who has implemented XEP-0199? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0199? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0199 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0199 from Draft to Final,
please provide them by the close of business on Friday, May 22, 2009.
After the Call for Experience, this XEP might undergo revisions to
address feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0199.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn5zugACgkQNL8k5A2w/vwn3wCfb0P0HVvQ/SxAqeRTQBj3Vy3L
TX4AoKRQpG2JaIp3SYtuKP0X6JwKQqX1
=hEVe
-----END PGP SIGNATURE-----

From editor at xmpp.org  Thu Apr 30 10:59:35 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 30 Apr 2009 10:59:35 -0500
Subject: [Standards] UPDATED: XEP-0124 (Bidirectional-streams Over
	Synchronous HTTP (BOSH))
Message-ID: <E1LzYff-0008Sy-00@apollo>

Version 1.8 of XEP-0124 (Bidirectional-streams Over Synchronous HTTP (BOSH)) has been released.

Abstract: This specification defines a transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or chunked responses.

Changelog: Removed secure attribute because it did not solve the problem it was intended to solve; added security consideration regarding link between connection manager and application server; changed "stanza" to "payload" for disambiguation with XMPP; clarified design objectives and relationship to similar technologies; corrected several errors in the schema. (psa/jm)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0124.xml?%40diffMode=u&%40diffWrap=s&r1=2469&r2=3105&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0124.html


From dave at cridland.net  Thu Apr 30 11:30:03 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 17:30:03 +0100
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
In-Reply-To: <49F9CE27.3030500@stpeter.im>
References: <49F9CE27.3030500@stpeter.im>
Message-ID: <27992.1241109003.466326@puncture>

On Thu Apr 30 17:13:27 2009, Peter Saint-Andre wrote:
> 1. Who has implemented XEP-0138? Please note that the protocol must  
> be
> implemented in at least two separate codebases (and preferably  
> more).
> 
> 
Isode have implemented this in Isode M-Link for some time, basing it  
off the very similar code used (and interop-tested) in IMAP  
COMPRESS=DEFLATE extension support in the M-Box product.

The code appears to work successfully against a number of  
implementations we've had nothing to do with at all. These have been  
mostly on C2S connections, although we do self-interop on S2S  
sessions.


> 2. Have developers experienced any problems with the protocol as  
> defined
> in XEP-0138? If so, please describe the problems and, if possible,
> suggested solutions.
> 
> 
The only minor niggle is that it uses the zlib file format instead of  
the marginally smaller, and more fitting, "raw" deflate blocks.  
However, this doesn't represent a serious problem.

> 3. Is the text of XEP-0138 clear and unambiguous? Are more examples
> necessary? Is the conformance language (MAY/SHOULD/MUST)  
> appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

I found it clearly written, and had no difficulty writing an  
implementation based on it which subsequently proved to interoperate  
with other, independently written, implementations.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave at cridland.net  Thu Apr 30 14:59:55 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 20:59:55 +0100
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
In-Reply-To: <49F9CEE8.8090603@stpeter.im>
References: <49F9CEE8.8090603@stpeter.im>
Message-ID: <3708.1241121595.513943@puncture>

On Thu Apr 30 17:16:40 2009, Peter Saint-Andre wrote:
> 1. Who has implemented XEP-0199? Please note that the protocol must  
> be
> implemented in at least two separate codebases (and preferably  
> more).

Isode M-Link has implemented XEP-0199 for some time, both responding  
cleanly to pings, and sending them to actively check for "ghosted"  
client connections as part of its timeout strategy. Both these pings  
have been tested for interoperability with existing clients claiming  
to support XEP-0199, and we have found no issues.

> 2. Have developers experienced any problems with the protocol as  
> defined
> in XEP-0199? If so, please describe the problems and, if possible,
> suggested solutions.

There exist a number of clients, often on mobile devices, which do  
not respond to unknown <iq/> stanzas, in violation of RFC 3920. This  
can cause servers using pings to detect unresponsive clients to  
disconnect clients which are actually live.

Whilst it's obviously not the place of this specification to fix this  
problem - if these client authors are ignoring RFC 3920 anyway  
they'll hardly conform to this - it may be useful to note this issue.

> 3. Is the text of XEP-0199 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?  
> Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

Just prior to Example 15, there is a MUST which repeats a requirement  
in RFC 3920. Instead, I suggest replacing this with:

"If the pinged entity does not support the ping namespace, RFC 3920  
requires it to return a <service-unavailable/> stanza error."

There is a similar case with the first MUST in the Security  
Considerations.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From remko at el-tramo.be  Thu Apr 30 15:00:39 2009
From: remko at el-tramo.be (=?UTF-8?Q?Remko_Tron=C3=A7on?=)
Date: Thu, 30 Apr 2009 22:00:39 +0200
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
In-Reply-To: <49F9CE27.3030500@stpeter.im>
References: <49F9CE27.3030500@stpeter.im>
Message-ID: <133fd4c60904301300p3c9bd501waf14ee8ebf8aeea9@mail.gmail.com>

> 1. Who has implemented XEP-0138? Please note that the protocol must be
> implemented in at least two separate codebases (and preferably more).

I implemented it in Psi, and reimplemented it from scratch in Swift.
So that's 2 implementations ;-)

> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0138? If so, please describe the problems and, if possible,
> suggested solutions.

The protocol itself is simple enough to not have problems with. I
tested the compression part itself with several server
implementations, and had no problems. Except for Openfire. It used to
work fine up to a certain version, and after that it went wrong. The
stream starts out fine, but after a while gets scrambled, typically
after a burst of stanzas. Smells like a buffer overrun.

Given that the problem occurs in both of my independent
implementations, and that the Swift version is 20 lines of code that i
checked over and over (I even have a unit test to test overruns of the
compression buffer), and that I never have the problem with another
server, and that the problem started suddenly appearing, I tend to
think the problem is with Openfire.

> 3. Is the text of XEP-0138 clear and unambiguous? Are more examples
> necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

I don't recall any confusion over the protocol.

cheers,
Remko

From js-xmpp-standards at webkeks.org  Thu Apr 30 15:09:39 2009
From: js-xmpp-standards at webkeks.org (Jonathan Schleifer)
Date: Thu, 30 Apr 2009 22:09:39 +0200
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
In-Reply-To: <3708.1241121595.513943@puncture>
References: <49F9CEE8.8090603@stpeter.im>
	<3708.1241121595.513943@puncture>
Message-ID: <20090430220939.4fcfa8f2@webkeks.org>

Dave, are you sure sending pings for keepalive is a good idea? This
generates a lot of traffic for mobile devices. Normally, a TCP
keepalive or - if not available - sending a space should be sufficient.

IMO, pinging should be used to get to know the latency, not as a
keepalive.

-- 
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090430/4f86dac8/attachment.pgp>

From fabio.forno at gmail.com  Thu Apr 30 15:16:20 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Thu, 30 Apr 2009 22:16:20 +0200
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
In-Reply-To: <133fd4c60904301300p3c9bd501waf14ee8ebf8aeea9@mail.gmail.com>
References: <49F9CE27.3030500@stpeter.im>
	<133fd4c60904301300p3c9bd501waf14ee8ebf8aeea9@mail.gmail.com>
Message-ID: <2fd53c3a0904301316g7fe177e6o206cc9c94c12aefb@mail.gmail.com>

2009/4/30 Remko Tron?on <remko at el-tramo.be>:
>> 1. Who has implemented XEP-0138? Please note that the protocol must be
>> implemented in at least two separate codebases (and preferably more).
>
> I implemented it in Psi, and reimplemented it from scratch in Swift.
> So that's 2 implementations ;-)

One more implementation is Lampiro, so it works also with the most
sluggish mobile platform, i.e. j2me.

>> 2. Have developers experienced any problems with the protocol as defined
>> in XEP-0138? If so, please describe the problems and, if possible,
>> suggested solutions.
>
> The protocol itself is simple enough to not have problems with. I
> tested the compression part itself with several server
> implementations, and had no problems. Except for Openfire. It used to
> work fine up to a certain version, and after that it went wrong. The
> stream starts out fine, but after a while gets scrambled, typically
> after a burst of stanzas. Smells like a buffer overrun.

[...]

I confirm the problem related to Openfire implementation, with all
other test servers it is a piece of cake

>
>> 3. Is the text of XEP-0138 clear and unambiguous? Are more examples
>> necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate?
>> Have developers found the text confusing at all? Please describe any
>> suggestions you have for improving the text.
>
> I don't recall any confusion over the protocol.

I've just a problem with the business rules, specifically these ones

# TLS compression and stream compression SHOULD NOT be used simultaneously.
# If both TLS (whether including TLS compression or not) and stream
compression are used, then TLS MUST be negotiated first, followed by
negotiation of stream compression.

The above business rules don't forbid but discourage to fall back to
stream compression after TLS has been established but no compression
has been activated. I see no harm in telling that stream compression
MAY be offered after TLS if TLS doesn't succeed in activating
compression (so far we haven't been able to to it with any server)

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From dave at cridland.net  Thu Apr 30 15:30:58 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 21:30:58 +0100
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
In-Reply-To: <20090430220939.4fcfa8f2@webkeks.org>
References: <49F9CEE8.8090603@stpeter.im> <3708.1241121595.513943@puncture>
	<20090430220939.4fcfa8f2@webkeks.org>
Message-ID: <3708.1241123458.384747@puncture>

On Thu Apr 30 21:09:39 2009, Jonathan Schleifer wrote:
> Dave, are you sure sending pings for keepalive is a good idea? This
> generates a lot of traffic for mobile devices. Normally, a TCP
> keepalive or - if not available - sending a space should be  
> sufficient.
> 
> 
We use TCP keepalives in our IMAP product, M-Box, which is heavily  
geared toward (and heavily used by) the mobile email industry, and  
we've a number of issues with them, not least they're insufficiently  
controllable in most operating systems, hence we moved to untagged OK  
responses, instead. The size difference between a TCP keepalive  
packet and an untagged OK isn't actually that much, and all operating  
systems allow precise control of when we send the latter, of course.

With XMPP, XEP-0199 provided a much cleaner option, but we only use  
these after a reasonably lengthy time has elapsed with nothing at all  
from the remote end - about five minutes, in fact - and even then, we  
send two, one minute apart, and timeout only when the first is  
outstanding by over two minutes.

We also use whitespace more frequently in order to (attempt to)  
defeat NATs, however several mobile networks appear to have vastly  
increased NAT timeout, as well as survivability of TCP sessions for  
out-of-range devices, so I'm strongly considering a corresponding  
increase in timeouts.

So we're using XEP-0199 explicitly to provoke clients into a  
response, to ensure they're still actually present, and that only  
after they've been silent long enough for us to consider the  
possibility they're actually ghosts.

By way of completeness, incidentally:

1) The operating system gives no feedback from the result of a TCP  
keepalive operation, and indeed doesn't tell you they've even occured.

2) In the mobile environment, where this is particularly needed,  
things are even less useful, since the GSM gateways can, and often  
do, acknowledge data even if the handset is out of range, so the  
keepalive actvity never goes across the air, and never tells you  
anything useful (even if the OS would tell you).

> IMO, pinging should be used to get to know the latency, not as a
> keepalive.

Well, we're absolutely not using them as a keepalive, we're using  
them as a connectivity probe, which I think is an entirely reasonable  
usage, and arguably much better usage than latency measurement.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From editor at xmpp.org  Thu Apr 30 15:46:34 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 30 Apr 2009 15:46:34 -0500
Subject: [Standards] NEW: XEP-0267 (Server Rosters)
Message-ID: <E1Lzd9O-0002IL-00@apollo>

Version 0.1 of XEP-0267 (Server Rosters) has been released.

Abstract: This specification defines a convention for trust between XMPP server deployments.

Changelog: Initial published version. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0267.html


From editor at xmpp.org  Thu Apr 30 15:46:40 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 30 Apr 2009 15:46:40 -0500
Subject: [Standards] NEW: XEP-0268 (Incident Reporting)
Message-ID: <E1Lzd9U-0002IU-00@apollo>

Version 0.1 of XEP-0268 (Incident Reporting) has been released.

Abstract: This specification defines methods for incident reporting among XMPP server deployments.

Changelog: Initial published version. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0268.html


From fabio.forno at gmail.com  Thu Apr 30 15:50:47 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Thu, 30 Apr 2009 22:50:47 +0200
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
In-Reply-To: <2fd53c3a0904301316g7fe177e6o206cc9c94c12aefb@mail.gmail.com>
References: <49F9CE27.3030500@stpeter.im>
	<133fd4c60904301300p3c9bd501waf14ee8ebf8aeea9@mail.gmail.com>
	<2fd53c3a0904301316g7fe177e6o206cc9c94c12aefb@mail.gmail.com>
Message-ID: <2fd53c3a0904301350o14e9a022xef3ce4a746437849@mail.gmail.com>

On Thu, Apr 30, 2009 at 10:16 PM, Fabio Forno <fabio.forno at gmail.com> wrote:
> I've just a problem with the business rules, specifically these ones
>
> # TLS compression and stream compression SHOULD NOT be used simultaneously.
> # If both TLS (whether including TLS compression or not) and stream
> compression are used, then TLS MUST be negotiated first, followed by
> negotiation of stream compression.
>
> The above business rules don't forbid but discourage to fall back to
> stream compression after TLS has been established but no compression
> has been activated. I see no harm in telling that stream compression
> MAY be offered after TLS if TLS doesn't succeed in activating
> compression (so far we haven't been able to to it with any server)

Just had an IM coversation with Dave about that. I completely misread
the rules skipping the word "TLS *compression*" in the first rule, so
the rules work, sorry.

There only one possible improvement in the second rule, which better
clarifies  when using stream compression: Stream compression MAY be
offered after TLS negotiation if TLS compression fails (it sounds more
as a recipe for users)

bye

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From mwild1 at gmail.com  Thu Apr 30 15:53:35 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Thu, 30 Apr 2009 21:53:35 +0100
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
In-Reply-To: <49F9CEE8.8090603@stpeter.im>
References: <49F9CEE8.8090603@stpeter.im>
Message-ID: <4db9cacb0904301353h667f844do23d1f9cb803bd8d5@mail.gmail.com>

On Thu, Apr 30, 2009 at 5:16 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>
> In its meeting yesterday, the XMPP Council agreed to issue a "Call for
> Experience" regarding XEP-0199 (XMPP Ping), in preparation for perhaps
> advancing this specification from Draft to Final in the XSF's standards
> process. To help the Council decide whether this XEP is ready to advance
> to a status of Final, the Council would like to gather the following
> information:
>
> 1. Who has implemented XEP-0199? Please note that the protocol must be
> implemented in at least two separate codebases (and preferably more).
>

We have implemented it in Prosody. We don't actively use it (yet) but
correctly answer pings from clients and other servers.

We are discussing using XMPP pings to check s2s connections are still
working prior to sending data after a long period of silence. As Dave
writes, relying on TCP is not enough for various reasons.

We also intend to use it to ping clients prior to replacing them in a
resource conflict.

> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0199? If so, please describe the problems and, if possible,
> suggested solutions.
>

No problems.

> 3. Is the text of XEP-0199 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
>

Happy with it, short and sweet. I'm in favour of the changes Dave
highlighted too.

> If you have any comments about advancing XEP-0199 from Draft to Final,
> please provide them by the close of business on Friday, May 22, 2009.
> After the Call for Experience, this XEP might undergo revisions to
> address feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
>

Go!

Matthew.

From dave at cridland.net  Thu Apr 30 15:56:55 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 21:56:55 +0100
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
In-Reply-To: <4db9cacb0904301353h667f844do23d1f9cb803bd8d5@mail.gmail.com>
References: <49F9CEE8.8090603@stpeter.im>
	<4db9cacb0904301353h667f844do23d1f9cb803bd8d5@mail.gmail.com>
Message-ID: <3708.1241125015.154468@puncture>

On Thu Apr 30 21:53:35 2009, Matthew Wild wrote:
> We also intend to use it to ping clients prior to replacing them in  
> a
> resource conflict.

Oh, yeah, we do that too. FWIW, it's a splendid way of handling  
resource conflicts, appears to have no nasty ping-pong failure cases,  
and essentially works exactly as users expect.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From editor at xmpp.org  Thu Apr 30 16:56:22 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 30 Apr 2009 16:56:22 -0500
Subject: [Standards] UPDATED: XEP-0237 (Roster Versioning)
Message-ID: <E1LzeEw-0002n6-00@apollo>

Version 0.11 of XEP-0237 (Roster Versioning) has been released.

Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not been modified, thus saving bandwidth during session establishment.

Changelog: Added implementation guidelines. (dc/psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0237.xml?%40diffMode=u&%40diffWrap=s&r1=3097&r2=3111&u=3&ignore=&k=

URL: http://xmpp.org/extensions/xep-0237.html


From editor at xmpp.org  Thu Apr 30 16:57:31 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 30 Apr 2009 16:57:31 -0500
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
Message-ID: <E1LzeG3-0002nT-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0237 (Roster Versioning).

Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not been modified, thus saving bandwidth during session establishment.

URL: http://www.xmpp.org/extensions/xep-0237.html

This Last Call begins today and shall end at the close of business on 2009-05-15.

Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

From stpeter at stpeter.im  Thu Apr 30 16:59:07 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 15:59:07 -0600
Subject: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
In-Reply-To: <E1LzeG3-0002nT-00@apollo>
References: <E1LzeG3-0002nT-00@apollo>
Message-ID: <49FA1F2B.6050201@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a second Last Call to ensure that feedback received during the
first Last Call has been incorporated correctly.

/psa

On 4/30/09 3:57 PM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0237 (Roster Versioning).
> 
> Abstract: This specification defines a proposed modification to the
> XMPP roster protocol that enables versioning of rosters such that the
> server will not send the roster to the client if the roster has not
> been modified, thus saving bandwidth during session establishment.
> 
> URL: http://www.xmpp.org/extensions/xep-0237.html
> 
> This Last Call begins today and shall end at the close of business on
> 2009-05-15.
> 
> Please consider the following questions during this Last Call and
> send your feedback to the standards at xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol? 2. Does the specification
> solve the problem stated in the introduction and requirements? 3. Do
> you plan to implement this specification in your code? If not, why
> not? 4. Do you have any security concerns related to this
> specification? 5. Is the specification accurate and clearly written?
> 
> Your feedback is appreciated!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn6HysACgkQNL8k5A2w/vx3cgCeOqc2uICQOtxOSlW6Rg+7AZ3e
f8oAoM9YgJIE5NtlCqK6JQpN/qlu4ZTq
=7WLy
-----END PGP SIGNATURE-----

From bogus@does.not.exist.com  Fri Apr 17 08:10:01 2009
From: bogus@does.not.exist.com ()
Date: Fri, 17 Apr 2009 13:10:01 -0000
Subject: No subject
Message-ID: <mailman.0.1242302360.16993.standards@xmpp.org>

1) Hashes are too hard to implement
2) Hashes in the examples make the examples too hard to follow

vs.

1) Integers in the examples may mislead implementors regarding
    the opacity of 'ver'

As a compromise how about making the ver in the examples something
like: 'r1', 'r2', 'r3'. Possibly changing 'r' in each example, just to
be absolutely certain :)

At the end of the day, as I have said before, I'm not really fussed
either way. I think we should give developers more credit, they aren't
all incapable of reading specifications.

Matthw