[Council] meeting minutes, 2007-01-03

[Peter Saint-Andre]

Hi Ralph, thanks for the votes and comments.

Ralph Meijer wrote:
> On Wed, Jan 03, 2007 at 12:15:39PM -0700, Peter Saint-Andre wrote:
>> Results of the XMPP Council meeting held 2007-01-03...
>>
>> [..]
>>
>> 1. XEP-0155: Chat Session Negotiation
>>
>> Advance version 0.14 to Draft?
>>
>> Ian, Kevin, and Peter voted +1. Chris and Ralph to vote on list.
> 
> I don't understand section 9.1. A user may be blocked from presence but
> not messages. I find 'invisible' misleading. Also, I can imagine a
> server and/or client feature that allows a user to only allow certain
> JIDs for chat, and deny all others, whether they are one the roster or
> not.

Yes I think the wording here needs to be more precise. I'll work up some 
text.

> Rest +1.
> 
>> 2. XEP-0157: Contact Addresses for XMPP Services
>>
>> Ralph to vote on list.
> 
> Does this apply to all messages? I imagine servers (= components, too)
> being subscribed to publish-subscribe nodes getting notifications to the
> domain as <message/>s, for example.

Hmm. As it's written now, yes that would apply to all messages. I don't 
think we want the server admins to receive massive numbers of pubsub 
sync-ups and such.

Maybe it makes more sense to define a <DomainID/ResourceID> JID for 
this, such as <domain.tld/admin> (so that we're not overloading the mere 
domain's JID).

>> 3. XEP-0170: Recommended Order of Stream Feature Negotiation
>>
>> Ralph to vote on list.
> 
> +1. Does this need any updates with regard to XEP-0192?

No, I think the two are orthogonal.

With your vote this spec now advances to Active.

>> 5. XEP-0190: Best Practice for Closing Idle Streams
>>
>> Ralph to vote on list.
> 
> Although I find some of the wording a bit odd, I +1 the concept and its
> embedding in RFC3920bis.

OK, this advances as well.

>> 6. XEP-0192: Proposed Stream Feature Improvements
>>
>> Ralph to vote on list.
> 
> In 3, first sentence it says suupport.
> 
> I think the goal is that an initiating entity must be able to decide
> when to start sending stanzas. As I see it, this is when none of the
> advertised features in a stream are required.
> 
> While this XEP doesn't show what to do in case of multiple features that
> are a valid choice at a certain stage, the examples in RFC3920bis do.
> However, I don't think they are correct. Take the example in 9.1,
> client-to-server.
> 
> There, in step 3, it appears that to be able to start sending stanzas,
> we need to do TLS first. That can't be right, though. Choosing SASL is
> ok, too. What's more, TLS is not required to do SASL in this example,
> otherwise it wouldn't offer SASL in the first place.
> 
> So if this example means to convey that you can choose either, both need
> to carry <required/> IMO.

OK, I'll look at that today.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

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