From dmeyer at tzi.de  Thu Oct  1 06:26:20 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 01 Oct 2009 13:26:20 +0200
Subject: [Standards] [Jingle] Fwd: Application referrals - GROBJ
In-Reply-To: <9555.1254345549.761395@puncture> (Dave Cridland's message of
	"Wed, 30 Sep 2009 22:19:09 +0100")
References: <9555.1254345549.761395@puncture>
Message-ID: <87hbujicdf.fsf@tzi.de>

Dave Cridland wrote:
> FYI, I thought this might be interesting from the point of view of
> XMPP/Jingle, whether filesharing or VOIP or whatever.
>
> It's also got an impressive sounding name.

I have no time to read the draft right now, but isn't that the reason we
have HIP (Host Identification Protocol)?


Dirk

-- 
It's the same old story; boy meets beer, boy drinks beer... boy gets
another beer.
		-- Cheers

From okrammarko at gmail.com  Thu Oct  1 10:33:54 2009
From: okrammarko at gmail.com (Marko A. Rodriguez)
Date: Thu, 1 Oct 2009 09:33:54 -0600
Subject: [Standards] Proposed XMPP Extension: Linked Process Protocol
In-Reply-To: <9555.1254347384.510626@puncture>
References: <3900026D08C347E5B27CCCAD4EB9303D@movsoftware.com>
	<03DE8AEB-D58B-4DC6-8720-7419088F6DDA@gmail.com>
	<9555.1254347384.510626@puncture>
Message-ID: <BF0D39F3-C67B-4798-8CAB-1C181E6ED032@gmail.com>

Hi Dave,

I think Moffitt was pitching this model to me over lunch a few moons  
ago. Moreover, I believe we concluded that this is not a good model  
because it requires people that want to run farms to have server  
access (running their own XMPP server) ??

With Linked Process, we want any "Joe Schmo" to be able to run a farm  
and allow people to use their laptop/cellphone/desktop/etc. to compute  
with. We want people to be able to use their gmail GTalk, jabber, etc.  
accounts as well---i.e. ride atop existing XMPP servers/networks. We  
want to make it as easy as possible for anyone to throw up a farm (in  
fact, hopefully, just have Linked Process as a background thread on as  
many machines as possible.)

In this respect, I think, though I'm not hyper-confident (Jack please  
fill in if you remember the context), that your model of  
farm.example.com/someidentifier requires that the farm provider have  
admin access to the underlying XMPP server at example.com. Thus, to  
run a farm means that you are running/admin'ing an XMPP server.

Given this realization (if its true), I saw fit to make a Farm a  
"standard" XMPP client -- as simple as a chat client.

Thoughts?

Marko.

http://markorodriguez.com


On Sep 30, 2009, at 3:49 PM, Dave Cridland wrote:

> On Wed Sep 30 18:26:54 2009, Marko A. Rodriguez wrote:
>> In short, the "environmentid" is needed to state to which  
>> environment  you are altering the state of (which VM you are  
>> altering the state  of). While this could be in the "to=" of the IQ  
>> tag, the farm is the  only XMPP client in the architecture (much  
>> faster/efficient to create  virtual machines without having to log  
>> them into an XMPP server and  flood the network with <presence/> --  
>> and no server components  wanted.). Or it could be in the "<code/>"  
>> tag -- e.g. <code  vm_id="VM-1234"/>??. What are you thoughts on  
>> this "routing" issue?
>
> Two comments.
>
> Firstly, yes, you could stick it as a part of the data. You can  
> stick *anything* as part of the data, and you get to define what it  
> looks like and what it means, so this is the logical place for it.
>
> Secondly, I'm pretty sure you should be modelling this as a  
> component, so a farm becomes, say, farm.example.com, with VMs as someidentifer at farm.example.com 
>  - or possibly farm.example.com/someidentifier.
>
> I'd probably opt for the latter - it allows a single presence  
> subscription (to farm.example.com) to be used to easily process  
> presence between clients and relevent VMs, without cluttering up the  
> model.
>
> So, my account could have a subscription to farm.example.com, but  
> farm.example.com responds to probes by delivering me presence of  
> only those of its resources that model VMs that I actually own.
>
> 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 okrammarko at gmail.com  Thu Oct  1 10:43:21 2009
From: okrammarko at gmail.com (Marko A. Rodriguez)
Date: Thu, 1 Oct 2009 09:43:21 -0600
Subject: [Standards] Proposed XMPP Extension: Linked Process Protocol
In-Reply-To: <4AC3CDEE.8020402@gmx.net>
References: <3900026D08C347E5B27CCCAD4EB9303D@movsoftware.com>
	<03DE8AEB-D58B-4DC6-8720-7419088F6DDA@gmail.com>
	<4AC3CDEE.8020402@gmx.net>
Message-ID: <2A1F8601-C027-4D1C-9798-A7D0DE7BBF01@gmail.com>

Hi Johannes,

What you say feels right.

> I think it is easy to realize your vm farming with IO Data. If you  
> choose to command and control your farms using IO Data to perform  
> your remote control calls, and you also want to have this all as a  
> standard, you could write an XEP that defines: 1.) the IO Data based  
> functionnames(API) a VM-farm-service must provide (as exemplified).  
> 2. The XML Schemata these functions must provide for input and  
> output. 3. General instructions how this "VM farming" is working.

Question --- 1 and 2 are clear, but what do you mean by 3? Can you  
please elaborate.

Another Question --- Does IO Data/AdHoc commands assume statelessness.  
What I mean is that, if the same function/procedure is executed twice  
with the same parameters/arguments, is it assumed that the return/ 
result will be the same? Or are such things not decided at the IOData/ 
AdHoc spec level?

Thank you,
Marko.

http://markorodriguez.com

From aliban at gmx.net  Fri Oct  2 15:53:20 2009
From: aliban at gmx.net (aliban at gmx.net)
Date: Fri, 02 Oct 2009 22:53:20 +0200
Subject: [Standards] Proposed XMPP Extension: Linked Process Protocol
In-Reply-To: <2A1F8601-C027-4D1C-9798-A7D0DE7BBF01@gmail.com>
References: <3900026D08C347E5B27CCCAD4EB9303D@movsoftware.com>	<03DE8AEB-D58B-4DC6-8720-7419088F6DDA@gmail.com>	<4AC3CDEE.8020402@gmx.net>
	<2A1F8601-C027-4D1C-9798-A7D0DE7BBF01@gmail.com>
Message-ID: <4AC66840.7010308@gmx.net>

Hi Marko,

Marko A. Rodriguez schrieb:
> Hi Johannes,
>
> What you say feels right.
>
>> I think it is easy to realize your vm farming with IO Data. If you 
>> choose to command and control your farms using IO Data to perform 
>> your remote control calls, and you also want to have this all as a 
>> standard, you could write an XEP that defines: 1.) the IO Data based 
>> functionnames(API) a VM-farm-service must provide (as exemplified). 
>> 2. The XML Schemata these functions must provide for input and 
>> output. 3. General instructions how this "VM farming" is working.
>
> Question --- 1 and 2 are clear, but what do you mean by 3? Can you 
> please elaborate.

In the XEP you proposed you say: "A virtual machine ... can be of any 
"species" (i.e. computer language) ... include JavaScript, Python, Ruby, 
Groovy"

In my opinion it is important to know what the virtual machine expects 
from me as a user. If this (or a way of discovering the *species* of the 
vm) is not specified in the XEP a user cannot know what kind of 
language/code the VM expects. Therefore I was missing a definition of 
what the virtual machine is. And I think it is not enough. It is also 
important to know what kind of API it supports... Do you want the user 
to *upload* the code libraries to a VM before he runs some code on it?

>
> Another Question --- Does IO Data/AdHoc commands assume statelessness. 
> What I mean is that, if the same function/procedure is executed twice 
> with the same parameters/arguments, is it assumed that the 
> return/result will be the same? Or are such things not decided at the 
> IOData/AdHoc spec level?
I would say this is not decided at the IO Data level:

Example,
a service called "coffee-machine.server.example.com" which supports a 
function with the name #getCoffeeCanStatus, which returns the amount of 
coffee in the can. And the can may have a state, full, empty, 55%.. (The 
function #brewNewCoffee would refill the can)


>
> Thank you,
> Marko.
>
> http://markorodriguez.com
>

Thank you

Johannes


From okrammarko at gmail.com  Fri Oct  2 16:09:32 2009
From: okrammarko at gmail.com (Marko A. Rodriguez)
Date: Fri, 2 Oct 2009 15:09:32 -0600
Subject: [Standards] Proposed XMPP Extension: Linked Process Protocol
In-Reply-To: <4AC66840.7010308@gmx.net>
References: <3900026D08C347E5B27CCCAD4EB9303D@movsoftware.com>	<03DE8AEB-D58B-4DC6-8720-7419088F6DDA@gmail.com>	<4AC3CDEE.8020402@gmx.net>
	<2A1F8601-C027-4D1C-9798-A7D0DE7BBF01@gmail.com>
	<4AC66840.7010308@gmx.net>
Message-ID: <EC96C25F-ED77-4105-BA4A-5E8714E1C7E2@gmail.com>

Hi Johannes,

> In the XEP you proposed you say: "A virtual machine ... can be of  
> any "species" (i.e. computer language) ... include JavaScript,  
> Python, Ruby, Groovy"
>
> In my opinion it is important to know what the virtual machine  
> expects from me as a user. If this (or a way of discovering the  
> *species* of the vm) is not specified in the XEP a user cannot know  
> what kind of language/code the VM expects.

The way to discover which virtual machines a farm supports is to do a  
disco#info on the farm.

http://xmpp.org/extensions/inbox/lop.html#sect-id2257047

The disco#info tells you which vm_species are supported, what the  
vm_time_to_live, how long jobs can last, if the farm requires a  
password, etc. etc. The disco#info of the farm tells you (the villein  
developer) all you need to know regarding whether your code will  
successfully execute on that machine.

> Therefore I was missing a definition of what the virtual machine is.  
> And I think it is not enough. It is also important to know what kind  
> of API it supports... Do you want the user to *upload* the code  
> libraries to a VM before he runs some code on it?

The disco#info of a farm tells you which read_files you have access to  
and thus, what preloaded libraries/APIs/packages exist and can be  
utilized. For those that are not supported, you can upload you own  
libraries using submit_job --- but, its important that the libraries  
don't violate the security permissions set forth by the farm (e.g.  
socket connections, graphic card access, etc.) --- such permissions,  
again, are all specified in the disco#info of the farm.

Does this makes sense?

Pages 36 through 50 of this pdf might explain it better --- http://markorodriguez.com/Lectures_files/cnls-linkedprocess2009.pdf 
  .

Take care,
Marko.

From editor at xmpp.org  Fri Oct  2 19:34:56 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Fri, 02 Oct 2009 19:34:56 -0500
Subject: [Standards] UPDATED: XEP-0181 (Jingle DTMF)
Message-ID: <E1MtsaO-0008SS-00@apollo>

Version 0.12 of XEP-0181 (Jingle DTMF) has been released.

Abstract: This specification defines an XML format for encapsulating Dual Tone Multi-Frequency (DTMF) events in informational messages sent within the context of Jingle audio sessions, e.g. to be used in the context of Interactive Voice Response (IVR) systems. Note well that this format is not to be used in the context of RTP sessions, where native RTP methods are to be used instead.

Changelog: Corrected definitions and schema to make it clear that the code attribute contains one and only one character representing a DTMF tone. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0181.xml?r1=2257&r2=3489

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


From editor at xmpp.org  Mon Oct  5 17:41:57 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Mon, 05 Oct 2009 17:41:57 -0500
Subject: [Standards] UPDATED: XEP-0251 (Jingle Session Transfer)
Message-ID: <E1MuwFh-0001u6-00@apollo>

Version 0.2 of XEP-0251 (Jingle Session Transfer) has been released.

Abstract: This specification defines an extension to XMPP Jingle for transferring a session (such as a voice call) from one person to another.

Changelog: Updated examples; added reference to RFC 5359; added security considerations regarding unattended transfer. (psa)

Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0251.xml?r1=3251&r2=3494

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


From okrammarko at gmail.com  Thu Oct  8 15:27:01 2009
From: okrammarko at gmail.com (Marko A. Rodriguez)
Date: Thu, 8 Oct 2009 14:27:01 -0600
Subject: [Standards] Update on Linked Process
Message-ID: <797407E8-FBB4-4C22-825C-5AD2E7963C5C@gmail.com>

Hi everyone,

For those that are interested, we recently released LoPSideD-proto  
v0.1 [ http://code.google.com/p/linkedprocess/ --- http://linkedprocess.org/lopsided/api/ 
  ]. This is a Java implementation of the Linked Process protocol. The  
"proto" refers to the fact that it implements the ProtoXEP version  
currently located at http://xmpp.org/extensions/inbox/lop.html .

The next steps we have with respect to the protocol are these:

1. Represent the Linked Process commands on top of IO Data [ http://xmpp.org/extensions/xep-0244.html 
  ].
	- this seems the most natural fit for the "commands" aspect of Linked  
Process.


2. Provide a efficient, language/library-agnostic way to allow inter- 
virtual machine communication.
	- specify a mechanism for virtual machines to initiate messages  
without requiring languages specific XMPP libraries to be loaded in  
the virtual machines.
	- in combination with its other features, this will allow Linked  
Process to simulate both WebService/RPC-based models of distributed  
computing and MPI/PVM-based models of distributed computing.


3. Work with an XMPP expert to ensure that our curent "disco#info"  
model for getting the permissions of a farm is acceptable.
	- given the importance that the disco#info of a farm plays in  
determining the resources and permissions someone has on a foreign  
machine, making this efficient, extensible, and natural is important.  
If the current model is not appropriate, finding the most appropriate  
way to represent this is necessary.


4. Tweak the protocol as other useful insights come out of this process.
	- we will continue to articulate novel use cases where Linked Process  
shines and work with groups interested in making use of Linked Process  
in their projects. Hopefully, with the contributions of others, we can  
find more use cases and possible additions/simplifications to the  
protocol.

With all that, we will provide another version of LoPSideD the  
implements all the changes to the protocol.

Take care,
Marko.

http://markorodriguez.com
http://linkedprocess.org




From dave at cridland.net  Thu Oct  8 16:48:29 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 08 Oct 2009 22:48:29 +0100
Subject: [Standards] Update on Linked Process
In-Reply-To: <797407E8-FBB4-4C22-825C-5AD2E7963C5C@gmail.com>
References: <797407E8-FBB4-4C22-825C-5AD2E7963C5C@gmail.com>
Message-ID: <23691.1255038509.175119@puncture>

On Thu Oct  8 21:27:01 2009, Marko A. Rodriguez wrote:
> 3. Work with an XMPP expert to ensure that our curent "disco#info"   
> model for getting the permissions of a farm is acceptable.
> 	- given the importance that the disco#info of a farm plays in   
> determining the resources and permissions someone has on a foreign   
> machine, making this efficient, extensible, and natural is  
> important.  If the current model is not appropriate, finding the  
> most appropriate  way to represent this is necessary.
> 
> 
It would be great if you just throw ideas out here - I'm sure you'll  
end up with the best model if you use the whole mailing list.

> With all that, we will provide another version of LoPSideD the   
> implements all the changes to the protocol.

I'm looking forward to 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 editor at xmpp.org  Thu Oct  8 22:53:59 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 08 Oct 2009 22:53:59 -0500
Subject: [Standards] DEFERRED: XEP-0152 (Reachability Addresses)
Message-ID: <E1Mw6YJ-0000EH-00@apollo>

XEP-0152 (Reachability Addresses) has been Deferred because of inactivity.

Abstract: This document defines an XMPP protocol extension for communicating reachability information related to non-XMPP devices.

URL: http://www.xmpp.org/extensions/xep-0152.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 Oct  8 22:54:05 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 08 Oct 2009 22:54:05 -0500
Subject: [Standards] DEFERRED: XEP-0186 (Invisible Command)
Message-ID: <E1Mw6YP-0000EQ-00@apollo>

XEP-0186 (Invisible Command) has been Deferred because of inactivity.

Abstract: This document specifies an XMPP-compatible protocol for user invisibility.

URL: http://www.xmpp.org/extensions/xep-0186.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 Oct  8 22:54:09 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Thu, 08 Oct 2009 22:54:09 -0500
Subject: [Standards] DEFERRED: XEP-0225 (Component Connections)
Message-ID: <E1Mw6YT-0000Ea-00@apollo>

XEP-0225 (Component Connections) has been Deferred because of inactivity.

Abstract: This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers.

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

If and when a new revision of this XEP is published, its status will be changed back to Experimental.

From gnauck at ag-software.de  Mon Oct 12 10:21:59 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Mon, 12 Oct 2009 17:21:59 +0200
Subject: [Standards] XSF membership application period Q4/2009
Message-ID: <4AD34997.7010206@ag-software.de>

The XMPP Standards Foundation (XSF) is currently holding its quarterly 
membership application period:
http://wiki.xmpp.org/web/Membership_Applications_October_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 28th October 2009 23:59h UTC, so apply today!

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

From yhe at yhetheridge.org  Mon Oct 12 10:44:58 2009
From: yhe at yhetheridge.org (Young H Etheridge)
Date: Mon, 12 Oct 2009 11:44:58 -0400
Subject: [Standards] XSF membership application period Q4/2009
In-Reply-To: <4AD34997.7010206@ag-software.de>
References: <4AD34997.7010206@ag-software.de>
Message-ID: <4AD34EFA.8000907@yhetheridge.org>

Alex,

Please consider my application to the XSF XMPP wiki.

I would like to be identified by:

Name: Young H. Etheridge
Alias: yhe
E-mail: yhe at yhetheridge.org

Thank you,

yhe

Alexander Gnauck wrote:
> The XMPP Standards Foundation (XSF) is currently holding its quarterly 
> membership application period:
> http://wiki.xmpp.org/web/Membership_Applications_October_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 28th October 2009 23:59h UTC, so apply 
> today!
>
> Regards,
> Alex
> -- 
> Alexander Gnauck
> xmpp:gnauck at jabber.org

From asterix at lagaule.org  Mon Oct 12 15:11:00 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Mon, 12 Oct 2009 22:11:00 +0200
Subject: [Standards] error 503 in MUC
Message-ID: <4AD38D54.5020008@lagaule.org>

When we try to join a room and get such an answer:

<presence from='room at server/nick' to='jid' type='error' id='816'>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>

Does this mean the room is not joinable (it's what XEP86 says)?
Or does this mean maximum number of participant has been reached (it's
ehat XEP45 says)?

I know XEP 86 is deprecated, but at least ejabberd still implement that,
and it returns the exact same answer in both case. I'm not sure which
XEP is wrong, if any ...

-- 
Yann

From joe.hildebrand at webex.com  Mon Oct 12 15:18:36 2009
From: joe.hildebrand at webex.com (Joe Hildebrand)
Date: Mon, 12 Oct 2009 14:18:36 -0600
Subject: [Standards] error 503 in MUC
In-Reply-To: <4AD38D54.5020008@lagaule.org>
Message-ID: <C6F8EB3C.157E2%joe.hildebrand@webex.com>

503 often means a server-to-server delivery problem, too.  Are you sure that
the server you're specifying is reachable from your server?


On 10/12/09 2:11 PM, "Yann Leboulanger" <asterix at lagaule.org> wrote:

> When we try to join a room and get such an answer:
> 
> <presence from='room at server/nick' to='jid' type='error' id='816'>
> <error code='503' type='cancel'>
> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
> </error>
> </presence>
> 
> Does this mean the room is not joinable (it's what XEP86 says)?
> Or does this mean maximum number of participant has been reached (it's
> ehat XEP45 says)?
> 
> I know XEP 86 is deprecated, but at least ejabberd still implement that,
> and it returns the exact same answer in both case. I'm not sure which
> XEP is wrong, if any ...

-- 
Joe Hildebrand


From asterix at lagaule.org  Mon Oct 12 15:43:24 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Mon, 12 Oct 2009 22:43:24 +0200
Subject: [Standards] error 503 in MUC
In-Reply-To: <C6F8EB3C.157E2%joe.hildebrand@webex.com>
References: <C6F8EB3C.157E2%joe.hildebrand@webex.com>
Message-ID: <4AD394EC.9090303@lagaule.org>

Joe Hildebrand wrote:
> 503 often means a server-to-server delivery problem, too.  Are you sure that
> the server you're specifying is reachable from your server?
> 
> 
> On 10/12/09 2:11 PM, "Yann Leboulanger" <asterix at lagaule.org> wrote:
> 
>> When we try to join a room and get such an answer:
>>
>> <presence from='room at server/nick' to='jid' type='error' id='816'>
>> <error code='503' type='cancel'>
>> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>> </error>
>> </presence>
>>
>> Does this mean the room is not joinable (it's what XEP86 says)?
>> Or does this mean maximum number of participant has been reached (it's
>> ehat XEP45 says)?
>>
>> I know XEP 86 is deprecated, but at least ejabberd still implement that,
>> and it returns the exact same answer in both case. I'm not sure which
>> XEP is wrong, if any ...
> 

yep, I'm sur it's available when I get the 503 answer because of max
users. I connected to use a few seconds before when there wwas less
occupants. And in XEP 45 503 is max users:
http://xmpp.org/extensions/xep-0045.html#errorcodes

-- 
Yann

From dave at cridland.net  Tue Oct 13 10:13:09 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 13 Oct 2009 16:13:09 +0100
Subject: [Standards] error 503 in MUC
In-Reply-To: <4AD38D54.5020008@lagaule.org>
References: <4AD38D54.5020008@lagaule.org>
Message-ID: <9001.1255446789.829122@puncture>

On Mon Oct 12 21:11:00 2009, Yann Leboulanger wrote:
> Does this mean the room is not joinable (it's what XEP86 says)?

Yes.


> Or does this mean maximum number of participant has been reached  
> (it's
> ehat XEP45 says)?
> 
> 
Maybe that's the reason it's not joinable.


> I know XEP 86 is deprecated, but at least ejabberd still implement  
> that,
> and it returns the exact same answer in both case. I'm not sure  
> which
> XEP is wrong, if any ...

Or, as Joe says, it might mean the host is unreachable.

Or - maybe - it means the moon is in the seventh phase.

Is anyone interested in defining some sensible error elements for  
XEP-0045?

So this might become:

<presence from='room at server/nick' to='jid' type='error' id='816'>
<error type='cancel'>
<limit-exceeded xmlns='urn:xmpp:muc:errors:0'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>

I know this won't solve your immediate problem, but it'd be nice to  
tidy up MUC a bit, and remove some of the warts it has.

(I'm also up for considering changing <status code='182'/> to  
something meangingful, too - a lot of those are ignored by clients  
right now anyway.)

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 Oct 13 10:15:13 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 13 Oct 2009 09:15:13 -0600
Subject: [Standards] error 503 in MUC
In-Reply-To: <9001.1255446789.829122@puncture>
References: <4AD38D54.5020008@lagaule.org> <9001.1255446789.829122@puncture>
Message-ID: <4AD49981.6030108@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/13/09 9:13 AM, Dave Cridland wrote:

> Is anyone interested in defining some sensible error elements for XEP-0045?
> 
> So this might become:
> 
> <presence from='room at server/nick' to='jid' type='error' id='816'>
> <error type='cancel'>
> <limit-exceeded xmlns='urn:xmpp:muc:errors:0'>
> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
> </error>
> </presence>
> 
> I know this won't solve your immediate problem, but it'd be nice to tidy
> up MUC a bit, and remove some of the warts it has.
> 
> (I'm also up for considering changing <status code='182'/> to something
> meangingful, too - a lot of those are ignored by clients right now anyway.)

IMHO all the error and status codes could be converted from numbers to
something approaching human-readable...

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/

iEYEARECAAYFAkrUmYEACgkQNL8k5A2w/vxBkQCfR4I5Sr89ob4bgBX/OwvkJZgK
RoYAoO4BDcfFlcB4GMEX0kohePr3iNpp
=xFQF
-----END PGP SIGNATURE-----

From okrammarko at gmail.com  Tue Oct 13 10:23:56 2009
From: okrammarko at gmail.com (Marko A. Rodriguez)
Date: Tue, 13 Oct 2009 09:23:56 -0600
Subject: [Standards] Requesting thoughts on disco#info in Linked Process
In-Reply-To: <23691.1255038509.175119@puncture>
References: <797407E8-FBB4-4C22-825C-5AD2E7963C5C@gmail.com>
	<23691.1255038509.175119@puncture>
Message-ID: <09C2F93B-A8AE-4A41-8E09-CED1970DB77A@gmail.com>

Hello people,

I would appreciate some advice concerning our use of disco#info in  
Linked Process (acronym LoP). [ http://xmpp.org/extensions/inbox/lop.html 
  ]

THIS IS A SHORT DESCRIPTION OF LoP: Computing device *A* can run a  
farm. A farm is an XMPP client. Computing device *B* (anonymous  
machine out there in the world) can request that the device *A* farm  
spawn/create a virtual machine (a language interpreter, hardware  
emulator, etc.). Device *B* can then make use of the computing  
resources on device *A* by means of the spawned virtual machine by  
sending code to the virtual machine to execute. [see http://linkedprocess.org/Overview.html 
  ]

PROBLEM: The farm on device *A* can offer various permissions --- for  
example: allow a remote device to open/listen_for socket connections,  
read/write/delete various files/directories, access hardware  
components, other things that we (the protocol designers) can't think  
of --- extensibility required. When remote device *B* wants to run  
some code on the spawned virtual machine at device *A*, it needs to  
first make sure that the code will execute appropriately. To do so, it  
must  make sure that the code will not violate the permissions of the  
farm.

SOLUTION: Currently, to advertise farm permissions, LoP uses  
disco#info. SEE http://xmpp.org/extensions/inbox/lop.html#sect- 
id2257047 .

With respects to XMPP, Is this the best way to do such things?

Thank you for your time,
Marko.

http://markorodriguez.com
http://linkedprocess.org

On Oct 8, 2009, at 3:48 PM, Dave Cridland wrote:

> On Thu Oct  8 21:27:01 2009, Marko A. Rodriguez wrote:
>> 3. Work with an XMPP expert to ensure that our curent "disco#info"   
>> model for getting the permissions of a farm is acceptable.
>> 	- given the importance that the disco#info of a farm plays in   
>> determining the resources and permissions someone has on a foreign   
>> machine, making this efficient, extensible, and natural is  
>> important.  If the current model is not appropriate, finding the  
>> most appropriate  way to represent this is necessary.
> It would be great if you just throw ideas out here - I'm sure you'll  
> end up with the best model if you use the whole mailing list.

From asterix at lagaule.org  Tue Oct 13 10:54:43 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Tue, 13 Oct 2009 17:54:43 +0200
Subject: [Standards] error 503 in MUC
In-Reply-To: <9001.1255446789.829122@puncture>
References: <4AD38D54.5020008@lagaule.org> <9001.1255446789.829122@puncture>
Message-ID: <4AD4A2C3.8030803@lagaule.org>

Dave Cridland a ?crit :
> On Mon Oct 12 21:11:00 2009, Yann Leboulanger wrote:
>> Does this mean the room is not joinable (it's what XEP86 says)?
> 
> Yes.
> 
> 
>> Or does this mean maximum number of participant has been reached (it's
>> ehat XEP45 says)?
>>
>>
> Maybe that's the reason it's not joinable.
> 
> 
>> I know XEP 86 is deprecated, but at least ejabberd still implement that,
>> and it returns the exact same answer in both case. I'm not sure which
>> XEP is wrong, if any ...
> 
> Or, as Joe says, it might mean the host is unreachable.

Indeed, so 503 error code for max users is useless, as we cannot know if 
when we get that we really exceed the number of allowed users.

So when we get a 503, should a client show "host unreachable" or "max 
users reached" error message?

-- 
Yann

From kevin at kismith.co.uk  Tue Oct 13 12:06:37 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 13 Oct 2009 18:06:37 +0100
Subject: [Standards] Fwd: Council meeting 20091014
In-Reply-To: <f5aae3ec0910131002q4a3dd005s6af412fe3506e4eb@mail.gmail.com>
References: <f5aae3ec0910131002q4a3dd005s6af412fe3506e4eb@mail.gmail.com>
Message-ID: <f5aae3ec0910131006t42e89do3ab7187caf39b387@mail.gmail.com>

FYI


---------- Forwarded message ----------
From: Kevin Smith
Date: Tue, Oct 13, 2009 at 6:02 PM
Subject: Council meeting 20091014
To: XMPP Council


Hi all,
?Here's a possible agenda for tomorrow. Please bash if necessary.


Time: 19:00 UTC Wednesday 14th October 2009 (8pm UK time)
Place: council at conference.jabber.org

1. Roll call.
2. Elect a new chair.
3. Agenda bashing.
4. Meeting frequency.
5. Meeting times.
6. Agenda formats.
7. Having protoXEP authors present for votes.
8. Having XEP authors request last calls (AOB, poking the chair etc).
9. Radar and responsibilities.
10. http://xmpp.org/xsf/roadmap.shtml
11. http://xmpp.org/xsf/people/
12. Date/time of next meeting.
13. Any other business.

/K

From jeacott at hardlight.com.au  Tue Oct 13 22:05:30 2009
From: jeacott at hardlight.com.au (Jason Eacott)
Date: Wed, 14 Oct 2009 12:05:30 +0900
Subject: [Standards] xmpp oauth query
Message-ID: <279092300910132005o68948bd8n755823d6c24ecc9a@mail.gmail.com>

Hi All,
   I've been trying to understand oauth for xmpp and have a couple of
questions, I hope someone can answer :)

I'm a bit confused as to what exactly the producer consists of.
For example, should an xmpp server accept the oauth stanza and subsequently
forward the given request as the oauth alias?
   clear as mud I know, but I'm asking if I send a message containing the
details:
from=somejidA
to=somejidB
oauth alias=somejidC

then should/could an xmpp server rewrite this as simply:
from=somejidC
to=somejidB

if this isnt the way its supposed to work, then is it up to each
component/client to implement its own oauth impl for every incoming stanza?
sorry if the question seems dumb but I'm still unclear on how to code a
component that reacts to a given subelement (ie oauth)
and apply its outcome to the wrapping element.

I hope someone can make my head less murky ;-)

thanks
Jason.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20091014/1f86c139/attachment.htm>

From nathanfritz at gmail.com  Thu Oct 15 00:17:05 2009
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Wed, 14 Oct 2009 22:17:05 -0700
Subject: [Standards] Minutes of the 1st Meeting of the 9th Council
	(2009-10-14)
Message-ID: <182eea400910142217v211a83r9541a25c888206e2@mail.gmail.com>

First meeting of the 9th XSF Council, Kevin Smith presiding.
Meeting logs can be found at
http://logs.jabber.org/council at conference.jabber.org/2009-10-14.html
Meeting minutes can also be found at
http://wiki.xmpp.org/web/Council_Meeting_2009-10-14

1. Roll call.

All council is present. (David Cridland, Ralph Meijer, Kevin Smith,
Remko Tron?on, Matthew Wild)

Quorum achieved.

2. Elect a new chair.

Kevin offers to chair the next council and requests everyone
specifically say whether they want to run for the position. Everyone
declines individually.
Kevin Smith and David Cridland abstain from voting.
The other 3 vote for Kevin Smith.
Kevin Smith is the chairman of the 9th Council by majority vote.

3. Agenda bashing.

None.

4. Meeting frequency.

A general consensus is reached for continuing the tradition of weekly meetings.
Ralph Meijer suggests a half hour question and answer session "now and then."

5. Meeting times.

After much discussion of availability, Mondays at 19:00-19:30 British
Time (UTC+1 currently, soon to be UTC) is settled upon.

6. Agenda formats.

A general consensus is reached on agendas that can be viewed in a web
browser, with list email agendas the format for now.
The possibility of publishing agendas via XMPP Pubsub is suggested.

7. Having protoXEP authors present for votes.

Alexey Melnikov suggests from the floor that this is a good idea.
It is generally agreed upon that this is a good idea by council members.

8. Having XEP authors request last calls (AOB, poking the chair etc).

The council generally decides that the council's role is to issue Last
Calls and that "interested parties" should attend a council meeting or
"poke" a chairman to get a Last Call issued.

9. Radar and responsibilities.

The chairman is responsible for forming the agenda, and the councilmen
are responsible for making sure things that they think belong on the
agenda are brought to the chairman's attention.

10. http://xmpp.org/xsf/roadmap.shtml

Deferred due to lack of time, although David Cridland suggests that
the first two items on the decidedly out-of-date roadmap are the
responsibility of the new IETF working group.

11. http://xmpp.org/xsf/people/

Please get your bio updated/added.

12. Date/time of next meeting.

Monday 19:00 British Time.

13. Any other business.

A general consensus is reached that at the beginning of each meeting,
a volunteer should be found to write the meeting minutes. I, Nathan
Fritz, volunteer.

Kevin Smith bangs the gavel.

From kevin at kismith.co.uk  Thu Oct 15 02:18:50 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Thu, 15 Oct 2009 08:18:50 +0100
Subject: [Standards] Fwd: [Members] Minutes of the 1st Meeting of the 9th
	Council (2009-10-14)
In-Reply-To: <182eea400910142217v211a83r9541a25c888206e2@mail.gmail.com>
References: <182eea400910142217v211a83r9541a25c888206e2@mail.gmail.com>
Message-ID: <f5aae3ec0910150018qd87bd39y5cd0bffd710ea987@mail.gmail.com>

FYI.


---------- Forwarded message ----------
From: Nathan Fritz <nathanfritz at gmail.com>
Date: Thu, Oct 15, 2009 at 6:17 AM
Subject: [Members] Minutes of the 1st Meeting of the 9th Council (2009-10-14)
To: XSF Members <members at xmpp.org>, XMPP Extension Discussion List
<standards at xmpp.org>


First meeting of the 9th XSF Council, Kevin Smith presiding.
Meeting logs can be found at
http://logs.jabber.org/council at conference.jabber.org/2009-10-14.html
Meeting minutes can also be found at
http://wiki.xmpp.org/web/Council_Meeting_2009-10-14

1. Roll call.

All council is present. (David Cridland, Ralph Meijer, Kevin Smith,
Remko Tron?on, Matthew Wild)

Quorum achieved.

2. Elect a new chair.

Kevin offers to chair the next council and requests everyone
specifically say whether they want to run for the position. Everyone
declines individually.
Kevin Smith and David Cridland abstain from voting.
The other 3 vote for Kevin Smith.
Kevin Smith is the chairman of the 9th Council by majority vote.

3. Agenda bashing.

None.

4. Meeting frequency.

A general consensus is reached for continuing the tradition of weekly meetings.
Ralph Meijer suggests a half hour question and answer session "now and then."

5. Meeting times.

After much discussion of availability, Mondays at 19:00-19:30 British
Time (UTC+1 currently, soon to be UTC) is settled upon.

6. Agenda formats.

A general consensus is reached on agendas that can be viewed in a web
browser, with list email agendas the format for now.
The possibility of publishing agendas via XMPP Pubsub is suggested.

7. Having protoXEP authors present for votes.

Alexey Melnikov suggests from the floor that this is a good idea.
It is generally agreed upon that this is a good idea by council members.

8. Having XEP authors request last calls (AOB, poking the chair etc).

The council generally decides that the council's role is to issue Last
Calls and that "interested parties" should attend a council meeting or
"poke" a chairman to get a Last Call issued.

9. Radar and responsibilities.

The chairman is responsible for forming the agenda, and the councilmen
are responsible for making sure things that they think belong on the
agenda are brought to the chairman's attention.

10. http://xmpp.org/xsf/roadmap.shtml

Deferred due to lack of time, although David Cridland suggests that
the first two items on the decidedly out-of-date roadmap are the
responsibility of the new IETF working group.

11. http://xmpp.org/xsf/people/

Please get your bio updated/added.

12. Date/time of next meeting.

Monday 19:00 British Time.

13. Any other business.

A general consensus is reached that at the beginning of each meeting,
a volunteer should be found to write the meeting minutes. I, Nathan
Fritz, volunteer.

Kevin Smith bangs the gavel.

From dmeyer at tzi.de  Thu Oct 15 10:53:50 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 15 Oct 2009 17:53:50 +0200
Subject: [Standards] Is XEP-0049 superseded by XEP-0223?
In-Reply-To: <4AC2309B.4070509@stpeter.im> (Peter Saint-Andre's message of
	"Tue, 29 Sep 2009 10:06:51 -0600")
References: <C276B660-C401-4ADC-99E4-4138DF7CEBA4@jivatechnology.com>
	<4AC22FD4.5070009@stpeter.im>
	<BB264CBF-AEE2-496E-B80E-73A1C6ACCA00@jivatechnology.com>
	<4AC2309B.4070509@stpeter.im>
Message-ID: <874oq0lkkx.fsf@tzi.de>

Peter Saint-Andre wrote:
> On 9/29/09 10:05 AM, Peter Ferne wrote:
>> On 29 Sep 2009, at 17:03, Peter Saint-Andre wrote:
>>
>>> I won't be convinced that XEP-0223 truly supersedes XEP-0049 until I see
>>> people actively using it for the same use cases...
>>
>>
>> Are you aware of any specific reasons why it hasn't gained traction,
>> other than inertia?
>
> No, I'm not. But I think we need some experimentation with the pubsub
> approach before we definitively kill off private XML storage.

Stupid question: is there any pubsub server out there that supports
XEP-0223? XEP-0223 requires a pubsub server to have a virtual pubsub
service with pubsub#persist_items = true and pubsub#max_items > 1. AFAIK
pubsub servers only support PEP on the virtual server which makes no
sense without the ability to store more than one item.

And there is the issue when to sync the private storage. See
http://www.mail-archive.com/pubsub at xmpp.org/msg00000.html [1]


Dirk

-- 
panic ("No CPUs found.  System halted.\n");
	2.4.3 linux/arch/parisc/kernel/setup.c

From joe.hildebrand at webex.com  Thu Oct 15 14:39:39 2009
From: joe.hildebrand at webex.com (Joe Hildebrand)
Date: Thu, 15 Oct 2009 13:39:39 -0600
Subject: [Standards] Is XEP-0049 superseded by XEP-0223?
In-Reply-To: <874oq0lkkx.fsf@tzi.de>
Message-ID: <C6FCD69B.15BE8%joe.hildebrand@webex.com>

Our PEP implementation allows multiple items per node.  We believe that the
singleton node approach from XEP-60, section 12.20 gives you single-item
nodes as a degenerate case.


On 10/15/09 9:53 AM, "Dirk Meyer" <dmeyer at tzi.de> wrote:

> Peter Saint-Andre wrote:
>> On 9/29/09 10:05 AM, Peter Ferne wrote:
>>> On 29 Sep 2009, at 17:03, Peter Saint-Andre wrote:
>>> 
>>>> I won't be convinced that XEP-0223 truly supersedes XEP-0049 until I see
>>>> people actively using it for the same use cases...
>>> 
>>> 
>>> Are you aware of any specific reasons why it hasn't gained traction,
>>> other than inertia?
>> 
>> No, I'm not. But I think we need some experimentation with the pubsub
>> approach before we definitively kill off private XML storage.
> 
> Stupid question: is there any pubsub server out there that supports
> XEP-0223? XEP-0223 requires a pubsub server to have a virtual pubsub
> service with pubsub#persist_items = true and pubsub#max_items > 1. AFAIK
> pubsub servers only support PEP on the virtual server which makes no
> sense without the ability to store more than one item.
> 
> And there is the issue when to sync the private storage. See
> http://www.mail-archive.com/pubsub at xmpp.org/msg00000.html [1]
> 
> 
> Dirk

-- 
Joe Hildebrand


From stpeter at stpeter.im  Thu Oct 15 23:44:46 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 15 Oct 2009 22:44:46 -0600
Subject: [Standards] Is XEP-0049 superseded by XEP-0223?
In-Reply-To: <874oq0lkkx.fsf@tzi.de>
References: <C276B660-C401-4ADC-99E4-4138DF7CEBA4@jivatechnology.com>	<4AC22FD4.5070009@stpeter.im>	<BB264CBF-AEE2-496E-B80E-73A1C6ACCA00@jivatechnology.com>	<4AC2309B.4070509@stpeter.im>
	<874oq0lkkx.fsf@tzi.de>
Message-ID: <4AD7FA3E.2010000@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 9:53 AM, Dirk Meyer wrote:

> And there is the issue when to sync the private storage. See
> http://www.mail-archive.com/pubsub at xmpp.org/msg00000.html [1]

As far as I can see, the discussion on the pubsub at xmpp.org list did not
lead to consensus about the options you proposed. Please reply to my
last message about that on the pubsub list if you disagree. :)

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/

iEYEARECAAYFAkrX+j4ACgkQNL8k5A2w/vxXTACgsVSsFMWOiYwymb4MfbE5KJZq
CXMAoN+bK0fqNHeg3JcBdB3pqRy+3zjY
=9cCn
-----END PGP SIGNATURE-----

From dmeyer at tzi.de  Fri Oct 16 00:59:24 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Fri, 16 Oct 2009 07:59:24 +0200
Subject: [Standards] Is XEP-0049 superseded by XEP-0223?
In-Reply-To: <4AD7FA3E.2010000@stpeter.im> (Peter Saint-Andre's message of
	"Thu, 15 Oct 2009 22:44:46 -0600")
References: <C276B660-C401-4ADC-99E4-4138DF7CEBA4@jivatechnology.com>
	<4AC22FD4.5070009@stpeter.im>
	<BB264CBF-AEE2-496E-B80E-73A1C6ACCA00@jivatechnology.com>
	<4AC2309B.4070509@stpeter.im> <874oq0lkkx.fsf@tzi.de>
	<4AD7FA3E.2010000@stpeter.im>
Message-ID: <87skdjkhfn.fsf@tzi.de>

Peter Saint-Andre wrote:
> On 10/15/09 9:53 AM, Dirk Meyer wrote:
>
>> And there is the issue when to sync the private storage. See
>> http://www.mail-archive.com/pubsub at xmpp.org/msg00000.html [1]
>
> As far as I can see, the discussion on the pubsub at xmpp.org list did not
> lead to consensus about the options you proposed. Please reply to my
> last message about that on the pubsub list if you disagree. :)

No, the discussion lead to no consensus. Still, the problem exists
unsolved. Is there an easy way to check if my pubsub storage is modified
since I last checked? I guess I have to answer to one of the posts and
maybe restart the discussion.


Dirk

-- 
I've already told you more than I know.

From linuxwolf at outer-planes.net  Fri Oct 16 14:37:43 2009
From: linuxwolf at outer-planes.net (Matthew A. Miller)
Date: Fri, 16 Oct 2009 13:37:43 -0600
Subject: [Standards] XEP-0249: Missing password field?
Message-ID: <10F96A92-CBEF-4040-B50A-F3D9CB097DA4@outer-planes.net>

I was going over XEP-0249 and noticed that there is no <password/>  
field.  In fact, there's no discussion on passwords in the XEP that I  
could see.

This seems like an omission to me, especially considering <reason/> is  
allowed (presumably for parity with XEP-0045 mediated invites).


Thoughts?

--
Matthew A. Miller
linuxwolf at outer-planes.net




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20091016/edeca4a3/attachment.bin>

From stpeter at stpeter.im  Fri Oct 16 17:32:32 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 16 Oct 2009 16:32:32 -0600
Subject: [Standards] XEP-0249: Missing password field?
In-Reply-To: <10F96A92-CBEF-4040-B50A-F3D9CB097DA4@outer-planes.net>
References: <10F96A92-CBEF-4040-B50A-F3D9CB097DA4@outer-planes.net>
Message-ID: <4AD8F480.6030707@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/16/09 1:37 PM, Matthew A. Miller wrote:
> I was going over XEP-0249 and noticed that there is no <password/>
> field.  In fact, there's no discussion on passwords in the XEP that I
> could see.
> 
> This seems like an omission to me, especially considering <reason/> is
> allowed (presumably for parity with XEP-0045 mediated invites).

I think you're right that this was an oversight. We added the 'reason'
attribute to XEP-0249 to ensure feature parity between direct and
mediated invitations, so adding a 'password' attribute would make sense
as well (with appropriate security considerations!).

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/

iEYEARECAAYFAkrY9H8ACgkQNL8k5A2w/vxIfwCgs5uC2YNVe9k8zrd25SOeEwry
VOwAoOc3xCqWUhctKYcBfwrk72kq8tGz
=iT0d
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Fri Oct 16 21:10:46 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 16 Oct 2009 20:10:46 -0600
Subject: [Standards] xmpp oauth query
In-Reply-To: <279092300910132005o68948bd8n755823d6c24ecc9a@mail.gmail.com>
References: <279092300910132005o68948bd8n755823d6c24ecc9a@mail.gmail.com>
Message-ID: <4AD927A6.2090709@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/13/09 9:05 PM, Jason Eacott wrote:
> Hi All,

Howdy. :)

>    I've been trying to understand oauth for xmpp and have a couple of
> questions, I hope someone can answer :)
> 
> I'm a bit confused as to what exactly the producer consists of.
> For example, should an xmpp server accept the oauth stanza and
> subsequently forward the given request as the oauth alias?
>    clear as mud I know, but I'm asking if I send a message containing
> the details:
> from=somejidA
> to=somejidB
> oauth alias=somejidC
> 
> then should/could an xmpp server rewrite this as simply:
> from=somejidC
> to=somejidB
> 
> if this isnt the way its supposed to work, then is it up to each
> component/client to implement its own oauth impl for every incoming stanza?
> sorry if the question seems dumb but I'm still unclear on how to code a
> component that reacts to a given subelement (ie oauth)
> and apply its outcome to the wrapping element.
> 
> I hope someone can make my head less murky ;-)

Hmm. :)

First, what exactly are you trying to accomplish? Perhaps you could
describe your use case a bit more.

The idea behind XEP-0235 (OAuth Over XMPP) is that the XMPP server isn't
really involved, and certainly not involved in rewriting stanzas.
Instead, an XMPP client would provide an access token when seeking to do
something like publish to a pubsub node or join a chatroom. The client
would not obtain the access token over XMPP and similarly the request
token would not be obtained over XMPP. Right now all we have defined is
a way to include an access token with a particular XMPP request.

I hope that clarifies things a bit more.

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/

iEYEARECAAYFAkrZJ6YACgkQNL8k5A2w/vy/4QCfYnQ6Cxw9BjEMXN86gfAhqIYR
IvwAoJifIxw4iYYd2qNe9t3AN910Wcld
=HbPQ
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Fri Oct 16 21:33:29 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 16 Oct 2009 20:33:29 -0600
Subject: [Standards] Is XEP-0049 superseded by XEP-0223?
In-Reply-To: <87skdjkhfn.fsf@tzi.de>
References: <C276B660-C401-4ADC-99E4-4138DF7CEBA4@jivatechnology.com>	<4AC22FD4.5070009@stpeter.im>	<BB264CBF-AEE2-496E-B80E-73A1C6ACCA00@jivatechnology.com>	<4AC2309B.4070509@stpeter.im>
	<874oq0lkkx.fsf@tzi.de>	<4AD7FA3E.2010000@stpeter.im>
	<87skdjkhfn.fsf@tzi.de>
Message-ID: <4AD92CF9.6050804@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 11:59 PM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> On 10/15/09 9:53 AM, Dirk Meyer wrote:
>>
>>> And there is the issue when to sync the private storage. See
>>> http://www.mail-archive.com/pubsub at xmpp.org/msg00000.html [1]
>> As far as I can see, the discussion on the pubsub at xmpp.org list did not
>> lead to consensus about the options you proposed. Please reply to my
>> last message about that on the pubsub list if you disagree. :)
> 
> No, the discussion lead to no consensus. Still, the problem exists
> unsolved. Is there an easy way to check if my pubsub storage is modified
> since I last checked? 

No.

> I guess I have to answer to one of the posts and
> maybe restart the discussion.

Yes, please. :)

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/

iEYEARECAAYFAkrZLPkACgkQNL8k5A2w/vy9OQCfczUg7WjE9JDCz8GEeb8tu8J1
ghoAnigPHu93Xa75wOm1H7/UBVX2yy0F
=RPBu
-----END PGP SIGNATURE-----

From editor at xmpp.org  Fri Oct 16 22:04:29 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Fri, 16 Oct 2009 22:04:29 -0500
Subject: [Standards] UPDATED: XEP-0227 (Portable Import/Export Format for
	XMPP-IM Servers)
Message-ID: <E1Myzan-0006QV-00@apollo>

Version 0.3 of XEP-0227 (Portable Import/Export Format for XMPP-IM Servers) has been released.

Abstract: This document specifies a file format for importing and exporting user data to and from XMPP-IM servers.

Changelog: Modified to include feedback received during the initial Last Call. Added sections for privacy lists and incoming subscriptions, as well as text on XInclude security. (wh)

Diff: temporarily unavailable

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


From jeacott at hardlight.com.au  Sat Oct 17 18:56:52 2009
From: jeacott at hardlight.com.au (Jason)
Date: Sun, 18 Oct 2009 08:56:52 +0900
Subject: [Standards] xmpp oauth query
In-Reply-To: <mailman.11.1255798802.29366.standards@xmpp.org>
References: <mailman.11.1255798802.29366.standards@xmpp.org>
Message-ID: <4ADA59C4.1090505@hardlight.com.au>

Thanks, it does clarify things a lot,
    but it means that each and every client/component must provide its 
own implementation for this, so it seems a real disincentive.
I'm trying to accomplish the usual oauth usecase, ie give an entity 
permission to act on behalf of another for a range of services. I want 
my cake and eat it too :)
  I want to make use of all the existing xmpp infrastructure for user 
management, authorisation, roster management, pubsub etc, but I want to 
allow 3rd party entities access to some of this functionality. It seems 
such a waste to have to reimplement this stuff over and over. my actual 
'users' will never log in directly to xmpp, they will always be 
'proxied' via 3rd party services (the user implementations using actual 
xmpp accounts being a convenience for me).
I am using xmpp principally as a transport, but I'm also trying to use 
it to naturally federate my app (although I'm not sure its really going 
to work), and to save me some work re user account management and pubsub 
services. it also provides me with a platform/language independent 2 way 
transport - there really arent many choices here - which I can use 
internally and externally.
oauth lets 1 entity act on behalf of others for given services so it 
seemed a good fit.
so my initial thought re oauth was that there should be a way to hook 
into an xmpp server provided service to appropriately process the 
stanza, but no such thing exists and I'm not sure it can?. My second 
thought was to create a component that would simply process the oauth 
request and forward the request as the new user (adding a short custom 
element describing the origin user) since this would work for all cases, 
would be easier to implement for all my services, and would work for all 
the existing xmpp provided services too. It would also allow any service 
to act on any others behalf I'm not sure components are actually allowed 
to do this though(?), because it seems as if they were then it would be 
easy to write xmpp spam bots.
Also there are problems with this scheme allowing oauth proxies access 
to services they were never authorised for (ie endpoint services that 
didnt check the origin and user prefs/granted access would blindly 
accept the request).
I hope this makes sense, what am I missing?

Thanks
Jason.






> On 10/13/09 9:05 PM, Jason Eacott wrote:
>> Hi All,
> 
> Howdy. :)
> 
>>    I've been trying to understand oauth for xmpp and have a couple of
>> questions, I hope someone can answer :)
>>
>> I'm a bit confused as to what exactly the producer consists of.
>> For example, should an xmpp server accept the oauth stanza and
>> subsequently forward the given request as the oauth alias?
>>    clear as mud I know, but I'm asking if I send a message containing
>> the details:
>> from=somejidA
>> to=somejidB
>> oauth alias=somejidC
>>
>> then should/could an xmpp server rewrite this as simply:
>> from=somejidC
>> to=somejidB
>>
>> if this isnt the way its supposed to work, then is it up to each
>> component/client to implement its own oauth impl for every incoming stanza?
>> sorry if the question seems dumb but I'm still unclear on how to code a
>> component that reacts to a given subelement (ie oauth)
>> and apply its outcome to the wrapping element.
>>
>> I hope someone can make my head less murky ;-)
> 
> Hmm. :)
> 
> First, what exactly are you trying to accomplish? Perhaps you could
> describe your use case a bit more.
> 
> The idea behind XEP-0235 (OAuth Over XMPP) is that the XMPP server isn't
> really involved, and certainly not involved in rewriting stanzas.
> Instead, an XMPP client would provide an access token when seeking to do
> something like publish to a pubsub node or join a chatroom. The client
> would not obtain the access token over XMPP and similarly the request
> token would not be obtained over XMPP. Right now all we have defined is
> a way to include an access token with a particular XMPP request.
> 
> I hope that clarifies things a bit more.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/

From kevin at kismith.co.uk  Sun Oct 18 12:44:59 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Sun, 18 Oct 2009 18:44:59 +0100
Subject: [Standards] Fwd: [Council] Agenda 20091019
In-Reply-To: <f5aae3ec0910181044ga1ae5dbva8c2b2e9ab2f1ede@mail.gmail.com>
References: <f5aae3ec0910181044ga1ae5dbva8c2b2e9ab2f1ede@mail.gmail.com>
Message-ID: <f5aae3ec0910181044q68317991id42db101915c70e2@mail.gmail.com>

FYI.


---------- Forwarded message ----------
From: Kevin Smith
Date: Sun, Oct 18, 2009 at 6:44 PM
Subject: Agenda 20091019
To: XMPP Council


Agenda for the meeting 20091019 1800 UTC
council at conference.jabber.org


1. Roll call.

2. Agenda Bashing.

3. What are this council's priorities for http://xmpp.org/xsf/roadmap.shtml ?

4. ProtoXEP Linked Process Protocol - http://xmpp.org/extensions/inbox/lop.html.
Accept as a XEP?

5. The following XEPs are soon to expire:
? ?* ?XEP-0152: Reachability Addresses
? ?* XEP-0225: Component Connections
? ?* XEP-0186: Invisible Command
? ?* XEP-0252: BOSH Script Syntax
No action required.

6. Date/Time of next meeting.

7. Any other business.

A nice short agenda, for a nice short meeting (we can hope).

Best,
/K

From mr at wirelessfactory.com  Mon Oct 19 08:09:04 2009
From: mr at wirelessfactory.com (Mads Randstoft)
Date: Mon, 19 Oct 2009 15:09:04 +0200
Subject: [Standards] Update and authorship of XEPs 0248, 0253 and 0254
In-Reply-To: <mailman.7.1255107603.25308.standards@xmpp.org>
References: <mailman.7.1255107603.25308.standards@xmpp.org>
Message-ID: <33167056EF3DF54BAEB7CD6E9A73B3AD31A73EDA1B@exch07.freeway.dk>

We have implemented and are using the above extensions to PubSub here, and have a few comments.

XEP-0248 I would like to get in un-deferred (what ever that word is) and I can take authorship of it.
  It is a working part of the Tigase PubSub component. I would request it is moved on in the std. track?

XEP-0253 Is being implemented here. I would request it is not deferred. I can take authorship of it.

XEP-0254 Is implemented and in testing here. I would also request that it is not deferred and I can take authorship of it.
  Along is a diff of some changes to the current document I have done.

Index: xep-0254.xml
===================================================================
--- xep-0254.xml	(revision 3550)
+++ xep-0254.xml	(working copy)
@@ -175,11 +175,12 @@
   </section2>
   <section2 topic='Deleting an Item from the Queue' anchor='delete'>
     <p>When the subscriber that received the item has successfully processed it (whatever that means in the context of the queue), the subscriber deletes the item from the queue.</p>
+    <p>Note: Whatever the retract is successful or not, the component MUST subtract from worker's lock count unless this is already 0.</p>
     <example caption='Entity deletes an item from a node'><![CDATA[
 <iq from='workerbee237 at shakespeare.lit/foo'
     id='delete1'
     to='workflows.shakespeare.lit'
-    type='get'>
+    type='set'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
     <retract node='a290fjsl29j19kjb'>
       <item id='ae890ac52d0df67ed7cfdf51b644e901'/>
@@ -237,6 +238,7 @@
   </section2>
   <section2 topic='Unlocking an Item' anchor='unlock'>
     <p>The subscriber might determine that it cannot process the item (whatever that means in the context of the queue); if so, the subscriber unlocks the item.</p>
+    <p>Note: Whatever the unlock is successful or not, the component MUST subtract from worker's lock count unless this is already 0.</p>
     <example caption='Entity unlocks an item'><![CDATA[
 <iq from='workerbee237 at shakespeare.lit/foo'
     id='unlock1'


From stpeter at stpeter.im  Mon Oct 19 08:47:17 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 19 Oct 2009 07:47:17 -0600
Subject: [Standards] Update and authorship of XEPs 0248, 0253 and 0254
In-Reply-To: <33167056EF3DF54BAEB7CD6E9A73B3AD31A73EDA1B@exch07.freeway.dk>
References: <mailman.7.1255107603.25308.standards@xmpp.org>
	<33167056EF3DF54BAEB7CD6E9A73B3AD31A73EDA1B@exch07.freeway.dk>
Message-ID: <4ADC6DE5.4010604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/19/09 7:09 AM, Mads Randstoft wrote:
> We have implemented and are using the above extensions to PubSub
> here, and have a few comments.

Thanks for your interested in XMPP pubsub.

> XEP-0248 I would like to get in un-deferred (what ever that word is)
> and I can take authorship of it. 

Last week I asked Brian Cully to become a co-author and spec maintainer
on XEP-0248 and he agreed to help. Clearly it is becoming unsustainable
for one person (even a workaholic) to maintain all these specs.

> It is a working part of the Tigase
> PubSub component. 

Great! Could you post about your implementation experience to the
pubsub at xmpp.org list?

> I would request it is moved on in the std. track?

I think that XEP-0248 is not yet ready for a Last Call. I have about 30
unprocessed emails about it, and among other things I want to move the
text about node relationship models to an informational section later in
the document. Soon we'll get an issue tracker installed at xmpp.org so
that we can track issues more efficiently.

> XEP-0253 Is being implemented here. I would request it is not
> deferred. 

There is no shame in deferral of a spec! The important ones return to
Experimental again after they are updated.

> I can take authorship of it.

Please ping me via IM so that we can discuss.

> XEP-0254 Is implemented and in testing here. I would also request
> that it is not deferred and I can take authorship of it. Along is a
> diff of some changes to the current document I have done.

Thanks for the patch.

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/

iEYEARECAAYFAkrcbeUACgkQNL8k5A2w/vwAagCgjQxsAMvV0YN92R5U4gDVpn/y
UCcAmgKbqi34S1OVzzNA6XjLBCfv0vor
=d5Cu
-----END PGP SIGNATURE-----

From nathanfritz at gmail.com  Mon Oct 19 22:04:46 2009
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Mon, 19 Oct 2009 20:04:46 -0700
Subject: [Standards] Minutes of the 2nd Meeting of the 9th Council
	(2009-10-19)
Message-ID: <182eea400910192004m5d442e17vb831bf1af2f941ad@mail.gmail.com>

Second meeting of the 9th XSF Council, Kevin Smith presiding.
Meeting logs can be found at
http://logs.jabber.org/council at conference.jabber.org/2009-10-19.html
Meeting minutes can also be found at
http://wiki.xmpp.org/web/Council_Meeting_2009-10-19

1. Roll call.

David Cridland, Kevin Smith, and Matthew Wild present. Quorum achieved.

2. Agenda Bashing.

None.

3. What are this council's priorities for http://xmpp.org/xsf/roadmap.shtml ?

It is decided that items 1 and 2 on the roadmap are now
responsibilities of the IETF Working Group, but it is still the
Council's responsibility to advise. Kevin Smith suggest combining this
to just be item #1.
The Council agrees to include "MUC Cleanup" as item #2.
The roadmap now stands as:

1. Advise the IETF WG on RFC bis revisions and e2e.
2. Clean up MUC (XEP-0045).
3. Improve XMPP file transfer by transitioning to Jingle (see
XEP-0234) with SOCKS5 bytestreams (XEP-0260) and in-band bytestreams
(XEP-0261).
4. Improve the resistance of XMPP to spam, phishing, abuse, and denial
of service attacks, with a current focus on XEP-0268: Incident
Reporting.

4. ProtoXEP Linked Process Protocol - http://xmpp.org/extensions/inbox/lop.html.
Accept as a XEP?

A consensus is reached to wait for the next revision of the spec,
which is apparently in the works, before voting.

5. The following XEPs are soon to expire:
* XEP-0252: BOSH Script Syntax
* XEP-0226: Message Stanza Profiles
* XEP-0253: PubSub Chaining
* XEP-0254: PubSub Queueing

XEP-0253 and 0254 are both in active interest on the jdev list. Kevin
Smith suggests the Council votes next week on issuing a Last Call for
XEP-0226.

6. Date/Time of next meeting.

Monday the 26th of October 2009 at 19:00UTC.

7. Issue a Last Call on http://xmpp.org/extensions/xep-0227.html?

There is some concern about requiring separate files and the lack of
last activity.
All three councilmen vote in favor of issuing a last call.

7. Any other business.
None.

Kevin Smith bangs the gavel.

From editor at xmpp.org  Mon Oct 19 22:24:32 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Mon, 19 Oct 2009 22:24:32 -0500
Subject: [Standards] LAST CALL: XEP-0227 (Portable Import/Export Format for
	XMPP-IM Servers)
Message-ID: <E1N05Kq-0008Ie-00@apollo>

This message constitutes notice of a Last Call for comments on XEP-0227 (Portable Import/Export Format for XMPP-IM Servers).

Abstract: This document specifies a file format for importing and exporting user data to and from XMPP-IM servers.

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

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

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  Mon Oct 19 22:26:13 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 19 Oct 2009 21:26:13 -0600
Subject: [Standards] LAST CALL: XEP-0227 (Portable Import/Export Format
 for	XMPP-IM Servers)
In-Reply-To: <E1N05Kq-0008Ie-00@apollo>
References: <E1N05Kq-0008Ie-00@apollo>
Message-ID: <4ADD2DD5.5000109@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI, this is a second last call, this time on version 0.3 (which
incorporates feedback received during the original last call).

/psa

On 10/19/09 9:24 PM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0227 (Portable Import/Export Format for XMPP-IM Servers).
> 
> Abstract: This document specifies a file format for importing and
> exporting user data to and from XMPP-IM servers.
> 
> URL: http://www.xmpp.org/extensions/xep-0227.html
> 
> This Last Call begins today and shall end at the close of business on
> 2009-10-06.
> 
> 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/

iEYEARECAAYFAkrdLdUACgkQNL8k5A2w/vwgjQCdFcLwl5Iw7EG2LutKivtsqL4e
zXMAoOxuGh4NDtA1fQ/B8yHpCmGZq+9L
=I+kn
-----END PGP SIGNATURE-----

From dave at cridland.net  Tue Oct 20 04:12:01 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 20 Oct 2009 10:12:01 +0100
Subject: [Standards] [Members] Minutes of the 2nd Meeting of the 9th
 Council (2009-10-19)
In-Reply-To: <182eea400910192004m5d442e17vb831bf1af2f941ad@mail.gmail.com>
References: <182eea400910192004m5d442e17vb831bf1af2f941ad@mail.gmail.com>
Message-ID: <14858.1256029921.224174@puncture>

On Tue Oct 20 04:04:46 2009, Nathan Fritz wrote:
> Second meeting of the 9th XSF Council, Kevin Smith presiding.
> Meeting logs can be found at
> http://logs.jabber.org/council at conference.jabber.org/2009-10-19.html
> Meeting minutes can also be found at
> http://wiki.xmpp.org/web/Council_Meeting_2009-10-19
> 
> 1. Roll call.
> 
> David Cridland, Kevin Smith, and Matthew Wild present. Quorum  
> achieved.
> 
> 
I'd note that Remko sent his apologies, with the excuse that he's on  
his honeymoon.

Ralph turned up precisely when the calendar told him to, which was  
unfortunate, because the calendar was off by an hour...

Note that the next meeting will move relative to UTC by an hour due  
to the end of Summer Time in the EU - all Council folk are within the  
EU block, and so the time doesn't change for us, but may for others.

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 Oct 20 10:42:35 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 20 Oct 2009 09:42:35 -0600
Subject: [Standards] [Members] Minutes of the 2nd Meeting of the 9th
 Council (2009-10-19)
In-Reply-To: <14858.1256029921.224174@puncture>
References: <182eea400910192004m5d442e17vb831bf1af2f941ad@mail.gmail.com>
	<14858.1256029921.224174@puncture>
Message-ID: <4ADDDA6B.7040903@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/20/09 3:12 AM, Dave Cridland wrote:
> On Tue Oct 20 04:04:46 2009, Nathan Fritz wrote:
>> Second meeting of the 9th XSF Council, Kevin Smith presiding.
>> Meeting logs can be found at
>> http://logs.jabber.org/council at conference.jabber.org/2009-10-19.html
>> Meeting minutes can also be found at
>> http://wiki.xmpp.org/web/Council_Meeting_2009-10-19
>>
>> 1. Roll call.
>>
>> David Cridland, Kevin Smith, and Matthew Wild present. Quorum achieved.
>>
>>
> I'd note that Remko sent his apologies, with the excuse that he's on his
> honeymoon.
> 
> Ralph turned up precisely when the calendar told him to, which was
> unfortunate, because the calendar was off by an hour...

Sorry about that. My fault.

> Note that the next meeting will move relative to UTC by an hour due to
> the end of Summer Time in the EU - all Council folk are within the EU
> block, and so the time doesn't change for us, but may for others.

Is the calendar entry at http://xmpp.org/xsf/XSF.ics 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/

iEYEARECAAYFAkrd2msACgkQNL8k5A2w/vyZFACfeguSBuzkefOZ4wvZFakUoEDA
0G4AnAnPhJEiUfjdO8b3TUm6gdt9sauH
=haec
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Wed Oct 21 12:52:57 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 21 Oct 2009 11:52:57 -0600
Subject: [Standards] PDFs!
Message-ID: <4ADF4A79.7050906@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks to great work by Tobias Markmann, the XSF now publishes PDF
versions of its specifications. You can find them here:

http://xmpp.org/extensions/

We're still working out a few glitches here and there, so your feedback
is appreciated.

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/

iEYEARECAAYFAkrfSnkACgkQNL8k5A2w/vy47QCeNzJuVLbJIKpA3vAZb9icoc0D
fLQAn2kQ7P0ltCPf1lWbcEiDN/9WFxCv
=fL8p
-----END PGP SIGNATURE-----

From nathanfritz at gmail.com  Wed Oct 21 13:14:15 2009
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Wed, 21 Oct 2009 11:14:15 -0700
Subject: [Standards] PDFs!
In-Reply-To: <4ADF4A79.7050906@stpeter.im>
References: <4ADF4A79.7050906@stpeter.im>
Message-ID: <182eea400910211114t7b6c37b9od00008bbf452427@mail.gmail.com>

On Wed, Oct 21, 2009 at 10:52 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks to great work by Tobias Markmann, the XSF now publishes PDF
> versions of its specifications. You can find them here:
>
> http://xmpp.org/extensions/
>
> We're still working out a few glitches here and there, so your feedback
> is appreciated.
>
> 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/
>
> iEYEARECAAYFAkrfSnkACgkQNL8k5A2w/vy47QCeNzJuVLbJIKpA3vAZb9icoc0D
> fLQAn2kQ7P0ltCPf1lWbcEiDN/9WFxCv
> =fL8p
> -----END PGP SIGNATURE-----
>

They look great, and smell great too!  I just noticed them yesterday
or the day before.  Are the checkbox filters new too?

-Fritzy

From stpeter at stpeter.im  Wed Oct 21 13:14:59 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 21 Oct 2009 12:14:59 -0600
Subject: [Standards] PDFs!
In-Reply-To: <182eea400910211114t7b6c37b9od00008bbf452427@mail.gmail.com>
References: <4ADF4A79.7050906@stpeter.im>
	<182eea400910211114t7b6c37b9od00008bbf452427@mail.gmail.com>
Message-ID: <4ADF4FA3.3010001@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/21/09 12:14 PM, Nathan Fritz wrote:
> On Wed, Oct 21, 2009 at 10:52 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Thanks to great work by Tobias Markmann, the XSF now publishes PDF
> versions of its specifications. You can find them here:
> 
> http://xmpp.org/extensions/
> 
> We're still working out a few glitches here and there, so your feedback
> is appreciated.
> 
> Peter
> 
>
> They look great, and smell great too!  I just noticed them yesterday
> or the day before.  Are the checkbox filters new too?

Yes, also made by Tobias.

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/

iEYEARECAAYFAkrfT6MACgkQNL8k5A2w/vyi5QCfUrr0IFY6FLH8j2H3Q8F3nCOy
4bAAn1rWj4H9kuB0qQYh5pxJKmRbLAzy
=+WeB
-----END PGP SIGNATURE-----

From kevin at kismith.co.uk  Thu Oct 22 01:56:05 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Thu, 22 Oct 2009 07:56:05 +0100
Subject: [Standards] PDFs!
In-Reply-To: <4ADF4FA3.3010001@stpeter.im>
References: <4ADF4A79.7050906@stpeter.im>
	<182eea400910211114t7b6c37b9od00008bbf452427@mail.gmail.com>
	<4ADF4FA3.3010001@stpeter.im>
Message-ID: <f5aae3ec0910212356o65e31dbcl1cca9bbf6a50e507@mail.gmail.com>

On Wed, Oct 21, 2009 at 7:14 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> http://xmpp.org/extensions/

Oh very nice, thanks Tobias.

The new syntax colouring also helps see typos in the samples, like a
missing ' in < m u j i x m l n s = ? h t t p : / / t e l e p a t h y .
f r e e d e s k t o p . o r g / m u j i >

/K

From ml at update.uu.se  Mon Oct 26 11:23:29 2009
From: ml at update.uu.se (Marcus Lundblad)
Date: Mon, 26 Oct 2009 17:23:29 +0100
Subject: [Standards] XEP-0264
Message-ID: <1256574209.6372.4.camel@andromeda.sth.curalia.se>

Out of curiosity, has anyone else besides me looked anything at the file
transfer thumbnails experimental XEP?
I have some working code for it as of now, and would be interested in
getting some feedback on the XEP so that it could be brought up on the
agende for advancement further on :)

//Marcus


From nathanfritz at gmail.com  Tue Oct 27 01:03:15 2009
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Mon, 26 Oct 2009 23:03:15 -0700
Subject: [Standards] Minutes of the 3rd Meeting of the 9th Council
	(2009-10-26)
Message-ID: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>

Third meeting of the 9th XSF Council, Kevin Smith presiding.
Meeting logs can be found at
http://logs.jabber.org/council at conference.jabber.org/2009-10-26.html
Meeting minutes can also be found at
http://wiki.xmpp.org/web/Council_Meeting_2009-10-26

1) Roll call.

David Cridland, Matthew Wild, Kevin Smith, Ralph Meijer attending.
Remko Tron?on sends apologies.

2) Agenda Bashing.

None.

3) XEP-0226: Message Stanza Profiles, Issue Last Call?

A consensus is reached on issuing a last call on XEP-0226, although
Matthew Wild notes that he finds the XEP pointless.

4) Reviewing of Peter Saint-Andre's Notes.

4a) Has the roadmap been updated?

Kevin Smith agrees to update the roadmap.

4b) Would we like to set a schedule for those items?

David Cridland suggests that the new Tech Review Team reviews XEP-0227.
Peter Saint Andre has created a new list for the Tech Review Team at
http://mail.jabber.org/mailman/listinfo/techreview

4c) "We've had some discussion on the BOSH list about registering port
5280 with IANA and also defining a default path for BOSH services. I
think it would be good for the Council to discuss these matters so
that we can move forward if desired."

A general consensus is reached to register the port, but a consensus
is not reached on default paths.

4d) "The page at http://xmpp.org/protocols/ it is very likely out of
date and missing some information. Perhaps this is a task that one of
the XSF teams can complete. Let's discuss what we think is
appropriate."

It is suggested that the Tech Review Team reviews this page.

4e) "Some of the XEPs need new maintainers because I can't keep up
with them all anymore (e.g. I have asked Brian Cully to take on
maintainership of the PubSub Collections spec, and regarding XEPs 253
and 254 see <http://mail.jabber.org/pipermail/pubsub/2009-October/000454.html>).
Does the Council think that we need a policy on maintainership of
XEPs?"

The council agrees that no policy is needed.

4) Date of next meeting?

2009-11-02 @ 19:00 UTC

5) Any other business?

None.

Kevin Smith bangs the gavel.

From kevin at kismith.co.uk  Tue Oct 27 02:14:57 2009
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 27 Oct 2009 07:14:57 +0000
Subject: [Standards] [Members] Minutes of the 3rd Meeting of the 9th
	Council (2009-10-26)
In-Reply-To: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>
References: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>
Message-ID: <f5aae3ec0910270014x81a8c1eg968acfaefbbc8a9b@mail.gmail.com>

On Tue, Oct 27, 2009 at 6:03 AM, Nathan Fritz <nathanfritz at gmail.com> wrote:
> Third meeting of the 9th XSF Council

Thanks Fritzy.

/K

From justin-keyword-jabber.093179 at affinix.com  Tue Oct 27 03:19:42 2009
From: justin-keyword-jabber.093179 at affinix.com (Justin Karneges)
Date: Tue, 27 Oct 2009 01:19:42 -0700
Subject: [Standards] Message Stanza Profiles (was Re: Minutes of the 3rd
	Meeting of the 9th Council (2009-10-26))
In-Reply-To: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>
References: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>
Message-ID: <200910270119.42613.justin-keyword-jabber.093179@affinix.com>

On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
> 3) XEP-0226: Message Stanza Profiles, Issue Last Call?
>
> A consensus is reached on issuing a last call on XEP-0226, although
> Matthew Wild notes that he finds the XEP pointless.

I'll explain the rationale for the message stanza profiles XEP.

First, I believe ambiguity in message stanza processing is a long-standing 
protocol issue that needs to be solved.  I initially wrote about it in 2004:
  http://mail.jabber.org/pipermail/standards/2004-August/006001.html

I was confused about how you're supposed to know if a message with extended 
content is supposed to be handled as an IM with an "attachment" or simply as 
a non-IM event.  For example, <body> with x:oob is an IM with a URL 
attachment, <body> with x:data is an XData form only (body text is for 
fallback), and <body> with IBB is an IBB packet only (body text could be 
fallback, but probably shouldn't be there at all).

You would never, ever present the latter stanza to the user as an IM with an 
IBB attachment.  We get by today thanks to everyone's common sense. :)  
However, the "monstrosity" stanza in XEP-0226 should be convincing enough 
that we have a spec problem.  The stanza is not illegal, yet processing of 
that stanza among various implementations is surely indeterministic.

Second, I believe clearing this up could simplify code.  Most XMPP software 
does stanza processing using handlers and filters.  It is easy to match IQ 
stanzas to their handlers.  However, for message stanzas you need more 
sophisticated filtering due to the potential of mixed content.  I suspect 
most code out there doesn't actually support processing, say, a pubsub event 
and an IBB chunk in the same message stanza.  More likely, a filter for one 
of the content types "wins" in some implementation-specific way (e.g. because 
that filter acts first).

Quoting the Implementation Notes section of the XEP:

"Since each message is unambiguously determined to be of a specific profile, 
implementations that use filtering to pass message stanzas to an appropriate 
handler (a very common XMPP implementation approach) need not be concerned 
with the filtering order. This is because only one handler should ever match 
on the filter expression."

The point being, that message stanzas could be matched to their handler with 
similar exactness that we enjoy with IQs.  Again, maybe common sense says 
this is already possible, but as an XMPP implementor I'd feel a lot better if 
it were in writing. :)

-Justin

From dave at cridland.net  Tue Oct 27 04:54:02 2009
From: dave at cridland.net (Dave Cridland)
Date: Tue, 27 Oct 2009 09:54:02 +0000
Subject: [Standards] Message Stanza Profiles (was Re: Minutes of the 3rd
 Meeting of the 9th Council (2009-10-26))
In-Reply-To: <200910270119.42613.justin-keyword-jabber.093179@affinix.com>
References: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>
	<200910270119.42613.justin-keyword-jabber.093179@affinix.com>
Message-ID: <20345.1256637242.520223@puncture>

On Tue Oct 27 08:19:42 2009, Justin Karneges wrote:
> On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
> > 3) XEP-0226: Message Stanza Profiles, Issue Last Call?
> >
> > A consensus is reached on issuing a last call on XEP-0226,  
> although
> > Matthew Wild notes that he finds the XEP pointless.
> 
> I'll explain the rationale for the message stanza profiles XEP.
> 
> First, I believe ambiguity in message stanza processing is a  
> long-standing
> protocol issue that needs to be solved.  I initially wrote about it  
> in 2004:
>   http://mail.jabber.org/pipermail/standards/2004-August/006001.html

Right - I'd note that Kurt used the definitions in XEP-0226 to define  
security labels as Metadata in XEP-0258 - in other words saying that  
these do not affect the "final action", merely the "processing".

So I think this XEP could serve in two roles.

Firstly, giving client authors a specification for consistently  
processing a particular stanza to achieve the same result, or as we  
in the standards development world call it, "interoperability".

Secondly, we can use the terms defined in the specification to  
describe what various extensions are doing  in their own  
specifications - so we can say that a XEP-0258 security label is  
"metadata" - ie, it doesn't affect the nature of the stanza, but it  
may affect its handling.

Or we can say a pubsub event element is a... erm... profile element?  
Oddly, XEP-0226 doesn't define a term for that, now I look.

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 mwild1 at gmail.com  Tue Oct 27 10:08:33 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Tue, 27 Oct 2009 15:08:33 +0000
Subject: [Standards] Message Stanza Profiles (was Re: Minutes of the 3rd
	Meeting of the 9th Council (2009-10-26))
In-Reply-To: <200910270119.42613.justin-keyword-jabber.093179@affinix.com>
References: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com> 
	<200910270119.42613.justin-keyword-jabber.093179@affinix.com>
Message-ID: <4db9cacb0910270808q425674feg300d193fb376fe7@mail.gmail.com>

2009/10/27 Justin Karneges <justin-keyword-jabber.093179 at affinix.com>:
> On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
>> 3) XEP-0226: Message Stanza Profiles, Issue Last Call?
>>
>> A consensus is reached on issuing a last call on XEP-0226, although
>> Matthew Wild notes that he finds the XEP pointless.
>
> I'll explain the rationale for the message stanza profiles XEP.
>
> First, I believe ambiguity in message stanza processing is a long-standing
> protocol issue that needs to be solved. ?I initially wrote about it in 2004:
> ?http://mail.jabber.org/pipermail/standards/2004-August/006001.html
>
> I was confused about how you're supposed to know if a message with extended
> content is supposed to be handled as an IM with an "attachment" or simply as
> a non-IM event. ?For example, <body> with x:oob is an IM with a URL
> attachment, <body> with x:data is an XData form only (body text is for
> fallback), and <body> with IBB is an IBB packet only (body text could be
> fallback, but probably shouldn't be there at all).
>
> You would never, ever present the latter stanza to the user as an IM with an
> IBB attachment. ?We get by today thanks to everyone's common sense. :)
> However, the "monstrosity" stanza in XEP-0226 should be convincing enough
> that we have a spec problem. ?The stanza is not illegal, yet processing of
> that stanza among various implementations is surely indeterministic.
>

The example stanza indeed doesn't look pretty. However just beneath it
the XEP describes all the different pieces of information in it, and
how they should be handled, which all seems common sense to me :)

Anyway, I've read your rationale from 2004, I see why the XEP might be
useful to combat a few corner cases. I'm not against it, just wasn't
sure what it was making so much of a fuss about.

> Second, I believe clearing this up could simplify code. ?Most XMPP software
> does stanza processing using handlers and filters. ?It is easy to match IQ
> stanzas to their handlers. ?However, for message stanzas you need more
> sophisticated filtering due to the potential of mixed content. ?I suspect
> most code out there doesn't actually support processing, say, a pubsub event
> and an IBB chunk in the same message stanza. ?More likely, a filter for one
> of the content types "wins" in some implementation-specific way (e.g. because
> that filter acts first).
>

Indeed, this I'd say is a client bug though. If specifying how they
should do it is going to make them do it properly, so be it.

> Quoting the Implementation Notes section of the XEP:
>
> "Since each message is unambiguously determined to be of a specific profile,
> implementations that use filtering to pass message stanzas to an appropriate
> handler (a very common XMPP implementation approach) need not be concerned
> with the filtering order. This is because only one handler should ever match
> on the filter expression."
>
> The point being, that message stanzas could be matched to their handler with
> similar exactness that we enjoy with IQs. ?Again, maybe common sense says
> this is already possible, but as an XMPP implementor I'd feel a lot better if
> it were in writing. :)
>

Ok :)

Matthew

From stpeter at stpeter.im  Tue Oct 27 11:00:59 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 27 Oct 2009 10:00:59 -0600
Subject: [Standards] Message Stanza Profiles (was Re: Minutes of the 3rd
 Meeting of the 9th Council (2009-10-26))
In-Reply-To: <4db9cacb0910270808q425674feg300d193fb376fe7@mail.gmail.com>
References: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>
	<200910270119.42613.justin-keyword-jabber.093179@affinix.com>
	<4db9cacb0910270808q425674feg300d193fb376fe7@mail.gmail.com>
Message-ID: <4AE7193B.60604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/27/09 9:08 AM, Matthew Wild wrote:
> 2009/10/27 Justin Karneges <justin-keyword-jabber.093179 at affinix.com>:
>> On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
>>> 3) XEP-0226: Message Stanza Profiles, Issue Last Call?
>>>
>>> A consensus is reached on issuing a last call on XEP-0226, although
>>> Matthew Wild notes that he finds the XEP pointless.
>> I'll explain the rationale for the message stanza profiles XEP.
>>
>> First, I believe ambiguity in message stanza processing is a long-standing
>> protocol issue that needs to be solved.  I initially wrote about it in 2004:
>>  http://mail.jabber.org/pipermail/standards/2004-August/006001.html
>>
>> I was confused about how you're supposed to know if a message with extended
>> content is supposed to be handled as an IM with an "attachment" or simply as
>> a non-IM event.  For example, <body> with x:oob is an IM with a URL
>> attachment, <body> with x:data is an XData form only (body text is for
>> fallback), and <body> with IBB is an IBB packet only (body text could be
>> fallback, but probably shouldn't be there at all).
>>
>> You would never, ever present the latter stanza to the user as an IM with an
>> IBB attachment.  We get by today thanks to everyone's common sense. :)
>> However, the "monstrosity" stanza in XEP-0226 should be convincing enough
>> that we have a spec problem.  The stanza is not illegal, yet processing of
>> that stanza among various implementations is surely indeterministic.
>>
> 
> The example stanza indeed doesn't look pretty. However just beneath it
> the XEP describes all the different pieces of information in it, and
> how they should be handled, which all seems common sense to me :)
> 
> Anyway, I've read your rationale from 2004, I see why the XEP might be
> useful to combat a few corner cases. I'm not against it, just wasn't
> sure what it was making so much of a fuss about.

Who said anyone was making a fuss? The XMPP Extensions Editor noticed
that this spec was about to become Deferred and flagged it for
discussion by the Council (as in, do we want to Last Call this or let it
sink into oblivion?). That's just normal "radar" processes doing their
job. :)

Now, if you think that writing an informational document to help guide
client developers about some potential corner cases is "making a fuss"
then we can have a discussion about that, but I've always thought that
more documentation is better...

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/

iEYEARECAAYFAkrnGTsACgkQNL8k5A2w/vz0ogCgqSq9Tv7YI2pdRVGwqBUoE4nn
oFsAn0eYLiaIw3qfS2dOv1zbXI0Y9rwg
=3LsY
-----END PGP SIGNATURE-----

From mwild1 at gmail.com  Tue Oct 27 11:48:55 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Tue, 27 Oct 2009 16:48:55 +0000
Subject: [Standards] Message Stanza Profiles (was Re: Minutes of the 3rd
	Meeting of the 9th Council (2009-10-26))
In-Reply-To: <4AE7193B.60604@stpeter.im>
References: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com> 
	<200910270119.42613.justin-keyword-jabber.093179@affinix.com> 
	<4db9cacb0910270808q425674feg300d193fb376fe7@mail.gmail.com> 
	<4AE7193B.60604@stpeter.im>
Message-ID: <4db9cacb0910270948y379584e8h3cd45138d318eae0@mail.gmail.com>

2009/10/27 Peter Saint-Andre <stpeter at stpeter.im>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/09 9:08 AM, Matthew Wild wrote:
>> 2009/10/27 Justin Karneges <justin-keyword-jabber.093179 at affinix.com>:
>>> On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
>>>> 3) XEP-0226: Message Stanza Profiles, Issue Last Call?
>>>>
>>>> A consensus is reached on issuing a last call on XEP-0226, although
>>>> Matthew Wild notes that he finds the XEP pointless.
>>> I'll explain the rationale for the message stanza profiles XEP.
>>>
>>> First, I believe ambiguity in message stanza processing is a long-standing
>>> protocol issue that needs to be solved. ?I initially wrote about it in 2004:
>>> ?http://mail.jabber.org/pipermail/standards/2004-August/006001.html
>>>
>>> I was confused about how you're supposed to know if a message with extended
>>> content is supposed to be handled as an IM with an "attachment" or simply as
>>> a non-IM event. ?For example, <body> with x:oob is an IM with a URL
>>> attachment, <body> with x:data is an XData form only (body text is for
>>> fallback), and <body> with IBB is an IBB packet only (body text could be
>>> fallback, but probably shouldn't be there at all).
>>>
>>> You would never, ever present the latter stanza to the user as an IM with an
>>> IBB attachment. ?We get by today thanks to everyone's common sense. :)
>>> However, the "monstrosity" stanza in XEP-0226 should be convincing enough
>>> that we have a spec problem. ?The stanza is not illegal, yet processing of
>>> that stanza among various implementations is surely indeterministic.
>>>
>>
>> The example stanza indeed doesn't look pretty. However just beneath it
>> the XEP describes all the different pieces of information in it, and
>> how they should be handled, which all seems common sense to me :)
>>
>> Anyway, I've read your rationale from 2004, I see why the XEP might be
>> useful to combat a few corner cases. I'm not against it, just wasn't
>> sure what it was making so much of a fuss about.
>
> Who said anyone was making a fuss?

I said the spec was making a fuss (meaning about stanzas with too many
child elements). It seems that it is right to do so (after I read
Justin's mail).

I didn't want to just resurrect and publish it for the sake of
"someone wrote it once", I don't think I've ever heard the XEP
mentioned in its own right, and was questioning whether it was useful.
I'm now convinced that it is.

> The XMPP Extensions Editor noticed
> that this spec was about to become Deferred and flagged it for
> discussion by the Council (as in, do we want to Last Call this or let it
> sink into oblivion?). That's just normal "radar" processes doing their
> job. :)
>

The XMPP Extensions Editor was right to flag it up for discussion, and
I was right to question it while I had doubts, and now it would be
right to advance it. I accused no *person* of making a fuss :)

Regards,
Matthew

From stpeter at stpeter.im  Tue Oct 27 11:57:34 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 27 Oct 2009 10:57:34 -0600
Subject: [Standards] Message Stanza Profiles (was Re: Minutes of the 3rd
 Meeting of the 9th Council (2009-10-26))
In-Reply-To: <4db9cacb0910270948y379584e8h3cd45138d318eae0@mail.gmail.com>
References: <182eea400910262303s3a07015aw631997e876df8adc@mail.gmail.com>
	<200910270119.42613.justin-keyword-jabber.093179@affinix.com>
	<4db9cacb0910270808q425674feg300d193fb376fe7@mail.gmail.com>
	<4AE7193B.60604@stpeter.im>
	<4db9cacb0910270948y379584e8h3cd45138d318eae0@mail.gmail.com>
Message-ID: <4AE7267E.3000803@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/27/09 10:48 AM, Matthew Wild wrote:
> 2009/10/27 Peter Saint-Andre <stpeter at stpeter.im>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 10/27/09 9:08 AM, Matthew Wild wrote:
>>> 2009/10/27 Justin Karneges <justin-keyword-jabber.093179 at affinix.com>:
>>>> On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
>>>>> 3) XEP-0226: Message Stanza Profiles, Issue Last Call?
>>>>>
>>>>> A consensus is reached on issuing a last call on XEP-0226, although
>>>>> Matthew Wild notes that he finds the XEP pointless.
>>>> I'll explain the rationale for the message stanza profiles XEP.
>>>>
>>>> First, I believe ambiguity in message stanza processing is a long-standing
>>>> protocol issue that needs to be solved.  I initially wrote about it in 2004:
>>>>  http://mail.jabber.org/pipermail/standards/2004-August/006001.html
>>>>
>>>> I was confused about how you're supposed to know if a message with extended
>>>> content is supposed to be handled as an IM with an "attachment" or simply as
>>>> a non-IM event.  For example, <body> with x:oob is an IM with a URL
>>>> attachment, <body> with x:data is an XData form only (body text is for
>>>> fallback), and <body> with IBB is an IBB packet only (body text could be
>>>> fallback, but probably shouldn't be there at all).
>>>>
>>>> You would never, ever present the latter stanza to the user as an IM with an
>>>> IBB attachment.  We get by today thanks to everyone's common sense. :)
>>>> However, the "monstrosity" stanza in XEP-0226 should be convincing enough
>>>> that we have a spec problem.  The stanza is not illegal, yet processing of
>>>> that stanza among various implementations is surely indeterministic.
>>>>
>>> The example stanza indeed doesn't look pretty. However just beneath it
>>> the XEP describes all the different pieces of information in it, and
>>> how they should be handled, which all seems common sense to me :)
>>>
>>> Anyway, I've read your rationale from 2004, I see why the XEP might be
>>> useful to combat a few corner cases. I'm not against it, just wasn't
>>> sure what it was making so much of a fuss about.
>> Who said anyone was making a fuss?
> 
> I said the spec was making a fuss (meaning about stanzas with too many
> child elements). It seems that it is right to do so (after I read
> Justin's mail).
> 
> I didn't want to just resurrect and publish it for the sake of
> "someone wrote it once", I don't think I've ever heard the XEP
> mentioned in its own right, and was questioning whether it was useful.
> I'm now convinced that it is.
> 
>> The XMPP Extensions Editor noticed
>> that this spec was about to become Deferred and flagged it for
>> discussion by the Council (as in, do we want to Last Call this or let it
>> sink into oblivion?). That's just normal "radar" processes doing their
>> job. :)
>>
> 
> The XMPP Extensions Editor was right to flag it up for discussion, and
> I was right to question it while I had doubts, and now it would be
> right to advance it. I accused no *person* of making a fuss :)

OK, so we're all good. Now if only the Editor would officially issue the
Last Call requested by the Council...

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/

iEYEARECAAYFAkrnJn4ACgkQNL8k5A2w/vzbBgCgjVgr467UmSjf3khiqQRn7iGT
dQoAoNJInCFOdwI2kCERJsT8Zfeh3w0M
=2I7R
-----END PGP SIGNATURE-----

From editor at xmpp.org  Tue Oct 27 12:20:35 2009
From: editor at xmpp.org (XMPP Extensions Editor)
Date: Tue, 27 Oct 2009 12:20:35 -0500
Subject: [Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
Message-ID: <E1N2pil-0004vT-F1@athena.jabber.org>

This message constitutes notice of a Last Call for comments on XEP-0226 (Message Stanza Profiles).

Abstract: This document specifies best practices for generating and handling extended content in XMPP message stanzas.

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

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

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  Tue Oct 27 18:11:15 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 27 Oct 2009 17:11:15 -0600
Subject: [Standards] XEP-0264
In-Reply-To: <1256574209.6372.4.camel@andromeda.sth.curalia.se>
References: <1256574209.6372.4.camel@andromeda.sth.curalia.se>
Message-ID: <4AE77E13.60303@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/26/09 10:23 AM, Marcus Lundblad wrote:
> Out of curiosity, has anyone else besides me looked anything at the file
> transfer thumbnails experimental XEP?
> I have some working code for it as of now, and would be interested in
> getting some feedback on the XEP so that it could be brought up on the
> agende for advancement further on :)

Yes, it would be good to move that along. But finishing the Jingle file
transfer specs (234, 260, 261) is a higher priority for me. :)

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/

iEYEARECAAYFAkrnfhMACgkQNL8k5A2w/vyw9QCfVi1ssamksOat4cDN/Nskn++B
5OEAoM3bfGC/jAjKttoy+TPcWkqY6ZvC
=Dvld
-----END PGP SIGNATURE-----

From Kurt.Zeilenga at Isode.com  Sat Oct 31 14:41:32 2009
From: Kurt.Zeilenga at Isode.com (Kurt Zeilenga)
Date: Sat, 31 Oct 2009 12:41:32 -0700
Subject: [Standards] XEP 203 nits
Message-ID: <79A1C455-6E35-40C1-919B-92361EA38131@Isode.com>

In looking at this spec recently, I found a few oddities...

The specification is not clear whether a stanza can contain multiple  
<delay/> elements such as when its delayed by multiple entities.   
While I cannot find any example or discussion of multiple <delay/>  
elements in any XEP, I assume multiple <delay/> elements are allowed  
as multiple entities can delay a stanza.  But oddly I cannot find any  
discussion of multiple <delay/> elements in XEP 203 or any  
specification which calls for <delay/> elements to be added.

Presuming the stanza can contain multiple <delay/> elements when its  
delayed by multiple entities, the specification language could be read  
as disallows an entity which delays a stanza multiple times from  
indicating that it has done so by including multiple <delay/>  
elements.  For instance, when a server delays a stanza to a chatroom  
(hosted on another server entity) and than delays the forwarding of  
that stanza to one or more of the subscribers of the chat room.

The specification recommends (in security considerations) that an  
entity remove delay notices which indicate that they were provided by  
the entity, or bounce the stanza, without at all noting that an entity  
should not remove it's own delay notices (or bounce a stanza it  
previously delayed).  IMO, an entity SHOULD NOT remove <delay/>  
purporting to be from it unless it believes they weren't from it.

There also seems to be issues in subsequent handling of previously  
delayed messages as well... but first the above.

-- Kurt