-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/20/13 5:43 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0288 (Bidirectional Server-to-Server Connections). > > Abstract: This specification defines a protocol for using > server-to-server connections in a bidirectional way such that > stanzas are sent and received on the same TCP connection. > > URL: http://xmpp.org/extensions/xep-0288.html > > This Last Call begins today and shall end at the close of business > on 2013-03-19. > > Please consider the following questions during this Last Call and > send your feedback to the [email protected] discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
Yes. > 2. Does the specification solve the problem stated in the > introduction and requirements? Yes. > 3. Do you plan to implement this specification in your code? If > not, why not? I don't have any server code in which to implement it. > 4. Do you have any security concerns related to this > specification? No. > 5. Is the specification accurate and clearly written? I have several questions: Section 2.1: "If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation)." Is there any reason why the "should" is not a "MUST"? Section 2.2: This isn't really negotiation, is it? More like simply enabling the feature (no parameters negotiated etc.). Section 2.2: "To enable bidirectional communication, the connecting server sends a <bidi/> element qualified by the 'urn:xmpp:bidi' namespace. This SHOULD be done before either SASL negotiation or Server Dialback." Why is this not a "MUST"? I don't see what good it would do to negotiate / enable bidi after SASL negotiation or server dialback. Section 2.2: "Also note that the receiving server MUST only send stanzas for which it has been authenticated - in the case of TLS/SASL based authentication, this is the value of the stream's 'to' attribute, whereas in the case of Server Dialback this is the inverse of any domain pair that has been used in a dialback request." This is already covered by RFC 6120 and XEP-0220. Does it need to be reiterated here? Section 3 has "C:" and "S:" but these are both servers. It might help to change them to "S1" and "S2" or "I" and "R". Add the TLS negotiation after <proceed/> for Example 3 and Example 4? I think Example 5 is OK but I think it's mislabled (it's really about piggybacking / multiplexing, not stream setup before TLS as far as I can see). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrl8NAAoJEOoGpJErxa2pndoQAJfGfuToD7EOK6CsE2D9fVwH 5POwGSEbqGES74TrS+ditlGwCYgT5oaf73Lru8xHj6vHO/+98qD7ryXzJzEjGKqA 4liakwBUeS6IDESX54HaKyGXp+urrXkymswm9O3vylDN+gmONBiOtW1LF6oS8/50 UXNK0m9ShmC26psiJlSHXnKk+3akxXgOGZrE/ql4RO4hw8zs2ZCQvP2g823zipF6 k2oy0ZN9zBFXZjsFqKIEa5BivT4TLYpk9kQpE6vEAd2Qg9gBQWkg4Hx5zfnLVaWd DKpkKJGVlt0JR/PIz3RV35zZPXNXRvKt2V7NGtSQg5eMcmVyQ7k6UosD+NR2bu/O wblAzj1+LU0ruQkI3Keq6pdGjaF10i8tUtlzcWJKI6qTZKe31TJVzew0sFPX0LXs VEug7hPl9LiUxpNatTBdGcksIfkKBggQdiVKRURuefRw9spJmn0QQXwJLfTqKb4E bqnq4CVyeKceM1im8o6vM6XszGgVrZ/qavdWpKijTXEyShGNM3w0tuKR24crr6Lo 9pLDVC2AEdAQNOtreOT5V3IWjHbi8VX6+Xj08g5D7K0LFw3tUSyRRyxw3VnJQzaD +K2diOqaBvkse0t+3t930ocKoEabx0b03UXoTJJXOPhxg8UOmGbiNPynFme3IR82 gLtPOA+BS3LgpnPAkSK/ =hsP4 -----END PGP SIGNATURE-----
