From stpeter at stpeter.im  Thu Oct  2 14:05:52 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Oct 2008 13:05:52 -0600
Subject: [Council] XMPP Council 2008-2009
Message-ID: <48E51B90.2030407@stpeter.im>

The members of the XMPP Standards Foundation voted today on the Board of
Directors and XMPP Council for 2008-2009. The elected Council members are:

Dave Cridland
Ralph Meijer
Jack Moffitt
Peter Saint-Andre
Kevin Smith

As outgoing Chair, I propose that we hold a meeting on Wednesday,
October 8 at 19:00 UTC to choose a Chair for 2008-2009 and perhaps get
some real work done, too.

Thanks for agreeing to serve. :)

Peter

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


From kevin at kismith.co.uk  Thu Oct  2 14:24:04 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Thu, 2 Oct 2008 20:24:04 +0100
Subject: [Council] XMPP Council 2008-2009
In-Reply-To: <48E51B90.2030407@stpeter.im>
References: <48E51B90.2030407@stpeter.im>
Message-ID: <f5aae3ec0810021224l6d00529auecff277cbe35f0ed@mail.gmail.com>

On Thu, Oct 2, 2008 at 8:05 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> As outgoing Chair, I propose that we hold a meeting on Wednesday,
> October 8 at 19:00 UTC to choose a Chair for 2008-2009 and perhaps get
> some real work done, too.

Let's get off to a bad start by saying I may have to vote by mail - I
may have something else that needs doing, and I won't know until the
day before.

/K

From jack at chesspark.com  Thu Oct  2 14:45:50 2008
From: jack at chesspark.com (Jack Moffitt)
Date: Thu, 2 Oct 2008 13:45:50 -0600
Subject: [Council] XMPP Council 2008-2009
In-Reply-To: <48E51B90.2030407@stpeter.im>
References: <48E51B90.2030407@stpeter.im>
Message-ID: <9b58f4550810021245t54a21279uac589f6b2c4098b2@mail.gmail.com>

> As outgoing Chair, I propose that we hold a meeting on Wednesday,
> October 8 at 19:00 UTC to choose a Chair for 2008-2009 and perhaps get
> some real work done, too.

That works for me.

> Thanks for agreeing to serve. :)

Glad to be here again.

jack.

From stpeter at stpeter.im  Thu Oct  2 23:47:02 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Oct 2008 22:47:02 -0600
Subject: [Council] preliminary meeting agenda
Message-ID: <48E5A3C6.8020603@stpeter.im>

I have no illusions that we'll get through all of this:

http://xmpp.org/council/agendas/2008-10-08.html

However, it gives you a sense of how much work there is to do. :)

/psa

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



From stpeter at stpeter.im  Mon Oct  6 23:36:43 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Oct 2008 22:36:43 -0600
Subject: [Council] meeting reminder: 2008-10-08
Message-ID: <48EAE75B.6030902@stpeter.im>

Just a reminder that we'll hold a meeting on Wednesday. I'll send out
another reminder about 24 hours ahead of time.

http://xmpp.org/council/agendas/2008-10-08.html

Peter

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


From stpeter at stpeter.im  Tue Oct  7 13:50:15 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 07 Oct 2008 12:50:15 -0600
Subject: [Council] meeting reminder
Message-ID: <48EBAF67.50206@stpeter.im>

Here is your 24-hour notice that the XMPP Council will hold a meeting
tomorrow. A tentative agenda is here:

http://xmpp.org/council/agendas/2008-10-08.html

Peter

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


From stpeter at stpeter.im  Wed Oct  8 15:15:32 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Oct 2008 14:15:32 -0600
Subject: [Council] meeting minutes, 2008-10-08
Message-ID: <48ED14E4.9050404@stpeter.im>

Results of the XMPP Council meeting held 2008-10-08...

Agenda:

http://xmpp.org/council/agendas/2008-10-08.html

Log:

http://logs.jabber.org/council at conference.jabber.org/2008-10-08.html

Scribe: Peter Saint-Andre

0. Roll call

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

All members of the Eighth XMPP Council present, quorum achieved.

1. Agenda bashing

None.

2. Orientation

None required.

3. Choice of Chair for Eighth Council

Peter Saint-Andre nominated Kevin Smith. Dave Cridland seconded. All in
favor. Kevin Smith is the Chair for the Eighth Council (2008-2009).

4. XEP-0053: XMPP Registrar Function

Approve version 1.4rc1?

No final consensus on changes to the namespace issuance process.
Discussion to be continued on the standards at xmpp.org list and at the
next Council meeting.

5. Deprecated XEPs (78, 90, 91).

These need to be extended in the Deprecated state or changed to Obsolete.

   5a. XEP-0078: Non-SASL Authentication

   Consensus on changing this to Obsolete.

   5b. XEP-0090: Entity Time

   Near consensus on changing this to Obsolete.

   5c. XEP-0091: Delayed Delivery

   Consensus that we need to determine how widely XEP-0203 is
   deployed before changing this to Obsolete.

6. XEP-0012: Last Activity

Consensus to issue Call for Experience in preparation for advancing this
Standards Track XEP to Final.

7. XEP-0085: Chat State Notifications

Consensus to issue Call for Experience in preparation for advancing this
Standards Track XEP to Final.

8 - 18. [These items not covered.]

19. Any other business?

None.

20. Next meeting

Date: Wednesday, October 15, 2008.
Time: 19:00 UTC.
Place: xmpp:council at conference.jabber.org

Peter

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


From kevin at kismith.co.uk  Tue Oct 14 06:36:42 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 14 Oct 2008 12:36:42 +0100
Subject: [Council] Council meeting 2008-10-15
Message-ID: <f5aae3ec0810140436p3d4539c7gd85dc1d3b37e5789@mail.gmail.com>

Hi all.
  Assuming I managed to do this correctly, there should be an agenda
for tomorrow's meeting available at:
http://xmpp.org/council/agendas/2008-10-15.html

I'll finish going through the way Peter did these things at some point
soon so we have prettier (and more efficient!) agendaing.

/K

From stpeter at stpeter.im  Wed Oct 15 15:03:52 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 15 Oct 2008 14:03:52 -0600
Subject: [Council] Status of XEP-0220 (Server Dialback)
Message-ID: <48F64CA8.7080103@stpeter.im>

When we hived XEP-0220 off from RFC 3920, we made it Experimental.
That's always struck me as odd, given that it came from the RFC. IMHO it
would have been better to make it Draft immediately. In fact I think we
intended to do that but I neglected to. Anyway I will give it a thorough
review one of these days and perhaps we can move it forward. :)

P

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


From stpeter at stpeter.im  Wed Oct 15 15:25:56 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 15 Oct 2008 14:25:56 -0600
Subject: [Council] meeting minutes, 2008-10-15
Message-ID: <48F651D4.8080603@stpeter.im>

Results of the XMPP Council meeting held 2008-10-15...

Agenda:

http://xmpp.org/council/agendas/2008-10-15.html

Log:

http://logs.jabber.org/council at conference.jabber.org/2008-10-15.html

Scribe: Peter Saint-Andre

0. Roll call

Present: Jack Moffitt, Peter Saint-Andre, Kevin Smith.

Dave Cridland and Ralph Meijer sent their regrets, will vote on the list.

Quorum achieved.

1. Agenda bashing

None.

2. XEP-0053: XMPP Registrar Function

Approve version 1.4rc1?

Jack, Peter, and Kevin reached consensus on the approach outlined in
1.4rc1, and voted +1. Dave and Ralph to vote on the list.

3. Other specs to consider for advancement to Final.

Skipped (holdover from 2008-10-08 meeting).

4. XEP-0124: BOSH -- Approve version 1.7rc2?
5. XEP-0206: XMPP Over BOSH -- Approve version 1.2rc2?

Jack and Peter +1 per discussion on the bosh at xmpp.org list and recent
BOSH groupchat. Kevin to review those discussions and vote on the
council at xmpp.org list. Dave and Ralph to vote on the list as well. Given
that the bosh@ list is not the official place to discuss XEPs, Peter to
post to the standards at xmpp.org as a sanity check.

6. XEP-0080: User Geolocation

Approve version 1.6rc2?

Jack noted that the change may not be backwards-compatible, since
<error/> is deprecated so new implementations will implement <accuracy/>
instead and therefore old and new won't be able to communicate this
information. To discuss on the standards@ list.

7. XEP-0107: User Mood

Approve version 1.2rc2?

Jack, Peter, and Kevin +1. Dave and Ralph to vote on the list.

8. XEP-0108: User Activity

Approve version 1.3rc1?

Jack, Peter, and Kevin +1. Dave and Ralph to vote on the list.

9. XEP-0205: Best Practices to Discourage Denial of Service Attacks

Issue Last Call for advancing this Informational XEP to Active?

Jack, Peter, and Kevin +1. Dave and Ralph to post to the list if they
have objections.

10. XEP-0224: Attention

Issue Last Call for advancing this Standards Track XEP to Draft?

Jack, Peter, and Kevin +1. Dave and Ralph to post to the list if they
have objections.

11. Proto-XEP: PubSub Chaining

Accept version 0.0.2 for official publication as a XEP?

Jack and Peter +1. Dave, Ralph, and Kevin to post to the list if they
have objections.

12. Proto-XEP: PubSub Queueing

Accept version 0.0.3 for official publication as a XEP?

Jack and Peter +1. Dave, Ralph, and Kevin to post to the list if they
have objections.

13. Minor spec cleanup on Jabber Search and Result Set Management.

Skipped (not a real agenda item because not votable).

14. Any Other Business?

None.

15. Next Meeting

Wednesday, 2008-10-22, 20:00 UTC.

/psa

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


From jabberfoundation at ralphm.ik.nu  Thu Oct 16 01:36:29 2008
From: jabberfoundation at ralphm.ik.nu (Ralph Meijer)
Date: Thu, 16 Oct 2008 08:36:29 +0200
Subject: [Council] Status of XEP-0220 (Server Dialback)
In-Reply-To: <48F64CA8.7080103@stpeter.im>
References: <48F64CA8.7080103@stpeter.im>
Message-ID: <20081016063629.GA18054@ik.nu>

On Wed, Oct 15, 2008 at 02:03:52PM -0600, Peter Saint-Andre wrote:
> When we hived XEP-0220 off from RFC 3920, we made it Experimental.
> That's always struck me as odd, given that it came from the RFC. IMHO it
> would have been better to make it Draft immediately. In fact I think we
> intended to do that but I neglected to. Anyway I will give it a thorough
> review one of these days and perhaps we can move it forward. :)

Yeah, it should have been at least Draft. As I am reviewing my dialback
code for inclusion in Twisted, writing more unit tests and all, I've
also reviewed this XEP and made a bunch of notes, so I'll send those
soon.

-- 
Groetjes,

ralphm

From stpeter at stpeter.im  Thu Oct 16 10:22:14 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 16 Oct 2008 09:22:14 -0600
Subject: [Council] Status of XEP-0220 (Server Dialback)
In-Reply-To: <20081016063629.GA18054@ik.nu>
References: <48F64CA8.7080103@stpeter.im> <20081016063629.GA18054@ik.nu>
Message-ID: <48F75C26.9040201@stpeter.im>

Ralph Meijer wrote:
> On Wed, Oct 15, 2008 at 02:03:52PM -0600, Peter Saint-Andre wrote:
>> When we hived XEP-0220 off from RFC 3920, we made it Experimental.
>> That's always struck me as odd, given that it came from the RFC. IMHO it
>> would have been better to make it Draft immediately. In fact I think we
>> intended to do that but I neglected to. Anyway I will give it a thorough
>> review one of these days and perhaps we can move it forward. :)
> 
> Yeah, it should have been at least Draft. As I am reviewing my dialback
> code for inclusion in Twisted, writing more unit tests and all, I've
> also reviewed this XEP and made a bunch of notes, so I'll send those
> soon.

Thanks, Ralph. I'm reviewing both XEP-0220 and XEP-0238 right now, too
(gotta rest my hands a bit so I'm marking them up on paper), so I may
send a message to the standards@ list or just release updated versions.

I hope you're feeling better. :)

Peter


From kevin at kismith.co.uk  Tue Oct 21 16:52:45 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 21 Oct 2008 22:52:45 +0100
Subject: [Council] Meeting 2008-10-22
Message-ID: <f5aae3ec0810211452v50a83a1ctf54ed367b04e796@mail.gmail.com>

Hi all.
  Sorry for a late agenda again, but it's short:
http://xmpp.org/council/agendas/2008-10-22.html

See you tomorrow at 7pm, UTC.

/K

From stpeter at stpeter.im  Tue Oct 21 17:00:10 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Oct 2008 16:00:10 -0600
Subject: [Council] Meeting 2008-10-22
In-Reply-To: <f5aae3ec0810211452v50a83a1ctf54ed367b04e796@mail.gmail.com>
References: <f5aae3ec0810211452v50a83a1ctf54ed367b04e796@mail.gmail.com>
Message-ID: <48FE50EA.3010702@stpeter.im>

Kevin Smith wrote:
> Hi all.
>   Sorry for a late agenda again, but it's short:
> http://xmpp.org/council/agendas/2008-10-22.html

Thanks! Here are some reminders for folks who didn't vote last time:

http://xmpp.org/council/agendas/2008-10-15.html

http://mail.jabber.org/pipermail/council/2008-October/002393.html

Peter

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


From dave at cridland.net  Wed Oct 22 06:29:37 2008
From: dave at cridland.net (Dave Cridland)
Date: Wed, 22 Oct 2008 12:29:37 +0100
Subject: [Council] Votes from 2008-10-15
Message-ID: <10893.1224674977.697485@peirce.dave.cridland.net>

Finally...

2) Can we actually vote? It says <approver>Board</approver>, which  
seems to suggest we can't. (Well, we can, we just can't approve it  
based on such a vote).

I note that the XMPP Registrar doesn't actually make the registration  
while the document is in Experimental state, and I'm mildly concerned  
that this can - in theory - lead to a state where two XEPs in  
Experimental end up with the same namespace, which is a bit silly.

In practise, I assume that we do actually track what namespaces are  
used by Experimental XEPs, so it seems sensible for the XMPP  
Registrar to make a note of these in the same way as any other used  
namespace.

Also, the use of the phrase "[...], or if significant new features  
have been added" I find somewhat misleading - it suggests that  
there's a case where the "new" protocol is entirely backwards  
compatible with the "old" - ie, there is no loss of interoperability  
- but we still want to change the namespace to break said  
interoperability. I'm not clear what case this is.

So, if my vote meant anything, I'd vote -1. But we're very close. :-)

3) I don't know of any reason not to press on with those.

4) There's a significant amount of small cleanup work here. It'd be  
useful to have these seperated out.

However, I've gone through it all and I'll vote +1 to both the  
changed XEP-0124 and bosh-script.

5) No idea, so I'll go through the mailing list as see if I can get a  
handle on the change.

6) +1

7) I still think USer Mood is very silly, but ours not to reason why.  
+1.

8) I think this is approaching silliness, too, but +1.

9/10) +1 to Last Call, however I'd like us to watch these carefully  
to ensure we are actually getting feedback.

11/12) In both cases I'm not convinced the motivation matches the  
design at all. I've a very different view of how chaining might work  
- this design seems to fit aggregation better than chaining - and I'm  
not convinced that PubSub and Queueing fit naturally into the same  
model.

I think I need, in both cases, to have a chat with the authors to get  
a better handle on what exactly is required.

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

From stpeter at stpeter.im  Wed Oct 22 09:05:56 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Oct 2008 08:05:56 -0600
Subject: [Council] Votes from 2008-10-15
In-Reply-To: <10893.1224674977.697485@peirce.dave.cridland.net>
References: <10893.1224674977.697485@peirce.dave.cridland.net>
Message-ID: <48FF3344.5010905@stpeter.im>

Dave Cridland wrote:
> Finally...
> 
> 2) Can we actually vote? It says <approver>Board</approver>, which seems
> to suggest we can't. (Well, we can, we just can't approve it based on
> such a vote).

Thank you for your close attention to detail. :P

The Board was the entity that originally approved the formation of the
XMPP Registrar function. I think that a change to the Registrar's
namespace issuance process is more within the purview of the Council,
and in general we prefer to ask the Council for its advice and input on
technical matters such as this. However, we could still ask the Board
for its approval, too (which in technical matters it will typically just
rubber-stamp). If I recall correctly, that is how we've proceeded with
previous changes to XEP-0001 and XEP-0053 (ask both the Board and the
Council to approve).

> I note that the XMPP Registrar doesn't actually make the registration
> while the document is in Experimental state, and I'm mildly concerned
> that this can - in theory - lead to a state where two XEPs in
> Experimental end up with the same namespace, which is a bit silly.

Correct, the namespaces are minted when the XEP is Experimental but not
registered until the XEP is Draft. Registering every namespace might
clutter up the registry with namespaces that are not approved and never
will be, and that strikes me as a bad idea (in particular it might cause
confusion regarding which namespaces are approved and which are not).

> In practise, I assume that we do actually track what namespaces are used
> by Experimental XEPs, so it seems sensible for the XMPP Registrar to
> make a note of these in the same way as any other used namespace.

All namespaces are checked for uniqueness before they are minted, and
that check includes XEPs in all states, not just Draft or Final. Would
you prefer to make that explicit?

> Also, the use of the phrase "[...], or if significant new features have
> been added" I find somewhat misleading - it suggests that there's a case
> where the "new" protocol is entirely backwards compatible with the "old"
> - ie, there is no loss of interoperability - but we still want to change
> the namespace to break said interoperability. I'm not clear what case
> this is.

I agree to strike that clause.

> So, if my vote meant anything, I'd vote -1. But we're very close. :-)

Your feedback is appreciated.

> 3) I don't know of any reason not to press on with those.

I assume that the Council Chair will add those to future agendas.

> 4) There's a significant amount of small cleanup work here. It'd be
> useful to have these seperated out.

What format would you find useful? A more detailed changelog?

> However, I've gone through it all and I'll vote +1 to both the changed
> XEP-0124 and bosh-script.

OK.

> 5) No idea, so I'll go through the mailing list as see if I can get a
> handle on the change.

Thanks.

> 6) +1

Jack raised an issue about backwards-compatibility regarding the
<error/> and <accuracy/> elements, and I sent a "poll" about this to the
jdev@ and standards@ lists. One solution would be to say that
implementations shall support both <error/> (= offset in arc minutes)
and <accuracy/> (= offset in meters) for some period of time, i.e., to
not immediately deprecate <error/>. But first we need to find out if any
implementations support <error/> (I have my doubts).

> 7) I still think USer Mood is very silly, but ours not to reason why. +1.

Well, your mood is always grumpy so I can see why you'd think the idea
of publishing mood changes is silly. ;-)

> 8) I think this is approaching silliness, too, but +1.

If you ask me, activity is even more risible than mood. But I try not to
let me personal usage and biases interfere with publishing specs that
some parts of the community deem useful (unless the protocol would cause
positive harm).

> 9/10) +1 to Last Call, however I'd like us to watch these carefully to
> ensure we are actually getting feedback.

I think XEP-0224 is relatively harmless. But I would like to get some
more significant feedback on the denial of service considerations since
that is referenced from rfc3920bis. I think I'll ask for feedback about
that on the operators@ list in addition to standards@ and jdev at .

> 11/12) In both cases I'm not convinced the motivation matches the design
> at all. I've a very different view of how chaining might work - this
> design seems to fit aggregation better than chaining - and I'm not
> convinced that PubSub and Queueing fit naturally into the same model.
> 
> I think I need, in both cases, to have a chat with the authors to get a
> better handle on what exactly is required.

Fine with me. :)

Peter

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



From dave at cridland.net  Wed Oct 22 09:47:41 2008
From: dave at cridland.net (Dave Cridland)
Date: Wed, 22 Oct 2008 15:47:41 +0100
Subject: [Council] Votes from 2008-10-15
In-Reply-To: <48FF3344.5010905@stpeter.im>
References: <10893.1224674977.697485@peirce.dave.cridland.net>
	<48FF3344.5010905@stpeter.im>
Message-ID: <19781.1224686861.101767@peirce.dave.cridland.net>

On Wed Oct 22 15:05:56 2008, Peter Saint-Andre wrote:
> > I note that the XMPP Registrar doesn't actually make the  
> registration
> > while the document is in Experimental state, and I'm mildly  
> concerned
> > that this can - in theory - lead to a state where two XEPs in
> > Experimental end up with the same namespace, which is a bit silly.
> 
> Correct, the namespaces are minted when the XEP is Experimental but  
> not
> registered until the XEP is Draft. Registering every namespace might
> clutter up the registry with namespaces that are not approved and  
> never
> will be, and that strikes me as a bad idea (in particular it might  
> cause
> confusion regarding which namespaces are approved and which are  
> not).
> 
> 
Well, I think no more so than the clutter of Experimental vs Draft  
XEPs, really. I'm not saying "show them by default in registry views".


> > In practise, I assume that we do actually track what namespaces  
> are used
> > by Experimental XEPs, so it seems sensible for the XMPP Registrar  
> to
> > make a note of these in the same way as any other used namespace.
> 
> All namespaces are checked for uniqueness before they are minted,  
> and
> that check includes XEPs in all states, not just Draft or Final.  
> Would
> you prefer to make that explicit?
> 
> 
Documenting the existing practise always seems like a good idea.

> > 4) There's a significant amount of small cleanup work here. It'd  
> be
> > useful to have these seperated out.
> 
> What format would you find useful? A more detailed changelog?

No, actually - on reflection, I'm just moaning, really.

If "minor changes" and suchlike got moved out of the way, it'd only  
come back to bite us when some minor slip had technical impact.

> Jack raised an issue about backwards-compatibility regarding the
> <error/> and <accuracy/> elements, and I sent a "poll" about this  
> to the
> jdev@ and standards@ lists. One solution would be to say that
> implementations shall support both <error/> (= offset in arc  
> minutes)
> and <accuracy/> (= offset in meters) for some period of time, i.e.,  
> to
> not immediately deprecate <error/>. But first we need to find out  
> if any
> implementations support <error/> (I have my doubts).
> 
> 
Not only whether they support it, but whether they support it  
intentionally interoperably and rely upon it. I suspect we're early  
enough to make this change, and any applications which actually use  
it are quite likely talking to other instances of themselves, or form  
some similarly homogenous network.


> > 7) I still think USer Mood is very silly, but ours not to reason  
> why. +1.
> 
> Well, your mood is always grumpy so I can see why you'd think the  
> idea
> of publishing mood changes is silly. ;-)
> 
> 
<offended/> ;-)

Actually, it's largely down to the bizarre, and sometimes worrying,  
choices of iconography in Gajim. I'm sure that "Aroused" uses an icon  
intended to depict "Unexpected Body Cavity Search", and most of them  
appear to depict various stages of "Constipated".


> > 8) I think this is approaching silliness, too, but +1.
> 
> If you ask me, activity is even more risible than mood. But I try  
> not to
> let me personal usage and biases interfere with publishing specs  
> that
> some parts of the community deem useful (unless the protocol would  
> cause
> positive harm).
> 
> 
In a lot of cases, I can see good uses for the Activity, although  
it'd be more use if PEP Activity states were tied into user defined  
rich presence states, and made available through a simple drop-down  
in the client. Knowing that someone's present, but eating, gives me  
useful cues to response time, etc.

As well as satisfying my noseyness.

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

From stpeter at stpeter.im  Wed Oct 22 10:20:57 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Oct 2008 09:20:57 -0600
Subject: [Council] Votes from 2008-10-15
In-Reply-To: <19781.1224686861.101767@peirce.dave.cridland.net>
References: <10893.1224674977.697485@peirce.dave.cridland.net>	<48FF3344.5010905@stpeter.im>
	<19781.1224686861.101767@peirce.dave.cridland.net>
Message-ID: <48FF44D9.90001@stpeter.im>

Dave Cridland wrote:
> On Wed Oct 22 15:05:56 2008, Peter Saint-Andre wrote:
>> > I note that the XMPP Registrar doesn't actually make the registration
>> > while the document is in Experimental state, and I'm mildly concerned
>> > that this can - in theory - lead to a state where two XEPs in
>> > Experimental end up with the same namespace, which is a bit silly.
>>
>> Correct, the namespaces are minted when the XEP is Experimental but not
>> registered until the XEP is Draft. Registering every namespace might
>> clutter up the registry with namespaces that are not approved and never
>> will be, and that strikes me as a bad idea (in particular it might cause
>> confusion regarding which namespaces are approved and which are not).
>>
>>
> Well, I think no more so than the clutter of Experimental vs Draft XEPs,
> really. I'm not saying "show them by default in registry views".

Currently there is only one registry view and we don't track the
"status" of registry items as we track the status of specifications.

>> > In practise, I assume that we do actually track what namespaces are
>> used
>> > by Experimental XEPs, so it seems sensible for the XMPP Registrar to
>> > make a note of these in the same way as any other used namespace.
>>
>> All namespaces are checked for uniqueness before they are minted, and
>> that check includes XEPs in all states, not just Draft or Final. Would
>> you prefer to make that explicit?
>>
>>
> Documenting the existing practise always seems like a good idea.

True.

[6] XEP-0080

>> Jack raised an issue about backwards-compatibility regarding the
>> <error/> and <accuracy/> elements, and I sent a "poll" about this to the
>> jdev@ and standards@ lists. One solution would be to say that
>> implementations shall support both <error/> (= offset in arc minutes)
>> and <accuracy/> (= offset in meters) for some period of time, i.e., to
>> not immediately deprecate <error/>. But first we need to find out if any
>> implementations support <error/> (I have my doubts).
>>
>>
> Not only whether they support it, but whether they support it
> intentionally interoperably and rely upon it. I suspect we're early
> enough to make this change, and any applications which actually use it
> are quite likely talking to other instances of themselves, or form some
> similarly homogenous network.

Well, let's see what the poll results show before jumping to
conclusions. No responses yet, so I'll need to start pinging people
individually, methinks.

>> > 7) I still think USer Mood is very silly, but ours not to reason
>> why. +1.
>>
>> Well, your mood is always grumpy so I can see why you'd think the idea
>> of publishing mood changes is silly. ;-)
>>
>>
> <offended/> ;-)
> 
> Actually, it's largely down to the bizarre, and sometimes worrying,
> choices of iconography in Gajim. I'm sure that "Aroused" uses an icon
> intended to depict "Unexpected Body Cavity Search", and most of them
> appear to depict various stages of "Constipated".

I have no idea what the iconography suggests, because I'm more of a
textual person myself (and I don't use Gajim).

>> > 8) I think this is approaching silliness, too, but +1.
>>
>> If you ask me, activity is even more risible than mood. But I try not to
>> let me personal usage and biases interfere with publishing specs that
>> some parts of the community deem useful (unless the protocol would cause
>> positive harm).
>>
>>
> In a lot of cases, I can see good uses for the Activity, although it'd
> be more use if PEP Activity states were tied into user defined rich
> presence states, and made available through a simple drop-down in the
> client. Knowing that someone's present, but eating, gives me useful cues
> to response time, etc.

Talk to the developers of your favorite client, or submit a patch.
That's what I always do (the former, not the latter). :)

> As well as satisfying my noseyness.

Always critically important.

So out of this little thread I take away the need for some edits to
XEP-0053; I'll work those in Real Soon Now [tm].

Peter

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


From stpeter at stpeter.im  Wed Oct 22 10:29:31 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Oct 2008 09:29:31 -0600
Subject: [Council] Votes from 2008-10-15
In-Reply-To: <48FF44D9.90001@stpeter.im>
References: <10893.1224674977.697485@peirce.dave.cridland.net>	<48FF3344.5010905@stpeter.im>	<19781.1224686861.101767@peirce.dave.cridland.net>
	<48FF44D9.90001@stpeter.im>
Message-ID: <48FF46DB.7010508@stpeter.im>

Peter Saint-Andre wrote:

> So out of this little thread I take away the need for some edits to
> XEP-0053; I'll work those in Real Soon Now [tm].

Done.

http://xmpp.org/extensions/tmp/xep-0053-1.4.html

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0053.xml

/psa

From stpeter at stpeter.im  Wed Oct 22 12:26:46 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Oct 2008 11:26:46 -0600
Subject: [Council] Meeting 2008-10-22
In-Reply-To: <f5aae3ec0810211452v50a83a1ctf54ed367b04e796@mail.gmail.com>
References: <f5aae3ec0810211452v50a83a1ctf54ed367b04e796@mail.gmail.com>
Message-ID: <48FF6256.5050506@stpeter.im>

Kevin Smith wrote:
> Hi all.
>   Sorry for a late agenda again, but it's short:
> http://xmpp.org/council/agendas/2008-10-22.html

That agenda is indeed short. Maybe too short. :P Here's another ProtoXEP
we might want to discuss:

http://xmpp.org/extensions/inbox/jingle-transfer.html

Hot off the presses!

Peter

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


From stpeter at stpeter.im  Wed Oct 22 16:25:30 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Oct 2008 15:25:30 -0600
Subject: [Council] meeting minutes, 2008-10-22
Message-ID: <48FF9A4A.6090100@stpeter.im>

Results of the XMPP Council meeting held 2008-10-22...

Agenda:

http://xmpp.org/council/agendas/2008-10-22.html

Log:

http://logs.jabber.org/council at conference.jabber.org/2008-10-22.html

Scribe: Peter Saint-Andre

0. Roll call

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

Absent: Ralph Meijer.

Quorum achieved.

1. Agenda bashing

None.

2. Voting reminder

Council members are reminded to vote on items from 2008-10-22.

http://xmpp.org/council/policies.shtml defines the Council's voting
policies, specifically the 10-day rule for voting periods, after which a
Council member shall be logged as "Did Not Vote" (effectively a vote of
"0" but noted as not voting). Council consensus that the voting period
shall be deemed to start at the Council meeting at which the item is
first brought for a vote.

Note: this implies that Council members have until 19:00 UTC on
Saturday, October 25 to vote on the items from the meeting on Wednesday,
October 15. To see if you have votes outstanding, please consult the
following:

http://xmpp.org/council/agendas/2008-10-15.html
http://mail.jabber.org/pipermail/council/2008-October/002393.html
http://logs.jabber.org/council at conference.jabber.org/2008-10-15.html
http://xmpp.org/council/tallies_08.shtml

Peter noted that, traditionally, an official vote of the Council is
either (1) a decision to modify the Status of a XEP or (2) a decision to
modify a Draft or Final XEP. In particular, decisions to issue Last
Calls, to accept ProtoXEPs as XEPs, and to issue Calls for Experience
are not official votes and can proceed with the assent of the majority
of the Council in quorum (not subject to the 10-day rule).

Therefore, since a majority of the Council in quorum assented to issuing
Last Calls for XEP-0165 and XEP-0224 in the 2008-10-15, the XEP Editor
shall issue these Last Calls.

3. XEP-0220: Server Dialback

Council consensus to keep this in XEP-0220 (not to move it back to
rfc3920bis or to publish a separate Internet-Draft), and to issue a Last
Call for advancement of XEP-0220 to Draft. Therefore the XEP Editor
shall issue a Last Call regarding XEP-0220.

4. Namespace wellformedness

The Council held a lengthy discussion beginning here:

http://logs.jabber.org/council at conference.jabber.org/2008-10-22.html#15:25:27

Dave will post a message summarizing the issues to the standards@ list.
After Dave posts his message, Peter will send individual messages to
each major server vendor/project to gather their feedback.

5. ProtoXEP - Jingle Session Transfer

No objections to publishing this as a XEP, so the XEP Editor shall
publish it. Some errors noted, and Peter will fix those before publication.

6. Any other business?

The Council decided to maintain its weekly meeting schedule for the
foreseeable future.

7. Next meeting

Wednesday, 2008-10-29 @ 20:00 UTC (this will be Standard Time in UK/NL
and Daylight Saving Time in the USA, so check your local time!).

Peter

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


From stpeter at stpeter.im  Wed Oct 22 16:49:09 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 22 Oct 2008 15:49:09 -0600
Subject: [Council] meeting minutes, 2008-10-22
In-Reply-To: <48FF9A4A.6090100@stpeter.im>
References: <48FF9A4A.6090100@stpeter.im>
Message-ID: <48FF9FD5.1060306@stpeter.im>

Peter Saint-Andre wrote:

> Therefore, since a majority of the Council in quorum assented to issuing
> Last Calls for XEP-0165 and XEP-0224 in the 2008-10-15, the XEP Editor
> shall issue these Last Calls.

Sorry, that is *XEP-0205* and XEP-0224.

Peter

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


From kevin at kismith.co.uk  Thu Oct 23 11:00:43 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Thu, 23 Oct 2008 17:00:43 +0100
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <48F651D4.8080603@stpeter.im>
References: <48F651D4.8080603@stpeter.im>
Message-ID: <f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>

Time to clean up my votes.

> 4. XEP-0124: BOSH -- Approve version 1.7rc2?

+1

> 5. XEP-0206: XMPP Over BOSH -- Approve version 1.2rc2?

+1

> 6. XEP-0080: User Geolocation

I've not seen anyone complain on list that they've implemented the old
errors, so I'm +1

> 11. Proto-XEP: PubSub Chaining
> 12. Proto-XEP: PubSub Queueing

I'd like to hold off until Dave's comments have come through, but not
inherently against them going to experimental.

Best,
/k

From stpeter at stpeter.im  Thu Oct 23 15:18:03 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 23 Oct 2008 14:18:03 -0600
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>
References: <48F651D4.8080603@stpeter.im>
	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>
Message-ID: <4900DBFB.9050905@stpeter.im>

Duly noted:

http://xmpp.org/council/tallies_08.shtml

I'm +1 on XEP-0080 as well, but I will endeavor to poke people whom I
know have implemented it to be sure.

Kevin Smith wrote:
> Time to clean up my votes.
> 
>> 4. XEP-0124: BOSH -- Approve version 1.7rc2?
> 
> +1
> 
>> 5. XEP-0206: XMPP Over BOSH -- Approve version 1.2rc2?
> 
> +1
> 
>> 6. XEP-0080: User Geolocation
> 
> I've not seen anyone complain on list that they've implemented the old
> errors, so I'm +1
> 
>> 11. Proto-XEP: PubSub Chaining
>> 12. Proto-XEP: PubSub Queueing
> 
> I'd like to hold off until Dave's comments have come through, but not
> inherently against them going to experimental.
> 
> Best,
> /k

From stpeter at stpeter.im  Fri Oct 24 16:51:57 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 24 Oct 2008 15:51:57 -0600
Subject: [Council] final voting reminder!
Message-ID: <4902437D.70001@stpeter.im>

Our illustrious Council Chair is serious about the 10-day limit on
voting, therefore as XMPP Extensions Editor I will send out a voting
reminder 24 hours before the end of each voting period. This is the
first such reminder.

By my accounting, the following votes are due from the 2008-10-15 meeting:

Dave Cridland: XEP-0053, XEP-0206, XEP-0080

Ralph Meijer: XEP-0053, XEP-0124, XEP-0206, XEP-0080, XEP-0107, XEP-0108

Jack Moffitt: XEP-0080 (in fact Jack voted +1 [0] but expressed a worry
about backwards-compatibility so I suppose I can mark him as +1...)

If you do not vote within the next 24 hours, you will be counted as "Did
Not Vote" (which is effectively zero but with a note that you did not
vote for the purpose of public shaming).

/psa

[0]
http://logs.jabber.org/council at conference.jabber.org/2008-10-15.html#14:27:18


From dave at cridland.net  Fri Oct 24 17:30:31 2008
From: dave at cridland.net (Dave Cridland)
Date: Fri, 24 Oct 2008 23:30:31 +0100
Subject: [Council] final voting reminder!
In-Reply-To: <4902437D.70001@stpeter.im>
References: <4902437D.70001@stpeter.im>
Message-ID: <14395.1224887431.352323@peirce.dave.cridland.net>

On Fri Oct 24 22:51:57 2008, Peter Saint-Andre wrote:
> Dave Cridland: XEP-0053,

Hmmm - I *did* register my vote, and it's even counted on the tally.  
I'm assuming this 10 days rule doesn't really mean "10 days to vote  
yes". ;-)

I'd think issuing a new version requires restarting the counter, and,  
I suspect it may more votes from all members, too. Just because I was  
the only dissenter for 1.4rc1 does not mean everyone else will  
automatically agree with 1.4rc2...

However, the changes in the current 1.4 look fine to me. But I'd like  
to know that other folk are still okay.

And yes, I do seem to be becoming very picky about procedure, don't I?

While I'm being so picky, perhaps the right thing for the tally is  
actually:

a) As Date, the date when the vote was officially commenced. I'd  
think this ought to be the first meeting for which the document is  
placed on the agenda, or when the new revision were submitted.

b) Each new revision, post-rejection, should create a new line. So in  
this case, we'd have:

XEP-0053		-1	.	+1	+1	+1	2008/10/15
XEP-0053		+1	.	.	.	.	2008/10/22

c) I suspect that we still need a 10 day timeout for those  
"re-votes", but rather than DNV they should default. This effectively  
means you've 10 days to review the changes.

I have to admit, I'd like to see vetos recorded.

>  XEP-0206, 

Reading through BOSH I noticed other stuff that needs a bit of work -  
nothing major, just oddities.

body MUST be empty - good.
server SHOULD ignore - fine.
server MAY send - wrong - this is not truly optional behaviour.

"[...] SHOULD ignore it. Some implementation are known to send that  
stanza when [...]" is prefereable, to avoid the implication that  
sending the stanza is actually okay.

Assuming you fix this, I'm +1, but as things stand that's a -1.

> XEP-0080

I voted +1 already, honest! (On the list, with absolutely no  
commentry, just "6) +1").

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  Fri Oct 24 17:54:36 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 24 Oct 2008 16:54:36 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <14395.1224887431.352323@peirce.dave.cridland.net>
References: <4902437D.70001@stpeter.im>
	<14395.1224887431.352323@peirce.dave.cridland.net>
Message-ID: <4902522C.1040006@stpeter.im>

Dave Cridland wrote:
> On Fri Oct 24 22:51:57 2008, Peter Saint-Andre wrote:
>> Dave Cridland: XEP-0053,
> 
> Hmmm - I *did* register my vote, and it's even counted on the tally. I'm
> assuming this 10 days rule doesn't really mean "10 days to vote yes". ;-)

I wanted to get clarification from you about whether version 1.4rc2
addressed your concerns.

> I'd think issuing a new version requires restarting the counter, and, I
> suspect it may more votes from all members, too. Just because I was the
> only dissenter for 1.4rc1 does not mean everyone else will automatically
> agree with 1.4rc2...

So would it have been OK if I had addressed your concerns without
changing the interim version from 1.4rc1 to 1.4rc2?

At some point this gets silly. You expressed a concern. No one else
expressed that concern, but they seemed to think that clarifying this
was a good idea (at least no one objected to further clarification
during the meeting). This is why we have meetings. If Council members
are not paying attention, or if they don't go to the meetings, or if
they don't track the xmpp-commits list, or if they just don't care about
a particular issue, that is their problem, and their concerns will not
be addressed. Tough luck.

> However, the changes in the current 1.4 look fine to me. But I'd like to
> know that other folk are still okay.

So "in future" (as you Brits say), shall we double check with Council
members for every concern that is addressed? And if so will we ever
finish any voting, given that a completely new vote will be required for
each minor revision? And what modifications require a revote?
Wordsmithing? Typo fixes? Changing a "may" to a "MAY"? Adding a missing
'id' attribute? But perhaps we need a Procedural XEP defining all this.
If we can ever vote it to Active.

> And yes, I do seem to be becoming very picky about procedure, don't I?

I think you're a DoS sent from the IETF. :P

> While I'm being so picky, perhaps the right thing for the tally is
> actually:
> 
> a) As Date, the date when the vote was officially commenced. I'd think
> this ought to be the first meeting for which the document is placed on
> the agenda, or when the new revision were submitted.
> 
> b) Each new revision, post-rejection, should create a new line. So in
> this case, we'd have:
> 
> XEP-0053        -1    .    +1    +1    +1    2008/10/15
> XEP-0053        +1    .    .    .    .    2008/10/22
> 
> c) I suspect that we still need a 10 day timeout for those "re-votes",
> but rather than DNV they should default. This effectively means you've
> 10 days to review the changes.

DoS.

> I have to admit, I'd like to see vetos recorded.

More work. Is it worth it? People can look at the list archives, the
meeting logs, the SVN check-ins, etc., for interim discussion. We log
all that stuff for a reason.

Now, we *do* follow this kind of procedure for major changes. If we have
a vote on advancing (say) XEP-0166 from Experimental to Draft and
serious objections that are raised, thus requiring that we issue a new
version (currently that would be a change from 0.32 to 0.33), we would
revote. But for minor stuff like essentially removing one clause from a
sentence and clarifying an existing practice that is already familiar to
people ...

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

... well, I really don't think that level of voting detail is worth all
the time and effort. At that rate we'll never get anything done.

We need to balance the need for accuracy with the need to get things
done. I think the foregoing procedure puts us out of balance, but other
Council members may disagree.

>>  XEP-0206,
> 
> Reading through BOSH I noticed other stuff that needs a bit of work -
> nothing major, just oddities.
> 
> body MUST be empty - good.
> server SHOULD ignore - fine.
> server MAY send - wrong - this is not truly optional behaviour.
> 
> "[...] SHOULD ignore it. Some implementation are known to send that
> stanza when [...]" is prefereable, to avoid the implication that sending
> the stanza is actually okay.
> 
> Assuming you fix this, I'm +1, but as things stand that's a -1.

Great! I love -1 votes. It means that someone is paying attention.

I'll investigate the text you refer to here.

>> XEP-0080
> 
> I voted +1 already, honest! (On the list, with absolutely no commentry,
> just "6) +1").

I must have missed that, sorry.

Peter

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


From dave at cridland.net  Fri Oct 24 19:04:51 2008
From: dave at cridland.net (Dave Cridland)
Date: Sat, 25 Oct 2008 01:04:51 +0100
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>
References: <48F651D4.8080603@stpeter.im>
	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>
Message-ID: <14395.1224893091.318144@peirce.dave.cridland.net>

On Thu Oct 23 17:00:43 2008, Kevin Smith wrote:
> > 11. Proto-XEP: PubSub Chaining
> > 12. Proto-XEP: PubSub Queueing
> 
> I'd like to hold off until Dave's comments have come through, but  
> not
> inherently against them going to experimental.

Well, here's my "thing". I've not got back to the authors, I'm afraid  
- whenever I've had the time I've not seen them online, and I've code  
freezes and other nightmares.

On PubSub chaining, I think it's okay, although I suspect unsuitable  
for real repeaters - I think this model is right for aggregation, but  
not terribly interesting for the simple case. I've another design for  
shadowing entire services, both MUC and PubSub, that I really need  
the time to finish off.

On PubSub queueing, I'm concerned that this is entirely the wrong  
model. In particular, I'm wondering what happens when a na?ve pubsub  
client (or a repeater, like above) subscribed with the default  
options, expecting one behaviour and discovering another entirely. I  
suspect - but I'm really not sure - that it might need to be an  
entirely distinct interface.

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

From dave at cridland.net  Fri Oct 24 19:24:57 2008
From: dave at cridland.net (Dave Cridland)
Date: Sat, 25 Oct 2008 01:24:57 +0100
Subject: [Council] final voting reminder!
In-Reply-To: <4902522C.1040006@stpeter.im>
References: <4902437D.70001@stpeter.im>
	<14395.1224887431.352323@peirce.dave.cridland.net>
	<4902522C.1040006@stpeter.im>
Message-ID: <14395.1224894297.732414@peirce.dave.cridland.net>

On Fri Oct 24 23:54:36 2008, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> > On Fri Oct 24 22:51:57 2008, Peter Saint-Andre wrote:
> >> Dave Cridland: XEP-0053,
> >
> > Hmmm - I *did* register my vote, and it's even counted on the  
> tally. I'm
> > assuming this 10 days rule doesn't really mean "10 days to vote  
> yes". ;-)
> 
> I wanted to get clarification from you about whether version 1.4rc2
> addressed your concerns.
> 
> 
Sure, but if there's a 10-day timer on reviewing, finding any  
possible concerns, raising them, resolving them, re-reviewing, and so  
on, then it seems there is a very real risk that timer will expire. I  
appreciate that you came back quickly with some minor edits, and as  
it happens my concerns were very minor, and had the document passed  
through without further input that wouldn't have been a bad thing  
(except for me, anyway).

> > However, the changes in the current 1.4 look fine to me. But I'd  
> like to
> > know that other folk are still okay.
> 
> So "in future" (as you Brits say), shall we double check with  
> Council
> members for every concern that is addressed? And if so will we ever
> finish any voting, given that a completely new vote will be  
> required for
> each minor revision? And what modifications require a revote?
> Wordsmithing? Typo fixes? Changing a "may" to a "MAY"? Adding a  
> missing
> 'id' attribute? But perhaps we need a Procedural XEP defining all  
> this.
> If we can ever vote it to Active.
> 
> 
Hmmm.

The purpose of the Council, as I see it - and you can correct me if  
you like - is to provide an objective and informed viewpoint of  
changes to documents.

Now the moment any concern is raised, and that member is involved  
with its resolution, the member's viewpoint isn't as objective  
anymore. So arguably, they've become the member least able to look at  
the new revision as a whole.

So yes, I'd hope the other Council members are checking the  
resolution, just to make sure it's not introduced anything unexpected.


> > And yes, I do seem to be becoming very picky about procedure,  
> don't I?
> 
> I think you're a DoS sent from the IETF. :P

Oh, you've got clause 6 for that, no member can be an effective DoS.



> > While I'm being so picky, perhaps the right thing for the tally is
> > actually:
> >
> > a) As Date, the date when the vote was officially commenced. I'd  
> think
> > this ought to be the first meeting for which the document is  
> placed on
> > the agenda, or when the new revision were submitted.
> >
> > b) Each new revision, post-rejection, should create a new line.  
> So in
> > this case, we'd have:
> >
> > XEP-0053        -1    .    +1    +1    +1    2008/10/15
> > XEP-0053        +1    .    .    .    .    2008/10/22
> >
> > c) I suspect that we still need a 10 day timeout for those  
> "re-votes",
> > but rather than DNV they should default. This effectively means  
> you've
> > 10 days to review the changes.
> 
> DoS.
> 
> 
Okay, 5 days. But if you're saying there cannot be a timer restart,  
we have a different avenue for DoS, since that veto would have been  
ignored.

Would it have mattered, with this case? Doubtful. But in principle, a  
minor change to you might well be a major change to me.

Is it a good example to use to figure out the right policy? Good  
enough. I'd hate to find an example where it mattered and have to  
figure things out then.


> > I have to admit, I'd like to see vetos recorded.
> 
> More work. Is it worth it? People can look at the list archives, the
> meeting logs, the SVN check-ins, etc., for interim discussion. We  
> log
> all that stuff for a reason.
> 
> 
I think it's still important data to have listed at a glance,  
somewhere, if for no other reason than it provides a guage of  
performance next year.

> >>  XEP-0206,
> >
> > Reading through BOSH I noticed other stuff that needs a bit of  
> work -
> > nothing major, just oddities.
> >
> > body MUST be empty - good.
> > server SHOULD ignore - fine.
> > server MAY send - wrong - this is not truly optional behaviour.
> >
> > "[...] SHOULD ignore it. Some implementation are known to send  
> that
> > stanza when [...]" is prefereable, to avoid the implication that  
> sending
> > the stanza is actually okay.
> >
> > Assuming you fix this, I'm +1, but as things stand that's a -1.
> 
> Great! I love -1 votes. It means that someone is paying attention.

Ah, I only do it so I can prove I've read the stuff. ;-)

That was horribly unclear, though - I'm referring to the paragraph at  
line 220, and in particular the parentheses at the end.

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 jack at chesspark.com  Sat Oct 25 00:43:42 2008
From: jack at chesspark.com (Jack Moffitt)
Date: Fri, 24 Oct 2008 23:43:42 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <4902437D.70001@stpeter.im>
References: <4902437D.70001@stpeter.im>
Message-ID: <9b58f4550810242243k5d65aa9ch6e72c3470a6ed6c@mail.gmail.com>

> Jack Moffitt: XEP-0080 (in fact Jack voted +1 [0] but expressed a worry
> about backwards-compatibility so I suppose I can mark him as +1...)

Record me as +1.  No one responded that I saw to your request for more
info, so probably no one has an implementation that will break :)

jack.

From jack at chesspark.com  Sat Oct 25 00:47:50 2008
From: jack at chesspark.com (Jack Moffitt)
Date: Fri, 24 Oct 2008 23:47:50 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <14395.1224887431.352323@peirce.dave.cridland.net>
References: <4902437D.70001@stpeter.im>
	<14395.1224887431.352323@peirce.dave.cridland.net>
Message-ID: <9b58f4550810242247n1e98b7b4x42081505a5a51e86@mail.gmail.com>

>>  XEP-0206,
>
> Reading through BOSH I noticed other stuff that needs a bit of work -
> nothing major, just oddities.
>
> body MUST be empty - good.
> server SHOULD ignore - fine.
> server MAY send - wrong - this is not truly optional behaviour.
>
> "[...] SHOULD ignore it. Some implementation are known to send that stanza
> when [...]" is prefereable, to avoid the implication that sending the stanza
> is actually okay.
>
> Assuming you fix this, I'm +1, but as things stand that's a -1.

I also dislike the "server MAY send" language, but I'd have to go back
and look and see if that was discussed in our bosh meeting.

jack.

From dave at cridland.net  Sat Oct 25 03:47:03 2008
From: dave at cridland.net (Dave Cridland)
Date: Sat, 25 Oct 2008 09:47:03 +0100
Subject: [Council] final voting reminder!
In-Reply-To: <9b58f4550810242247n1e98b7b4x42081505a5a51e86@mail.gmail.com>
References: <4902437D.70001@stpeter.im>
	<14395.1224887431.352323@peirce.dave.cridland.net>
	<9b58f4550810242247n1e98b7b4x42081505a5a51e86@mail.gmail.com>
Message-ID: <14395.1224924423.466933@peirce.dave.cridland.net>

On Sat Oct 25 06:47:50 2008, Jack Moffitt wrote:
> I also dislike the "server MAY send" language, but I'd have to go  
> back
> and look and see if that was discussed in our bosh meeting.

I couldn't find any mention.

MUST NOT send and SHOULD NOT accept is a pretty common combination,  
but the MAY suggests that something is allowed, normal behaviour, and  
fine - I actually misread the phrase the first time.

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

From stpeter at stpeter.im  Mon Oct 27 15:00:52 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Oct 2008 14:00:52 -0600
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <14395.1224893091.318144@peirce.dave.cridland.net>
References: <48F651D4.8080603@stpeter.im>	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>
	<14395.1224893091.318144@peirce.dave.cridland.net>
Message-ID: <49061DF4.3070006@stpeter.im>

Dave Cridland wrote:
> On Thu Oct 23 17:00:43 2008, Kevin Smith wrote:
>> > 11. Proto-XEP: PubSub Chaining
>> > 12. Proto-XEP: PubSub Queueing
>>
>> I'd like to hold off until Dave's comments have come through, but not
>> inherently against them going to experimental.
> 
> Well, here's my "thing". I've not got back to the authors, I'm afraid -
> whenever I've had the time I've not seen them online, and I've code
> freezes and other nightmares.
> 
> On PubSub chaining, I think it's okay, although I suspect unsuitable for
> real repeaters - I think this model is right for aggregation, but not
> terribly interesting for the simple case. I've another design for
> shadowing entire services, both MUC and PubSub, that I really need the
> time to finish off.

Right, I think the use case Ralph had in mind was really aggregation.
Indeed I'm not really sure about that, but presumably he can illuminate
the matter. :)

> On PubSub queueing, I'm concerned that this is entirely the wrong model.
> In particular, I'm wondering what happens when a na?ve pubsub client (or
> a repeater, like above) subscribed with the default options, expecting
> one behaviour and discovering another entirely. I suspect - but I'm
> really not sure - that it might need to be an entirely distinct interface.

I've forwarded your comments on to Joe and perhaps we can have a
discussion about this on the pubsub@ list.

Peter

From stpeter at stpeter.im  Mon Oct 27 16:13:36 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Oct 2008 15:13:36 -0600
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <49061DF4.3070006@stpeter.im>
References: <48F651D4.8080603@stpeter.im>	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>	<14395.1224893091.318144@peirce.dave.cridland.net>
	<49061DF4.3070006@stpeter.im>
Message-ID: <49062F00.2070701@stpeter.im>

Peter Saint-Andre wrote:
> Dave Cridland wrote:
>
>> On PubSub queueing, I'm concerned that this is entirely the wrong model.
>> In particular, I'm wondering what happens when a na?ve pubsub client (or
>> a repeater, like above) subscribed with the default options, expecting
>> one behaviour and discovering another entirely. I suspect - but I'm
>> really not sure - that it might need to be an entirely distinct interface.
> 
> I've forwarded your comments on to Joe and perhaps we can have a
> discussion about this on the pubsub@ list.

Joe and I discussed it offlist. We think that if the naive subscriber
doesn't include subscription options, the queueing node needs to return
a <not-acceptable/> error with a pubsub-specific condition of
<configuration-required/>. In fact this is already specified:

http://xmpp.org/extensions/inbox/pubsub-queueing.html#example-1

So a naive client will never get subscribed to a queueing node in the
first place.

Peter

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


From stpeter at stpeter.im  Mon Oct 27 17:03:47 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Oct 2008 16:03:47 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <14395.1224924423.466933@peirce.dave.cridland.net>
References: <4902437D.70001@stpeter.im>	<14395.1224887431.352323@peirce.dave.cridland.net>	<9b58f4550810242247n1e98b7b4x42081505a5a51e86@mail.gmail.com>
	<14395.1224924423.466933@peirce.dave.cridland.net>
Message-ID: <49063AC3.9000305@stpeter.im>

Dave Cridland wrote:
> On Sat Oct 25 06:47:50 2008, Jack Moffitt wrote:
>> I also dislike the "server MAY send" language, but I'd have to go back
>> and look and see if that was discussed in our bosh meeting.
> 
> I couldn't find any mention.
> 
> MUST NOT send and SHOULD NOT accept is a pretty common combination, but
> the MAY suggests that something is allowed, normal behaviour, and fine -
> I actually misread the phrase the first time.

What exactly are we referring to here? Is it this paragraph?

Upon receiving the <success/> element, the client MUST then ask the
connection manager to restart the stream. It does this by setting to
"true" the 'xmpp:restart' attribute (qualified by the 'urn:xmpp:xbosh'
namespace) of the BOSH <body/> element. When sending the restart
request, the client SHOULD also include the 'to' and 'xml:lang'
attributes. In addition the <body/> MUST be empty (if the client
includes an XML stanza in the body, the connection manager SHOULD ignore
it but MAY send that stanza when the stream is restarted; however there
is no guarantee that a connection manager will send the stanza so a
client cannot rely on this behavior).



From stpeter at stpeter.im  Mon Oct 27 17:12:47 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Oct 2008 16:12:47 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <14395.1224894297.732414@peirce.dave.cridland.net>
References: <4902437D.70001@stpeter.im>	<14395.1224887431.352323@peirce.dave.cridland.net>	<4902522C.1040006@stpeter.im>
	<14395.1224894297.732414@peirce.dave.cridland.net>
Message-ID: <49063CDF.7080609@stpeter.im>

Dave Cridland wrote:
> On Fri Oct 24 23:54:36 2008, Peter Saint-Andre wrote:
>> Dave Cridland wrote:
>> > On Fri Oct 24 22:51:57 2008, Peter Saint-Andre wrote:
>> >> Dave Cridland: XEP-0053,
>> >
>> > Hmmm - I *did* register my vote, and it's even counted on the tally.
>> I'm
>> > assuming this 10 days rule doesn't really mean "10 days to vote
>> yes". ;-)
>>
>> I wanted to get clarification from you about whether version 1.4rc2
>> addressed your concerns.
>>
>>
> Sure, but if there's a 10-day timer on reviewing, finding any possible
> concerns, raising them, resolving them, re-reviewing, and so on, then it
> seems there is a very real risk that timer will expire. I appreciate
> that you came back quickly with some minor edits, and as it happens my
> concerns were very minor, and had the document passed through without
> further input that wouldn't have been a bad thing (except for me, anyway).

Good point. We've never enforced the 10-day timer before, so that may
have unforeseen implications.

>> > However, the changes in the current 1.4 look fine to me. But I'd
>> like to
>> > know that other folk are still okay.
>>
>> So "in future" (as you Brits say), shall we double check with Council
>> members for every concern that is addressed? And if so will we ever
>> finish any voting, given that a completely new vote will be required for
>> each minor revision? And what modifications require a revote?
>> Wordsmithing? Typo fixes? Changing a "may" to a "MAY"? Adding a missing
>> 'id' attribute? But perhaps we need a Procedural XEP defining all this.
>> If we can ever vote it to Active.
>>
>>
> Hmmm.
> 
> The purpose of the Council, as I see it - and you can correct me if you
> like - is to provide an objective and informed viewpoint of changes to
> documents.
> 
> Now the moment any concern is raised, and that member is involved with
> its resolution, the member's viewpoint isn't as objective anymore. So
> arguably, they've become the member least able to look at the new
> revision as a whole.
> 
> So yes, I'd hope the other Council members are checking the resolution,
> just to make sure it's not introduced anything unexpected.

I'd be happy to add all Council members to the xmpp-commits list. :)

>> > And yes, I do seem to be becoming very picky about procedure, don't I?
>>
>> I think you're a DoS sent from the IETF. :P
> 
> Oh, you've got clause 6 for that, no member can be an effective DoS.
> 
> 
> 
>> > While I'm being so picky, perhaps the right thing for the tally is
>> > actually:
>> >
>> > a) As Date, the date when the vote was officially commenced. I'd think
>> > this ought to be the first meeting for which the document is placed on
>> > the agenda, or when the new revision were submitted.
>> >
>> > b) Each new revision, post-rejection, should create a new line. So in
>> > this case, we'd have:
>> >
>> > XEP-0053        -1    .    +1    +1    +1    2008/10/15
>> > XEP-0053        +1    .    .    .    .    2008/10/22
>> >
>> > c) I suspect that we still need a 10 day timeout for those "re-votes",
>> > but rather than DNV they should default. This effectively means you've
>> > 10 days to review the changes.
>>
>> DoS.
>>
>>
> Okay, 5 days. But if you're saying there cannot be a timer restart, we
> have a different avenue for DoS, since that veto would have been ignored.

I think if someone has concerns then they need to vote -1. Then we work
to address that person's concerns, and we do so as long as needed. But I
agree that the resulting modifications need to be reviewed by the rest
of the Council. That may or may not require a restart -- it's a bit of a
judgment call, depending on how serious the changes are.

> Would it have mattered, with this case? Doubtful. But in principle, a
> minor change to you might well be a major change to me.

Right. So Council members need to pay attention. :)

> Is it a good example to use to figure out the right policy? Good enough.
> I'd hate to find an example where it mattered and have to figure things
> out then.

True.

>> > I have to admit, I'd like to see vetos recorded.
>>
>> More work. Is it worth it? People can look at the list archives, the
>> meeting logs, the SVN check-ins, etc., for interim discussion. We log
>> all that stuff for a reason.
>>
>>
> I think it's still important data to have listed at a glance, somewhere,
> if for no other reason than it provides a guage of performance next year.

But then it requires more precise versioning, separate publication of
interim versions for reference purposes, archiving of those interim
versions (right now we redirect interim versions to the main spec once
changes are approved), etc. There are process implications here that
seem not worth it to me, but perhaps that's because I'm the one doing
the work. If the XSF had lots of money and staff to handle these tasks,
I might not object so strenuously.

>> >>  XEP-0206,
>> >
>> > Reading through BOSH I noticed other stuff that needs a bit of work -
>> > nothing major, just oddities.
>> >
>> > body MUST be empty - good.
>> > server SHOULD ignore - fine.
>> > server MAY send - wrong - this is not truly optional behaviour.
>> >
>> > "[...] SHOULD ignore it. Some implementation are known to send that
>> > stanza when [...]" is prefereable, to avoid the implication that
>> sending
>> > the stanza is actually okay.
>> >
>> > Assuming you fix this, I'm +1, but as things stand that's a -1.
>>
>> Great! I love -1 votes. It means that someone is paying attention.
> 
> Ah, I only do it so I can prove I've read the stuff. ;-)
> 
> That was horribly unclear, though - I'm referring to the paragraph at
> line 220, and in particular the parentheses at the end.

So this:

***

Upon receiving the <success/> element, the client MUST then ask the
connection manager to restart the stream. It does this by setting to
"true" the 'xmpp:restart' attribute (qualified by the 'urn:xmpp:xbosh'
namespace) of the BOSH <body/> element. When sending the restart
request, the client SHOULD also include the 'to' and 'xml:lang'
attributes. In addition the <body/> MUST be empty (if the client
includes an XML stanza in the body, the connection manager SHOULD ignore
it but MAY send that stanza when the stream is restarted; however there
is no guarantee that a connection manager will send the stanza so a
client cannot rely on this behavior).

***

We had some discussion about that on the BOSH list. Some current
implementations will accept a body in the restart request, and send it
on when stream is restarted. However, we don't want anyone to depend on
that behavior, thus the wording. I'm open to suggestions for improvement.

Peter

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


From stpeter at stpeter.im  Mon Oct 27 17:24:49 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 27 Oct 2008 16:24:49 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <49063CDF.7080609@stpeter.im>
References: <4902437D.70001@stpeter.im>	<14395.1224887431.352323@peirce.dave.cridland.net>	<4902522C.1040006@stpeter.im>	<14395.1224894297.732414@peirce.dave.cridland.net>
	<49063CDF.7080609@stpeter.im>
Message-ID: <49063FB1.90008@stpeter.im>

<snip/>

So at the end of all this, I see the following:

XEP-0053

*I think* Dave is +1 now (please correct me if I'm wrong), but he's not
sure if the other Council members find the modification acceptable,
therefore I take it that he would suggest this topic go on the agenda
for the next meeting. Correct?

The SVN diff can be found here:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0053.xml

The rendered copy is here:

http://xmpp.org/extensions/tmp/xep-0053-1.4.html

XEP-0124

Ralph DNV, all others +1

XEP-0206

Dave -1 pending discussion of the following paragraph:

***

Upon receiving the <success/> element, the client MUST then ask the
connection manager to restart the stream. It does this by setting to
"true" the 'xmpp:restart' attribute (qualified by the 'urn:xmpp:xbosh'
namespace) of the BOSH <body/> element. When sending the restart
request, the client SHOULD also include the 'to' and 'xml:lang'
attributes. In addition the <body/> MUST be empty (if the client
includes an XML stanza in the body, the connection manager SHOULD ignore
it but MAY send that stanza when the stream is restarted; however there
is no guarantee that a connection manager will send the stanza so a
client cannot rely on this behavior).

***

XEP-0080

Ralph DNV, all others +1

XEP-0107

Ralph DNV, all others +1

XEP-0108

Ralph DNV, all others +1

If that accounting is correct, I will go ahead and publish the revised
versions of XEPs 124, 80, 107, and 108.

But before doing so I will wait 24 hours to see if there are any objections.

Peter

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


From dave at cridland.net  Tue Oct 28 03:19:02 2008
From: dave at cridland.net (Dave Cridland)
Date: Tue, 28 Oct 2008 08:19:02 +0000
Subject: [Council] final voting reminder!
In-Reply-To: <49063FB1.90008@stpeter.im>
References: <4902437D.70001@stpeter.im>
	<14395.1224887431.352323@peirce.dave.cridland.net>
	<4902522C.1040006@stpeter.im>
	<14395.1224894297.732414@peirce.dave.cridland.net>
	<49063CDF.7080609@stpeter.im> <49063FB1.90008@stpeter.im>
Message-ID: <14829.1225181942.613550@peirce.dave.cridland.net>

On Mon Oct 27 22:24:49 2008, Peter Saint-Andre wrote:
> <snip/>
> 
> So at the end of all this, I see the following:
> 
> XEP-0053
> 
> *I think* Dave is +1 now (please correct me if I'm wrong), but he's  
> not
> sure if the other Council members find the modification acceptable,
> therefore I take it that he would suggest this topic go on the  
> agenda
> for the next meeting. Correct?
> 
> 
Other, lighter weight, options also acceptable to me:

1) Council members state on list that their votes still stand with  
the modifications.
2) We assume that, after a week, their votes stand. (ie, you include  
this in your 24-hour warning below).

I think (2) probably works simplest for our purposes, and we should  
probably get around to casting that in stone, along with the ability  
for the XEP Editor for force a complete restart at their discretion.

> XEP-0206
> 
> Dave -1 pending discussion of the following paragraph:
> 
> ***
> 
> Upon receiving the <success/> element, the client MUST then ask the
> connection manager to restart the stream. It does this by setting to
> "true" the 'xmpp:restart' attribute (qualified by the  
> 'urn:xmpp:xbosh'
> namespace) of the BOSH <body/> element. When sending the restart
> request, the client SHOULD also include the 'to' and 'xml:lang'
> attributes. In addition the <body/> MUST be empty (if the client
> includes an XML stanza in the body, the connection manager SHOULD  
> ignore
> it but MAY send that stanza when the stream is restarted; however  
> there
> is no guarantee that a connection manager will send the stanza so a
> client cannot rely on this behavior).

Specifically, the last parenthetical phrase.

I'd suggest replacing it with:

. If the client includes an XML stanza in the body, the connection  
manager SHOULD ignore it. It is known that some implementations send  
such a stanza when the stream is restarted; however there is no  
guarantee that a connection manager will send the stanza so a client  
cannot rely on this behaviour.

(That's removing it from the parenthesis, and rephrasing the MAY to  
avoid the normative language).

> If that accounting is correct, I will go ahead and publish the  
> revised
> versions of XEPs 124, 80, 107, and 108.
> 
> But before doing so I will wait 24 hours to see if there are any  
> objections.

All looks right to me.

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

From dave at cridland.net  Tue Oct 28 03:19:49 2008
From: dave at cridland.net (Dave Cridland)
Date: Tue, 28 Oct 2008 08:19:49 +0000
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <49062F00.2070701@stpeter.im>
References: <48F651D4.8080603@stpeter.im>
	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>
	<14395.1224893091.318144@peirce.dave.cridland.net>
	<49061DF4.3070006@stpeter.im> <49062F00.2070701@stpeter.im>
Message-ID: <14829.1225181989.024178@peirce.dave.cridland.net>

On Mon Oct 27 21:13:36 2008, Peter Saint-Andre wrote:
> Joe and I discussed it offlist. We think that if the naive  
> subscriber
> doesn't include subscription options, the queueing node needs to  
> return
> a <not-acceptable/> error with a pubsub-specific condition of
> <configuration-required/>. In fact this is already specified:
> 
> http://xmpp.org/extensions/inbox/pubsub-queueing.html#example-1
> 
> So a naive client will never get subscribed to a queueing node in  
> the
> first place.

Ah, okay. In that case, that would seem to be the major area of  
interop failure gone, so I'm okay with this in principle.

I'll admit I'm not convinced, yet, that this is the right approach  
for queueing, but it does at least appear not to cause damage, so I  
have no objections.

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 kevin at kismith.co.uk  Tue Oct 28 04:05:53 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 28 Oct 2008 09:05:53 +0000
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <14829.1225181989.024178@peirce.dave.cridland.net>
References: <48F651D4.8080603@stpeter.im>
	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>
	<14395.1224893091.318144@peirce.dave.cridland.net>
	<49061DF4.3070006@stpeter.im> <49062F00.2070701@stpeter.im>
	<14829.1225181989.024178@peirce.dave.cridland.net>
Message-ID: <f5aae3ec0810280205q2a0245aehd94cf3df8f236450@mail.gmail.com>

On Tue, Oct 28, 2008 at 8:19 AM, Dave Cridland <dave at cridland.net> wrote:
> Ah, okay. In that case, that would seem to be the major area of interop
> failure gone, so I'm okay with this in principle.

If that's sorted out, I'm +1 again (not that this is a needed vote,
yadda yadda).

/K

From kevin at kismith.co.uk  Tue Oct 28 08:27:02 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 28 Oct 2008 13:27:02 +0000
Subject: [Council] final voting reminder!
In-Reply-To: <49063FB1.90008@stpeter.im>
References: <4902437D.70001@stpeter.im>
	<14395.1224887431.352323@peirce.dave.cridland.net>
	<4902522C.1040006@stpeter.im>
	<14395.1224894297.732414@peirce.dave.cridland.net>
	<49063CDF.7080609@stpeter.im> <49063FB1.90008@stpeter.im>
Message-ID: <f5aae3ec0810280627p7f890d72x7207a37e0ada8baf@mail.gmail.com>

On Mon, Oct 27, 2008 at 10:24 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> So at the end of all this, I see the following:
> XEP-0053
> *I think* Dave is +1 now (please correct me if I'm wrong), but he's not
> sure if the other Council members find the modification acceptable,
> therefore I take it that he would suggest this topic go on the agenda
> for the next meeting. Correct?

I am ok with the most recent modification.

> If that accounting is correct, I will go ahead and publish the revised
> versions of XEPs 124, 80, 107, and 108.

Seems to be, thanks.

/K

From stpeter at stpeter.im  Tue Oct 28 10:24:44 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Oct 2008 09:24:44 -0600
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <f5aae3ec0810280205q2a0245aehd94cf3df8f236450@mail.gmail.com>
References: <48F651D4.8080603@stpeter.im>	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>	<14395.1224893091.318144@peirce.dave.cridland.net>	<49061DF4.3070006@stpeter.im>
	<49062F00.2070701@stpeter.im>	<14829.1225181989.024178@peirce.dave.cridland.net>
	<f5aae3ec0810280205q2a0245aehd94cf3df8f236450@mail.gmail.com>
Message-ID: <49072EBC.60109@stpeter.im>

Kevin Smith wrote:
> On Tue, Oct 28, 2008 at 8:19 AM, Dave Cridland <dave at cridland.net> wrote:
>> Ah, okay. In that case, that would seem to be the major area of interop
>> failure gone, so I'm okay with this in principle.
> 
> If that's sorted out, I'm +1 again (not that this is a needed vote,
> yadda yadda).

OK, thanks. Perhaps Ralph will resurface soon with thoughts on
chaining/aggregation.

Peter

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


From stpeter at stpeter.im  Tue Oct 28 10:25:31 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Oct 2008 09:25:31 -0600
Subject: [Council] meeting minutes, 2008-10-15
In-Reply-To: <14829.1225181989.024178@peirce.dave.cridland.net>
References: <48F651D4.8080603@stpeter.im>	<f5aae3ec0810230900k3bc02826mbde1359f03f0c057@mail.gmail.com>	<14395.1224893091.318144@peirce.dave.cridland.net>	<49061DF4.3070006@stpeter.im>
	<49062F00.2070701@stpeter.im>
	<14829.1225181989.024178@peirce.dave.cridland.net>
Message-ID: <49072EEB.3000706@stpeter.im>

Dave Cridland wrote:
> On Mon Oct 27 21:13:36 2008, Peter Saint-Andre wrote:
>> Joe and I discussed it offlist. We think that if the naive subscriber
>> doesn't include subscription options, the queueing node needs to return
>> a <not-acceptable/> error with a pubsub-specific condition of
>> <configuration-required/>. In fact this is already specified:
>>
>> http://xmpp.org/extensions/inbox/pubsub-queueing.html#example-1
>>
>> So a naive client will never get subscribed to a queueing node in the
>> first place.
> 
> Ah, okay. In that case, that would seem to be the major area of interop
> failure gone, so I'm okay with this in principle.
> 
> I'll admit I'm not convinced, yet, that this is the right approach for
> queueing, but it does at least appear not to cause damage, so I have no
> objections.

Did I say I was convinced? :) I think it is an approach worth exploring.
Alternative approaches are welcome...

Peter

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


From jabberfoundation at ralphm.ik.nu  Tue Oct 28 10:44:02 2008
From: jabberfoundation at ralphm.ik.nu (Ralph Meijer)
Date: Tue, 28 Oct 2008 16:44:02 +0100
Subject: [Council] final voting reminder!
In-Reply-To: <4902437D.70001@stpeter.im>
References: <4902437D.70001@stpeter.im>
Message-ID: <49073342.8040301@ralphm.ik.nu>

On 2008-10-24 23:51, Peter Saint-Andre wrote:
> Our illustrious Council Chair is serious about the 10-day limit on
> voting, therefore as XMPP Extensions Editor I will send out a voting
> reminder 24 hours before the end of each voting period. This is the
> first such reminder.
> 
> By my accounting, the following votes are due from the 2008-10-15 meeting:
>
> [..]
> 
> Ralph Meijer: XEP-0053, XEP-0124, XEP-0206, XEP-0080, XEP-0107, XEP-0108

FWIW, I am +1 on them, except for XEP-0206, given the discussion Dave
raised.

Sorry for not calling in earlier, I've been ill and was hauled to Berlin
at the last moment last week. I'll be present tomorrow.

ralphm


From stpeter at stpeter.im  Tue Oct 28 10:52:41 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Oct 2008 09:52:41 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <14829.1225181942.613550@peirce.dave.cridland.net>
References: <4902437D.70001@stpeter.im>	<14395.1224887431.352323@peirce.dave.cridland.net>	<4902522C.1040006@stpeter.im>	<14395.1224894297.732414@peirce.dave.cridland.net>	<49063CDF.7080609@stpeter.im>
	<49063FB1.90008@stpeter.im>
	<14829.1225181942.613550@peirce.dave.cridland.net>
Message-ID: <49073549.70105@stpeter.im>

Dave Cridland wrote:
> On Mon Oct 27 22:24:49 2008, Peter Saint-Andre wrote:
>> <snip/>
>>
>> So at the end of all this, I see the following:
>>
>> XEP-0053
>>
>> *I think* Dave is +1 now (please correct me if I'm wrong), but he's not
>> sure if the other Council members find the modification acceptable,
>> therefore I take it that he would suggest this topic go on the agenda
>> for the next meeting. Correct?
>>
>>
> Other, lighter weight, options also acceptable to me:
> 
> 1) Council members state on list that their votes still stand with the
> modifications.
> 2) We assume that, after a week, their votes stand. (ie, you include
> this in your 24-hour warning below).
> 
> I think (2) probably works simplest for our purposes, and we should
> probably get around to casting that in stone, along with the ability for
> the XEP Editor for force a complete restart at their discretion.

Something like (2) works for me. In fact, I'll test it out right now...

>> XEP-0206
>>
>> Dave -1 pending discussion of the following paragraph:
>>
>> ***
>>
>> Upon receiving the <success/> element, the client MUST then ask the
>> connection manager to restart the stream. It does this by setting to
>> "true" the 'xmpp:restart' attribute (qualified by the 'urn:xmpp:xbosh'
>> namespace) of the BOSH <body/> element. When sending the restart
>> request, the client SHOULD also include the 'to' and 'xml:lang'
>> attributes. In addition the <body/> MUST be empty (if the client
>> includes an XML stanza in the body, the connection manager SHOULD ignore
>> it but MAY send that stanza when the stream is restarted; however there
>> is no guarantee that a connection manager will send the stanza so a
>> client cannot rely on this behavior).
> 
> Specifically, the last parenthetical phrase.
> 
> I'd suggest replacing it with:
> 
> . If the client includes an XML stanza in the body, the connection
> manager SHOULD ignore it. It is known that some implementations send
> such a stanza when the stream is restarted; however there is no
> guarantee that a connection manager will send the stanza so a client
> cannot rely on this behaviour.
> 
> (That's removing it from the parenthesis, and rephrasing the MAY to
> avoid the normative language).

Right. That works for me, and is more in line with that long thread on
ietf at ietf.org about such topics, which I blogged about here (and perhaps
promptly forgot?):

https://stpeter.im/?p=2225

I have adjusted the text to incorporate Dave's concern, with language
close to what he has proposed. In addition, I have cleaned up the
paragraph about restart requests a bit to more clearly explain exactly
what a restart request is. I think the text is now more readable.

The rendered document is here:

http://xmpp.org/extensions/tmp/xep-0206-1.2.html

See especially the text following Example 9:

http://xmpp.org/extensions/tmp/xep-0206-1.2.html#example-9

The SVN diff from version 1.2rc2 is here:

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

(Or http://is.gd/513x if you prefer short URLs.)

If you have objections to the text as it now stands or if it will change
your previous vote on version 1.2rc2 of XEP-0206, please voice those
objections on this list or in the next Council meeting. (I am of the
opinion that this change is small enough that you should not need 7 days
to review it, but we can discuss appropriate time periods for such
review in the next meeting.)

Peter

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


From stpeter at stpeter.im  Tue Oct 28 11:21:30 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Oct 2008 10:21:30 -0600
Subject: [Council] final voting reminder!
In-Reply-To: <49073342.8040301@ralphm.ik.nu>
References: <4902437D.70001@stpeter.im> <49073342.8040301@ralphm.ik.nu>
Message-ID: <49073C0A.7050501@stpeter.im>

Ralph Meijer wrote:
> On 2008-10-24 23:51, Peter Saint-Andre wrote:
>> Our illustrious Council Chair is serious about the 10-day limit on
>> voting, therefore as XMPP Extensions Editor I will send out a voting
>> reminder 24 hours before the end of each voting period. This is the
>> first such reminder.
>>
>> By my accounting, the following votes are due from the 2008-10-15
>> meeting:
>>
>> [..]
>>
>> Ralph Meijer: XEP-0053, XEP-0124, XEP-0206, XEP-0080, XEP-0107, XEP-0108
> 
> FWIW, I am +1 on them, except for XEP-0206, given the discussion Dave
> raised.
> 
> Sorry for not calling in earlier, I've been ill and was hauled to Berlin
> at the last moment last week. I'll be present tomorrow.

Thanks, Ralph! It seems that you were more ill than I realized. I hope
you're feeling better now!

Peter

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


From stpeter at stpeter.im  Tue Oct 28 12:45:17 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Oct 2008 11:45:17 -0600
Subject: [Council] obsolete XEPs
Message-ID: <49074FAD.1090606@stpeter.im>

I just noticed that I have not yet updated XEP-0078 to reflect the
Council consensus to obsolete this spec (a decision made in the meeting
on 2008-10-08).

The Council did not have consensus to obsolete XEP-0090 and XEP-0091. If
there are no objections, I will extend the expiration dates on those
specs to 2008-12-31 so that we have until the end of the year to figure
out what we'll do with them.

Peter



From jack at chesspark.com  Tue Oct 28 14:15:31 2008
From: jack at chesspark.com (Jack Moffitt)
Date: Tue, 28 Oct 2008 13:15:31 -0600
Subject: [Council] obsolete XEPs
In-Reply-To: <49074FAD.1090606@stpeter.im>
References: <49074FAD.1090606@stpeter.im>
Message-ID: <9b58f4550810281215v650af5a6tb538023b04888d17@mail.gmail.com>

> The Council did not have consensus to obsolete XEP-0090 and XEP-0091. If
> there are no objections, I will extend the expiration dates on those
> specs to 2008-12-31 so that we have until the end of the year to figure
> out what we'll do with them.

Seems reasonable to me.

jack.

From stpeter at stpeter.im  Tue Oct 28 14:23:59 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 28 Oct 2008 13:23:59 -0600
Subject: [Council] obsolete XEPs
In-Reply-To: <9b58f4550810281215v650af5a6tb538023b04888d17@mail.gmail.com>
References: <49074FAD.1090606@stpeter.im>
	<9b58f4550810281215v650af5a6tb538023b04888d17@mail.gmail.com>
Message-ID: <490766CF.40708@stpeter.im>

Jack Moffitt wrote:
>> The Council did not have consensus to obsolete XEP-0090 and XEP-0091. If
>> there are no objections, I will extend the expiration dates on those
>> specs to 2008-12-31 so that we have until the end of the year to figure
>> out what we'll do with them.
> 
> Seems reasonable to me.

While looking for references to XEP-0078 (jabber:iq:auth) in other XEPs,
I was reminded that the 2008 compliance suites (specifically XEP-0212)
recommend support for it. Perhaps it's strange that a current compliance
suite would recommend support for a deprecated technology, but it's
probably even stranger to recommend support for an obsolete technology.

I don't think this warrants a delay in obsoleting XEP-0078 (e.g., we
*could* wait until January 1, 2009), but I wanted to bring it to the
Council's attention.

Peter


From kevin at kismith.co.uk  Tue Oct 28 17:47:02 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Tue, 28 Oct 2008 22:47:02 +0000
Subject: [Council] Council meeting 20091029
Message-ID: <f5aae3ec0810281547i2303be77k425ed172a88adb5d@mail.gmail.com>

Hi all,
  Another agenda - no votable items this week, but enough to be discussing:

http://xmpp.org/council/agendas/2008-10-29.html

/K

From stpeter at stpeter.im  Wed Oct 29 10:06:48 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 29 Oct 2008 09:06:48 -0600
Subject: [Council] Council meeting 20091029
In-Reply-To: <f5aae3ec0810281547i2303be77k425ed172a88adb5d@mail.gmail.com>
References: <f5aae3ec0810281547i2303be77k425ed172a88adb5d@mail.gmail.com>
Message-ID: <49087C08.3060604@stpeter.im>

Already scheduling meetings for 2009, are we? ;-)


From kevin at kismith.co.uk  Wed Oct 29 10:07:51 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Wed, 29 Oct 2008 15:07:51 +0000
Subject: [Council] Council meeting 20091029
In-Reply-To: <49087C08.3060604@stpeter.im>
References: <f5aae3ec0810281547i2303be77k425ed172a88adb5d@mail.gmail.com>
	<49087C08.3060604@stpeter.im>
Message-ID: <f5aae3ec0810290807t6bc93b6anf66e36e0e56f6af5@mail.gmail.com>

On Wed, Oct 29, 2008 at 3:06 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Already scheduling meetings for 2009, are we? ;-)

Uhm.
Yes.

Well spotted, that man.

/K

From stpeter at stpeter.im  Wed Oct 29 10:24:58 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 29 Oct 2008 09:24:58 -0600
Subject: [Council] Council meeting 20091029
In-Reply-To: <f5aae3ec0810281547i2303be77k425ed172a88adb5d@mail.gmail.com>
References: <f5aae3ec0810281547i2303be77k425ed172a88adb5d@mail.gmail.com>
Message-ID: <4908804A.8050806@stpeter.im>

Kevin Smith wrote:
> Hi all,
>   Another agenda - no votable items this week, but enough to be discussing:
> 
> http://xmpp.org/council/agendas/2008-10-29.html

At some point we need to vote on approving the recent modifications to
XEP-0174 (Serverless Messaging). See here:

http://xmpp.org/extensions/tmp/xep-0174-1.3.html

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

(Or http://is.gd/4Fmg if you like shorter URLs.)

But I think we can do that next week, because I haven't gotten any
feedback about this yet on the standards@ list.

Peter

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


From stpeter at stpeter.im  Wed Oct 29 16:22:35 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 29 Oct 2008 15:22:35 -0600
Subject: [Council] meeting minutes, 2008-10-29
Message-ID: <4908D41B.7020107@stpeter.im>

Results of the XMPP Council meeting held 2008-10-29...

Agenda:

http://xmpp.org/council/agendas/2008-10-22.html

Log:

http://logs.jabber.org/council at conference.jabber.org/2008-10-29.html

Scribe: Peter Saint-Andre

0. Roll call

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

Quorum achieved.

1. Agenda bashing

None.

2. Moving Jingle from Experimental to Draft

Lengthy discussion with input from Robert McQueen. Consensus that it
would be desirable to perform some online interop testing before
advancing the specs. Peter to poll developers about whether they are
ready for that, and if not when they would be ready.

3. Draft to Final process

General consensus that formal interoperability testing is not needed.
Peter to post to the council@ list with further thoughts about the process.

4. Other business

4a. Double-check that all Council members approve of the interim
XEP-0206 modifications. All in favor.

4b. Double-check that all Council members approve of the interim
XEP-0053 modifications. All in favor.

4c. Double-check that all Council members approve of Obsoleting XEP-0078
immediately rather than waiting until 2009-01-01. All in favor.

5. Next meeting

Wednesday, 2008-11-05 @ 21:00 UTC.

Peter

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


From stpeter at stpeter.im  Thu Oct 30 17:24:24 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Oct 2008 16:24:24 -0600
Subject: [Council] XEP-0084 (User Avatar)
Message-ID: <490A3418.1000301@stpeter.im>

We currently have two Draft specs under revision: XEP-0084 and XEP-0174.
It seems that we didn't get XEP-0084 (User Avatar) on the agenda with
the other "rich presence" / PEP payload specs, so we'll need to vote on
that sometime soon.

Here are the particulars regarding version 1.1rc1 of XEP-0084:

http://xmpp.org/extensions/tmp/xep-0084-1.1.html

Changelog: For consistency with other PEP payload formats, changed stop
semantics to use an empty <metadata/> element rather than a <stop/>
child element.

SVN diff from 1.0:

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

(Or http://is.gd/5gXw if you like short URLs.)

Before proceeding, we may need to check with developers about who has
implemented the <stop/> semantics.

I'll post separately about XEP-0174.

Peter

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


From stpeter at stpeter.im  Thu Oct 30 17:28:58 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Oct 2008 16:28:58 -0600
Subject: [Council] XEP-0174 (Serverless Messaging)
Message-ID: <490A352A.2030002@stpeter.im>

As noted, XEP-0174 (Serverless Messaging) is currently under revision.
The particulars regarding version 1.3rc2 are as follows:

http://xmpp.org/extensions/tmp/xep-0174-1.3.html

Changelog: Corrected TXT record format in conformance with
draft-cheshire-dnsext-dns-sd; clarified a number of issues related to
DNS-SD and Multicast DNS; as an optimization, recommended sending of
disco#info data in stream features; removed reference to Encrypted
Sessions specification from the security considerations.

SVN diff from 1.2:

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

(Or http://is.gd/5gZ4 if you like short URLs.)

The TXT record correction is fairly important, as discussed on the
standards@ list, so I'd like to see this put into production sooner
rather than later.

Kev, I suppose you can consider these two messages as requests for time
on the agenda at the next meeting. :)

Peter

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


From dmeyer at tzi.de  Thu Oct 30 04:28:54 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 30 Oct 2008 09:28:54 -0000
Subject: [Council] Council meeting 20091029
In-Reply-To: <4908804A.8050806@stpeter.im> (Peter Saint-Andre's message of
	"Wed\, 29 Oct 2008 09\:24\:58 -0600")
References: <f5aae3ec0810281547i2303be77k425ed172a88adb5d@mail.gmail.com>
	<4908804A.8050806@stpeter.im>
Message-ID: <87y706fnkb.fsf@phex.sachmittel.de>

Peter Saint-Andre wrote:
> At some point we need to vote on approving the recent modifications to
> XEP-0174 (Serverless Messaging). See here:
>
> http://xmpp.org/extensions/tmp/xep-0174-1.3.html
>
> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0174.xml?%40diffMode=u&%40diffWrap=s&r1=2186&r2=2431&u=3&ignore=&k=
>
> (Or http://is.gd/4Fmg if you like shorter URLs.)
>
> But I think we can do that next week, because I haven't gotten any
> feedback about this yet on the standards@ list.

I like the disco#query support. On the other hand it creates a lot of
noise if I already know the capabilities. If we can live with one
roundtrip more maybe make it a feature:

| <stream:features>
|   <starttls/>
|   <query xmlns='http://jabber.org/protocol/disco#info'/>
| </stream:features>


Dirk

-- 
Computer analyst to programmer: "You start coding. I'll go
find out what they want."