> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol?
While I think there is a gap in the XMPP specifications in ways for allowing a user to transparently switch clients in mid-conversation, it’s seems this spec inadequately addresses that gap. The key problem, which I believe has been noted by others, with the spec is that does not deal with the all to common case that the client the user wants to switch to is not online at the time the user decides to switch to it. > 2. Does the specification solve the problem stated in the introduction and > requirements? The spec says: If the target user is online with multiple resources when the original message is sent, a conversation ensues on one of the user's devices; if the user subsequently switches devices, parts of the conversation may end up on the alternate device, causing the user to be confused, misled, or annoyed. I think that, with this spec, when the user switches (online) devices he may well end up with only part of the conversation and that in turn will cause the user to be confused, mislead, or annoyed. The spec further says: All clients that turn on the new protocol MUST be able to see all inbound instant messaging messages. All clients that turn on the new protocol MUST be able to see all outbound instant messaging messages… where in both cases, I assume, all clients refers to all “online” clients. It is clear from section 6 that not all clients will be able to see IM messages as they are not eligible for carbon delivery. Maybe the requirements just need to be clarified, s/all/all carbon-eligible/. Despite this MUST, I assume all servers are free to not carbon any eligible stanza. If not, what are they to do when faced with a situation where carbon’ing the stanza would, for instance, violate some security policy? > 3. Do you plan to implement this specification in your code? If not, why not? Personally, I rather not implement this but instead an extension that addresses users switching to not yet online devices. > 4. Do you have any security concerns related to this specification? Yes. The security considerations says: The security model assumed by this document is that all of the resources for a single user are in the same trust boundary. Aside for dislike of the term “trust boundary” here, I think the assumption is a bad one, especially from a security perspective. The user may not trust his clients equally or trust the network they use equally. The server might not trust the clients equally. And, even if the ‘trust’ was equal, the security factors may not be and that’s likely attackable. And, of course, if an attacker gains control of any of the user’s clients, it can use carbons to gain access to information to/from that user’s other clients. I have a bit of a concern with the paragraph: Outbound chat messages that are encrypted end-to-end are not often useful to receive on other resources. As such, they should use the <private/> element specified above to avoid such copying, unless the encryption mechanism is able to accommodate this protocol. First, the “should” appears to stated for “useful”ness reasons, not for security reasons, hence I think the paragraph is misplaced as worded. Second, the should appears to be possibly applied to implementations which have not specifically implemented this specification and, as such, could be viewed as making the specification not truly optional. Hence, I suggest moving this paragraph out of security considerations (such as to section 9) and either changing “they” to “implementations of this specification” or changing the “should" to a “may”. > 5. Is the specification accurate and clearly written? I think it clear enough that someone wanting to implement could implement it. If I were to implement this, I would want the spec to be clear that a server is free not to carbon any stanza of its choosing… just as it’s free not to forward any stanza its choosing. This is yet another reason why the requirements quoted above are not necessarily addressed by this specification… that requirement, IMO, is simply unrealistic. — Kurt
