Hi,
I found the following items that need correction:
1. Section 2, Protocol: in the first bullet set, the fourth bullet is
wrong, it should be "The Stream ID of the stream from the Receiving
Server to the Originating Server is ..." - the servers are reversed;
2. Section 2.3.4.2: there is an empty Note Well block in the fourth
paragraph.
3. Example 31, 35 and 41: the error should be <remote-connection-
failed>, as the text before the example states.
The following items are questions I have about the spec:
1. Section 2.4.2.2: Error cases for Authoritative Server Processes
Verification Request
Two error cases are shown, but I think a third is also required: the
value of the 'from' address provided by the Receiving Server is not
authorized to connect to you.
If some miss-configured outgoing S2S service at Originating Server
initiates a connection to a domain that he was not allowed to, then
the Authorization Server has this opportunity to prevent the
connection from completing.
2. Section 2.6.2.1, Invalid connection from Auth Server to Recv Server
The spec notes that the Recv Server MUST close the connection to the
Auth Server if it receives a <db:result /> of type='invalid'.
If the verification is being performed in a piggyback connection (as
permitted in Section 1.5, last note), this is not very helpful because
it could close an already active and useful connection. I would
suggest that a <db:result type="invalid" /> doesn't alter the
connection at al. This way the Recv Server can reuse that connection
for other purposes, including other verifications.
Also notice that the behavior (whether to close or not the connection
after receiving the <db:result />) is left unspecified in the
following Section 2.6.2.2, Valid Connection. A small note common to
both 2.6.2.1 and 2.6.2.2 staging that the connection between Recv and
Authz can be left open for reuse probably clarifies the whole issue.
3. Section 3, Reuse of Connections (piggybacking)
1. Cosmetic: maybe we should start using the term multiplexing;
2. The second paragraph limits the piggyback connections to sub-
domains of the initial negotiated domain.
I don't see any security reason for this. You can allow any domain to
be multiplexed on an already existing connection, provided that the
dialback verification process is successful. This would allow services
with large number of domains to reuse S2S connections much easily.
3. Support for multiplex connections
Going forward, it would be cleaner if the Recv Server announces
support for multiplexed connections in the initial stream features.
Something like:
R2O:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<required/>
</dialback>
<multiplex xmlns='urn:xmpp:features:multiplex'>
<optional/>
</multiplex>
</stream:features>
This clearly announces support for the feature and would precent try-
and-miss attempts on future servers.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
