Hello standards-list, hello Mark, "inspired" by the recent discussions surrounding XEP-0301 (Real Time Text) I had a look over it's current status and felled I should provide some feedback. Some is rather minor some I'm somewhat more concerned about, I've ordered it sequentially rather than by importance.
Section 3: Glossary The "RTT" entry seems superfluous to me. I'd be better to just note the acronym in the "real-time text" entry. Also the remark about the element's name is misleading as that is generally lower-case. Section 4.2.2: 'seq' attribute It seems to me the start of a session (and therefore when to reset this to 0) is not clearly defined, since the start and cancel events are purely optional. In a more general sense I'm somewhat concerned about the attempt to reimplement the transport layer on the application layer. (see below) Section 4.2.3: 'event' attribute I feel the requirement for session start and cancel needs to be either tightened (if we decide we absolutely need it for this protocol) or removed. Having it truly optional makes it useless for detecting the actual session start and end IMHO. It's sole purpose appears to be mapping to SIP, which is a problem possible best handled separately. The new and reset events appear to have been introduced under the assumption that messages get lost. If they are not the reset event can be safely removed and the new event is implicit upon receipt of a <body/> element. Section 4.5.1: action elements The normative text in this section should be further explained. E.g.: What is REQUIRED for the <t/> element? Support, inclusion in each <rtt/> element, etc. (It is relatively clear to me what you mean, I just wish it was somewhat more fleshed out) "A client conforming to this specification MUST accept <t/>, <e/> and <d/> elements and handle them as described in the following..." Section 4.5.1.3: counting It appears to me that the rules for determining the position and count of code points are somewhat backwards. In particular if the sending client does perform any normalization before sending the counts need to be based on the normalized version since the receiving client can not undo such normalization (this is the opposite of what is described in the text). Also most of the described transformations are only relevant for display on screen and should not change the string. IMHO it should suffice to count code points based on what is send over the wire. Section 4.5.2: action elements I'd like to hear some rational on why there is forward and backward delete. Both appear to be able to generate the same results. It did occur to me that they are meant to be used in conjunction with cursor display. However, it appears that this would cause interesting possible situations. E.g. what happens if a character is forward deleted at a position preceding the cursor. In that situation the absolute position of the cursor should move one to the left, but will instead move 1 to the right relative to the text (it might move over the right end). I'd prefer expected cursor position to always be transmitted explicitly in these cases and have either delete variant removed. Section 4.6: error recovery As mentioned before, the attempt to correct errors is my biggest concern about this XEP. For the case of reconnects it appears to me that the sending client will always be able to notice this situation and treat it as a new RTT session. Messages being dropped by servers on the other hand is an issue I've not yet experienced. I'm however willing to believe there are servers in existence that do this. Ideally I'd expect this to be discoverable via an error response, but seeing how this itself generates traffic I can see how implementations would not send this. Do we have other protocols that need to respect this? Ideally I'd like to simplify the protocol a bit in this matters. E.g. sequence numbers could be reused for each new RTT message, seq="0" would then imply event="new", etc. However, I've not thought through all implications of such a system yet. Section 6.4.1: message length limit In the second example with the split messages I would not have expected an empty <rtt/> element. If that is actually intended to indicate the <body/> is part of the RTT session this should be mentioned elsewhere. Regards, Florian Zeitz
