On Thursday 22 October 2009 20:32:12 you wrote:
> On 10/22/09 7:07 PM, Justin Karneges wrote:
> > 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.
Yes, I should have been more clear: the spec would define the feature's
requiredness, whether that means always required or only sometimes. For
example, TLS is required if <required/> is present as a child element, and
resource binding is always required.
I understand the rationale for wanting to make <required/> a generic concept,
because it might be handy if we find ourselves defining such a flag for lots
of features. I guess my question is if anyone is really wanting to make all
those features flaggable. Right now, only TLS has this flag, and the rest of
the features are defined as either required or optional.
> 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).
Something to define, then. :)
> > 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).
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.
> > 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.
-Justin
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.