[Standards-JIG] UPDATED: JEP-0170 (Recommended Order of Stream Feature Negotiation)

Philipp Hancke fippo at goodadvice.pages.de
Fri Jan 27 16:45:34 UTC 2006

some questions about the dialback section...

 >   1. TLS
 >   2. SASL
 >   3. Dialback
Which SASL mechanism?
How does the initating entity know that it is supposed to do
dialback after SASL?

Dialback+stream compression:
 >   1. TLS
 >   2. SASL
 >   3. Dialback
 >   4. Stream compression
Why not
    1. TLS
    2. SASL
    3. Stream compression
    4. Dialback
which would allow negotiating stream compression immediately
after <stream:features/> is received?

Furthermore... what about AT LEAST documenting starttls+dialback?

And finally,
 > Note: Even though it may appear that SASL does not provide
 > meaningful authentication in the case of self-signed
 > certificates or certificates whose root certification
 > authority is not trusted by the receiving entity,
 > RFC 3920 requires its use, a recommendation which this
 > document does not override.
regarding XMPP-Core:
What if there are no 'usable' SASL mechanisms, which is only
known AFTER <starttls/>?
(I am assuming that a server will not offer mechanisms which
  can not possibly be negotiated successfully)

Apart from EXTERNAL, which mechanisms are capable of
authenticating two domains which have not previously been aware
of each other (§2.2.1 of RFC 2779)?



More information about the Standards mailing list