Re: [xmpp] the stream negotiation process

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

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

On 10/22/09 7:07 PM, Justin Karneges wrote:
> On Thursday 22 October 2009 13:08:08 Peter Saint-Andre wrote:
>> On 10/21/09 8:45 AM, Peter Saint-Andre wrote:
>>> 1. Negotiation of all stream features is optional. If the receiving
>>> entity considers negotiation of a given feature to be mandatory, it will
>>> advertise only that feature; and if the initiating entity does not
>>> negotiate that feature (e.g., by attempting to send stanzas before it is
>>> allowed to do so), then the receiving entity will return an error to the
>>> initiating entity. Therefore, we have no need to specify over the wire
>>> if a given stream feature must be negotiated at any given stage of the
>>> stream negotiation process.
>> For TLS, we felt the need in RFC 3920 to define a method whereby the
>> server could flag negotiation of TLS as mandatory to negotiate ("MTN")
>> in order to enforce local service policies. The discussions since then
>> have always assumed that we need a way to flag (some) features as MTN.
>> The thread here has attempted to define MTN in a standardized way,
>> rather than assuming that MTN will be explicit in the definition of some
>> features (TLS) but not others (everything else), implicit in the
>> definition of a given feature (SASL is always mandatory) or implicit via
>> the inclusion of a given feature and only that feature at a particular
>> point in the stream negotiation process (what Mr. Cridland appears to be
>> suggesting).
> 
> I feel similar to Dave on this matter, that the suggested changes to stream 
> features amount to overengineering.
> 
> If we want a future feature to be required, it should be enough to state in 
> the spec that it is required.  

Sometimes TLS is required and sometimes it isn't -- that depends on the
local service policy.

The case of SASL or dialback for s2s is interesting, but we have never
clearly defined that. It might be that the receiving entity would
require either SASL or dialback in some situations, in which case SASL
is not required in all circumstances (again, it depends on the context).

> A client isn't going to say to an 
> end-user: "Sorry, the server requires the 'ugly-long-namespace' feature in 
> order to log in."  Either the client will display a generic error ("Sorry, 
> the server requires a feature not supported by this client"), or it will be 
> spec-aware and display ("Sorry, the server requires the Foo feature, which is 
> not supported by this client" (except that it sort of is, if the client can 
> write such a message..)).
> 
> 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).

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

> Everything else should almost always be optional.  Is anyone really planning 
> to require compression or stream management for example, to the point where 
> the client can't even use the service without them?  I don't think you will, 
> but in the chance that you do, you can bounce the client off with a stream 
> error.

Sure, if people find that acceptable. My concern is not so much with
endless extensibility and future-proofing, but with features that right
now can be either mandatory or voluntary depending on local service
policies.

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/

iEYEARECAAYFAkrhI7wACgkQNL8k5A2w/vxHJwCgt3WrcHlJw55f3RhIkZKxpTMV
PIQAoIXNkEgdrfJ+K0mpwPMa47tyB0OR
=YdhH
-----END PGP SIGNATURE-----