<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 April 2014 06:15, Philipp Hancke <span dir="ltr"><<a href="mailto:fippo@goodadvice.pages.de" target="_blank">fippo@goodadvice.pages.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 24.04.2014 10:58, schrieb Kevin Smith:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Room logs: <a href="http://logs.xmpp.org/council/2014-04-23/" target="_blank">http://logs.xmpp.org/council/<u></u>2014-04-23/</a><br>
</blockquote>
[...]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) <a href="http://xmpp.org/extensions/inbox/rayo-clustering.html" target="_blank">http://xmpp.org/extensions/<u></u>inbox/rayo-clustering.html</a><br>
Accept as Experimental<br>
<br>
Lance/Philipp to post their objections to the council/standards lists.<br>
</blockquote>
<br>
here we go... the requirements make senese. However,<br>
    Nodes and Clients SHOULD NOT be aware of each others identity<br>
    of presence, and SHOULD only communicate with the Gateway(s).<br>
stated later in section 4.2. actually shows why the XSF does not need to standardize this;<br>
it requires no extensions to a stock rayo client.<br></blockquote><div><br></div><div>Not to the client, no, but it's important to the implementation of the proposed server components (gateways and nodes) which have behaviour that is beyond that in the XMPP RFCs and requires standardisation for gateways and nodes from multiple vendors to interoperate, as went my justification on the other thread.</div>
<div><br></div><div>If the XSF were not to host this specification, where would the appropriate place be? Rayo is already an XEP, and this is the specification of specific behaviour of XMPP components, so I don't really see how there is a more suitable venue...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ISTR that ejabberd allows multiple components to connect for the same domain and then does some kind of session-based loadbalancing.<br>
This is somewhat more generic but we have not standardized either either.<br>
<br>
<br>
minor issue:<br>
The spec is also using RFC 2119 language a little too often in places, where this is not required for interoperability. E.g. for using two domains or when describing load balancing.<br></blockquote><div><br></div><div>Is that not something that can be dealt with in the post-publishing review phase?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<hat type=guy-who-used-to-write-<u></u>servers><br>
Using resource identifiers to encode the rayo node, similar to the way google talk apparently uses them, might allow the gateway to minimize the state kept.<br>
</hat><br>
</blockquote></div><br></div></div>