On 6/5/13 4:27 AM, Dave Cridland wrote: > Thanks for the feedback. > > On Tue, Jun 4, 2013 at 10:41 PM, Peter Saint-Andre <stpe...@stpeter.im > <mailto: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.
Yeah, I find those very confusing and these days I always use "ought to" (or somesuch) instead of lowercase "should". > 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. It's not a hill for me to die on. > 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. Receiving entity offers, initiating entity enables. > 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. Fine with me. > 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. I don't see any harm in including that text, it just seemed duplicative. > 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. Thanks for considering the feedback. Peter -- Peter Saint-Andre https://stpeter.im/
