On Fri Feb 8 09:37:18 2013, Kevin Smith wrote:
(M.M. has since +1d the LC)
/K
On Fri, Feb 8, 2013 at 9:33 AM, Kevin Smith <[email protected]>
wrote:
> FYI
>
>
> ---------- Forwarded message ----------
> From: Kevin Smith
> Date: Fri, Feb 8, 2013 at 9:31 AM
> Subject: Minutes meeting 20130206
> To: XMPP Council
>
>
> Room logs: http://logs.xmpp.org/council/130206/
>
> 1) Roll call
> Ralph, Tobias, Kev present. Matt W sends apologies, Matt M absent.
>
> 2) Bidi, http://xmpp.org/extensions/xep-0288.html
> Issue Last Call?
>
> +1 from those present, pending from the Matts.
So the reason that bidi works without a response to the request is
that it's not a request, it's an advertisement. In effect, it's a
feature in reverse, and we would have done that if it wouldn't have
involved a lengthy chunk of spec-writing to do reverse features
safely.
It'd be a valid suggestion that we should instead bite the bullet and
do a proper <stream:features/> from the sender, but it'll mean
defining that in another spec and then using it in <bidi/>.
There's no need to have any negotiation, as such, because the
converation is, roughly:
Initiator connects; sends stream open: "Hello, I'm example.com".
Receiver accepts; responds with stream open and features: "Hi, I'm
jabber.org, and I support sending stanzas on this session".
Initiator offers Bidi: "Oh, I do bidi too, so send stanzas to me if
you like."
At this stage, the receiver can either use the Bidi, or not. Neither
Philip nor I could think of any time that a response provided further
information at this point.
Another way of looking at this, if you really insist on having a
request/response negotiation, is that the stream feature is the
request, and the <bidi/> element the response.
Hope this answers Ralph's query.
I'd note for the record that XEP-0288 has been implemented (at least)
three times without this being an operational or implementation issue
as far as I'm aware, and I really don't want another <session/>.
Dave.
