[Council] agenda items

Peter Saint-Andre stpeter at stpeter.im
Tue May 19 13:14:14 CDT 2009


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

On 5/19/09 11:04 AM, Dave Cridland wrote:
> On Mon May 18 19:50:38 2009, Peter Saint-Andre wrote:
>> It seems that we have a Council meeting schedule for May 20. Here are
>> some possible agenda items, feel free to add your own. :)
>>
>>
> I am highly unlikely to make this one, I'm afraid.

No worries. Thanks for sending your regrets on the list.

>> 1. Jingle
>>
>> Vote on advancing XEP-0166, XEP-0167, XEP-0176, XEP-0177 to Draft. We
>> might still have some remaining issues to discuss on the jingle@ list.
>> It never ends...
> 
> Sounds like you're voting against. I need to catch up on this one before
> I can take a view.

There is one niggling issue for ICE-UDP regarding restarts. Further
documentation is required, but I think we can have consensus on that in
the next few days.

>> 2. Roster Versioning
>>
>> Vote on advancing XEP-0237 to Draft.
> 
> I'm satisfied this can be advanced to Draft, you may consider this a
> vote in advance.

+1 here as well.

>> 3. Shared BOSH
>>
>> Accept http://xmpp.org/extensions/inbox/shared-bosh.html as a XEP?
>>
>>
> I'm a bit confused as to why you'd not want to just use two distinct
> connections, and send stanzas between them as required. This method
> means that you're doubling the bandwidth consumption at minimum, which
> seems like the least optimal solution.

I'll let Jack comment on that.

>> 4. SIFT
>>
>> Accept http://xmpp.org/extensions/inbox/sift.html as a XEP?
>>
>>
> What's concerning me here is that there's yet another proposal for
> something to do invisibility and privacy lists. None of these have seen
> much traction in the community, yet we seem to produce a lot of them.

This has nothing to do with privacy lists, although it might provide a
way to handle invisibility.

> Before we go through with this proposal, I'd like to see someone clearly
> write down some requirements, and get general agreement on those first.

Adding some requirements makes sense, I'll do that in the next version
of the document.

>> 5. Entity Time
>>
>> XEP-0090 is set to expire on 2009-06-30. The Council needs to decide
>> whether to maintain this specification in the Deprecated state or change
>> its status to Obsolete.
>>
>> 6. Delayed Delivery
>>
>> XEP-0091 is set to expire on 2009-06-30. The Council needs to decide
>> whether to maintain this specification in the Deprecated state or change
>> its status to Obsolete.
>>
>> 7. Message Events
>>
>> XEP-0022 is currently Deprecated but does not have an expiration date.
>> The Council might want to assign an expiration date or change its status
>> to Obsolete.
>>
>>
> I think all of these might be considered for a "Last Call" to obsolete
> at this point. (I know we don't have to do a Last Call, but I think it'd
> be useful to forewarn the community and see if anyone screams.)

Sure. We'll call it something other than a Last Call, but I agree that
asking for feedback would be a good idea.

>> 8. Direct MUC Invitations
>>
>> Issue a Last Call in preparation for advancing XEP-0249 to Draft.
>>
>> 9. Stream Management
>>
>> Issue a Last Call in preparation for advancing XEP-0199 to Draft.
> 
> Last-Call-tastic from here.

Super. (That last one is XEP-0198, not XEP-0199.)

Peter

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoS9vYACgkQNL8k5A2w/vybhwCgz60L8VLWnRR4zNNsxY7g3r9S
hjQAoKlgKGdA+pJkBLNPXcQGam5AMw+6
=+Y5S
-----END PGP SIGNATURE-----


More information about the Council mailing list