> No, with stream:features you have two additional
> roundtrips. At the beginning you send and
> wait for an answer and an extra stanza with the
> . After you restart the stream
> and also have a roundtrip.
Right. There was a discussion not long time ago on how this could be
improved. See
http
Justin Karneges wrote:
> The default namespace is nice, since we needed to qualify the
> stanzas anyway. The 'to' and 'from' are a tad superfluous, but maybe we
> should consider them for consistency with XEP-174 (Link Local) ? Same for
> putting to/from on the message stanzas.
[...]
>xml
JabberForum wrote:
> ProtoXEP:
>
> 1. Discover Support
> 2. Send XTLS negotiation request, i.e.
> 3. Receive XTLS negotation response
> 4. Open IBB
> 5. Send stanza
>
> With stream:features step:
>
> 1. Discover Support
> 2. Open IBB
> 3. Send TLS negotiation request, i.e.
> 3. Receive TLS negoti
> We would leave out the version='1.0' flag though,
> since there is no stream:features step.
I didn't follow the conversation that led to the ProtoXEP in its
current form, but what's wrong with doing TLS negotiation in a
stream:features step?
ProtoXEP:
1. Discover Support
2. Send XTLS negotiat
On Sunday 08 June 2008 11:57 am, Dirk Meyer wrote:
> Justin Karneges wrote:
> > Treated as a stream, we cannot enforce that a particular TLS packet
> > contains an entire XML document. A single TLS packet might contain
> > many messages, and one message might be split across many TLS
> > packets.
Justin Karneges wrote:
> I think the original intent with XTLS was to use a new parser instance for
> the
> content of each TLS packet, but this violates the TLS abstraction.
My original intent was to open a new stream incl. feature handling. I
implemented that and therefor never had the missi
On Sunday 08 June 2008 4:23 am, JabberForum wrote:
> > The basic idea behind XTLS is that two XMPP entities negotiate
> > an encrypted "tunnel" between themselves over XMPP. The tunnel
> > is negotiated using standard TLS handshake data, encapsulated
> > in In-Band Bytestreams. The entities can the
> The basic idea behind XTLS is that two XMPP entities negotiate
> an encrypted "tunnel" between themselves over XMPP. The tunnel
> is negotiated using standard TLS handshake data, encapsulated
> in In-Band Bytestreams. The entities can then exchange
> TLS-encrypted XMPP stanzas over that tunnel.
Dnia 2008-06-05, czw o godzinie 15:39 -0600, Peter Saint-Andre pisze:
> Should we allow subscriptions to a full JID instead of a bare JID?
We should disallow full JID based subscriptions. This introduces many
inconsistencies and doubts in presence handling.
> I know people have said there are le
