First, I want to comment on how much I like the approach of this draft. It is simple and flexible and can be the basis for many applications on top of it so I want to say nice job to the authors.
Most of these comments are nits with the document and not the overall design of the protocol but there are also a few blanks that need filled in. 1. In Example 3 where the Responder sends the session-accept, the jingle stanza contains a 'host' attribute for '[email protected]'. This attribute isn't included in Example 1 where the Initiator initially sends the session-initiate. But both include a <host> transport element that looks more like a u...@host. The term host seems to be overloaded here and its not clear what it refers to. It seems like the conference jid should be in both the session-accept and the session-initiate. 2. Section 5 is titled, 'Determining the Host Type' yet there seems to be little in this section that explains what host 'type' you're trying to identify. It seems like its more Host or Entity Capabilities. It seems like this section should encourage the use of XEP-0115 to discover capabilities. 3. Section 6 describes how to advertise a session. I have some questions here. a. Is the session supposed to be a unique identifier? Is is supposed to be a human readable name? If its not a name, can a 'name' attribute and a 'description' attribute be added to help the user determine if they want to connect to the session? If not, how would this info be discovered without first connecting to the session and synchronizing the document? b. Is there a preferred way to request the sessions in a serverless messaging (XEP-0174) environment? 4. Section 8.1, point 1 says both the host and the invitor MUST offer to send the state. Again the meaning of the term 'host' is not clear. 5. Section 8.2 says a joiner must abort the negotiation with other users that offered to send state. It isn't clear what type of response to a <state-offer/> is used to abort the negotiation? 6. Section 10.1, the formal definition of the <sxe/> element lists the 'id' attribute as required but Example 9 in Section 6 doesn't include an 'id' attribute. 7. Section 10.4, it is not clear what is meant by 'Server' here. This whole section implies that you might have an editing server that sends updates to all participants but it is not clear why a participant choosing to serve other participants would have to have any special definition. If a 'Server' really is a different type of entitiy, then it needs to be explained. 8. Section 10.6.1, Table 7. 'replacefrom' and 'replacen' are not defined anywhere. I quickly realized that 'replacefrom' meant from a character position but it took a few reads to realize 'replacen' meant to replace for 'n' characters. In the table entry for 'replacefrom', it says only allowed if 'chdata' and 'replacefrom' attributes are also included. This is confusing and would make more sense if 'replacefrom' required 'replacen' and vice-versa. Thanks again for the contribution. Tom Pusateri
