[Council] meeting minutes, 2007-01-03

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> 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.

How does this sound?

***

If a contact does not share its presence information with a user through 
a presence subscription (see RFC 3921) or if it blocks outbound presence 
notifications to the user (see XEP-0016), then it will effectively 
expose its presence if it accepts the user's chat session negotiation 
request or returns an error to the user. Therefore, due care must be 
exercised in determining whether to accept the request or return an 
error. The contact's client SHOULD NOT automatically (i.e. without first 
asking the contact) either accept the user's request or return an error 
to the user unless the user is subscribed to the contact's presence and 
the contact is not blocking outbound presence notifications to the user. 
Note: There should be no need for the contact's client to consult the 
contact's block list (see XEP-0191), since if the user is on the block 
list then the contact would not receive the request from the user in the 
first place.

***

>> 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).

The more I reflect on it, the more I think that's the right way to go.

>>> 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.

Agreed.

>> 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.

I think we need to provide some guidance on that in XEP-0192.

>> 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.

Well, I think the examples in 9.1 are that way to show the difference 
between the SASL mechanisms on offer before TLS is negotiated and the 
SASL mechanisms on offer after TLS is negotiated. Since TLS is required, 
the server would need to reject an attempt at SASL negotiation at that 
stage. But I need to review the SASL and TLS specs again to see whether 
that example makes sense.

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/20070105/ef4b4d68/smime.bin