Thanks for the feedback. On Tue, Jun 4, 2013 at 10:41 PM, Peter Saint-Andre <stpe...@stpeter.im>wrote:
> On 2/20/13 5:43 PM, XMPP Extensions Editor wrote: > > 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"? > > It's a should not a SHOULD, too. While I don't think it'd be useful, I don't think it raises an interoperability concern. For instance, a server could suggest bidi after some traffic has flowed, and if the peer starts sending traffic back, great - if not, nothing's lost. As such, RFC 2119 language would seem inappropriate. > Section 2.2: This isn't really negotiation, is it? More like simply > enabling the feature (no parameters negotiated etc.). > > If I'm to be pedantic, I might suggest this is really a feature offer, and neither enabling nor negotiating. Happy to pick a term and stick to it throughout, but I'd note this is splitting hairs. > 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. > > As above - this shouldn't be "SHOULD", but "is typically" or some such. > 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? > > Yes, I thought so at the time. The distinction between what RFC 6120 and XEP-0220 says is in the direction. > 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". > > Yes, R and I seem sensible. > Add the TLS negotiation after <proceed/> for Example 3 and Example 4? > > OK > 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). > > I'll take a look.
