Re: [xmpp] the stream negotiation process

[Peter Saint-Andre <stpeter at stpeter.im>]

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

On 10/22/09 10:56 PM, Justin Karneges wrote:
> On Thursday 22 October 2009 20:32:12 you wrote:
>> On 10/22/09 7:07 PM, Justin Karneges wrote:
>>
>>> Sure, a generic way to flag any feature as required would allow a client
>>> to easily display the generic "feature not supported" error message. 
>>> Otherwise, as mentioned, the client would have to send a stanza and
>>> receive an error in order to determine that there was an unnegotiated
>>> required feature.  I'm partial to using an error as a solution, since it
>>> requires the least amount of change to XMPP.  I'd suggest a stream error
>>> here and not (or not merely) a stanza error.
>> Of course it must be a stream error -- the initiating entity hasn't
>> necessarily sent any stanzas (e.g., if it hasn't completed SASL
>> negotiation yet).
> 
> How else would the receiving entity know to send an error?  If I negotiate TLS 
> and then just sit there and not negotiate SASL, the server shouldn't boot me 
> (well except due to a timeout, but that's not the same thing as skipping over 
> a required feature).  The server pretty much has to wait for me to make a 
> wrong move.  Maybe you mean if I try to negotiate a stream feature out of 
> sequence?  That would be one non-stanza way of me doing something wrong.

A stanza is <iq/>, <message/>, or <presence/>. If the server is
expecting SASL and I try to negotiate XEP-0198 support or dialback or
whatever, I haven't sent a stanza so how can the server return a stanza
error to me?

>>> Finally, I want to say that very few features should be required at all
>>> anyway.  TLS, SASL, and resource binding are the only ones that matter.
>> TLS or something very much like it. SASL or something very much like it.
>> Resource binding or something very much like it. But, in case we should
>> ever design or re-use things very much like TLS, SASL, and resource
>> binding then most likely those features would be defined as required, too.
> 
> If an alternative feature to SASL existed (let's call it NGAuth), I think the 
> best approach would be for the new feature to define not only itself but its 
> relationship to SASL.  For example, if both are offered, then the NGAuth is 
> preferred, else SASL is used.
> 
> I don't think <required/> flags would be enough to drive this.  You'd need a 
> way to specify that one deprecates the other or should be tried before the 
> other, and that only one of them should be used.
> 
> In the case of ensuring only one of these features is used, and not both, of 
> course the server could be smart about how the features are offered.  For 
> example, on the first pass it could offer both NGAuth and SASL, but if NGAuth 
> is used and succeeds then the next set of stream features would not contain 
> either of them.  That said, the client shouldn't be so dumb that it relies on 
> the server for this logic.  A client shouldn't auth twice, and it should know 
> that it only needs one of NGAuth or SASL because it would say so in the spec.

That seems reasonable.

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/

iEYEARECAAYFAkrhtOoACgkQNL8k5A2w/vzlJACff/ZAjRy2faDzj1TEyfvDkAMY
e6YAnj2zvUQPpBWboMQKDLQQg3XGhQDU
=n9QH
-----END PGP SIGNATURE-----