On Thu, Mar 3, 2011 at 3:53 PM, Peter Saint-Andre <[email protected]> wrote: > 1. It seems to me that the real-time-text feature is very important to a > few small classes of users (mainly deaf people, but perhaps also to > certain users of specialized applications such as emergency services and > hotlines). To everyone else, it is merely a curiosity. > > 2. Given that user profile, I'm less concerned about producing a more > complex protocol *if* that is the only way to really optimize the > experience for the target population(s). Naturally, if we can design a > simpler protocol that gets the job done, we'll all be happier.
Without commenting on opinion, I'll just say this: What matters here is some reasonable level of interoperability between different software clients, throughout the world is necessary, and is sufficient raison d'etre enough for some form of real time text spec to exist! > 3. Do we really need feature negotiation and session establishment? It > seems simpler to use disco and caps (XEPs 30 and 155) to see if the > other side supports RTT, then just start sending messages. I thought of that, but what if the other person doesn't WANT to send replies in real time text? Then we've got a one-sided real time text conversation. That gets very confusing and annoying to unaware people. How do we resolve this scenario, spec-wise? Both ICQ and AIM used 'initation' mechanisms that ensured that RTT was turned on for both ends. Related issue: What about privacy concerns, unaware people pasting sensitive text before deleting the sensitive parts before transmitting? Some of us have often pasted text into the textbox of an IM before editing it, before sending. RTT reveals all. > 4. We need to describe how RTT interacts with chat states (XEP-0085). Will look into this. > 5. In several places the space defines multiple ways of doing the same > thing (e.g., type='reset' and <r/>). Let's avoid that if possible. This will be done. > 6. I agree with most of the comments made in this thread about cleaning > up the namespacing, moving the UI and implementation stuff to separate > sections, not designing around out-of-order messages and packet loss in > existing XMPP servers or deployed services, etc. Agreed on all, except for lost messages, for reasons already subsequently explained. > Could you clarify what you mean by "transform-based mechanism"? I don't > see that term in version 0.0.1 of the proposal. Kevin used that terminology on the "Edit Codes" system I used, so I switched to replying in that terminology. Transforms are a series of steps that modifies the string that is real time text. "Insert this, delay, insert that, delay, move cursor, delay, backspace, delay, etc" A serial sequence of steps. Another example is ISO6429 (or VT100 or ANSI or Linux escape codes) can also kind of be considered a transform too, because it transforms a communications terminal screen to a different state of display. The terminolgy used so far in this mailing list, has been: Retransmits: Transmit the whole line of text every keypress Fragments: Transmit only the fragment of new text at end of line. (harder to do real time editing) Transforms: Step by step operations. Makes it easier to add delay codes and cursor movements. >> First: From what I can see, it looks like I am able to chop at least >> 40% of non-boilerplate text (including splitting out implementation >> details into Implementation notes) with only extremely minor >> modifications to existing experimental software (keep seq/msg/type >> attribute, keep all edit code transforms). > > Why are we optimizing for backward compatibility with pre-alpha software? I'm not. I'm just stating a clear example of how the document was more complicated than its own implementation. I just think the protocol is already pretty simple for its full-spectrum experience (including inter-key delays and cursor movements). As you already know by previous messages in the mailing list -- I also tried designing other methods like retransmits and fragment methods, but those weren't practical for reasons explained. Kevin seems apparently convinced we'd have to go with a transform method. I've researched the following transform methods, too, for my real time text spec. - XML based (current spec) - made-up proprietary control codes (old spec I never submitted to XMPP) - ISO6429 based (I wrote a proposal for this, but it was clear it wasn't the proper tool for the job) >> -- Merge the Backspace/Delete edit code transform? >> A backspace could be done by using a delete operation with >> repositioned cursor. (or vice versa). The intent to include both was >> to make it easy to use the keypress-recording technique of real time >> text. (If an implementor decides not to use the before-and-after text >> compare method to generate the edit code transforms) >> LEANING: Undecided > > Here again I think it would be better to recommend one approach, or at > least not reflect different implementation approaches in the protocol > itself. I should also note that if I include both codes, implementors don't have to use both for sending messages (they can use backspaces for deletes, and deletes for backspaces). It's mainly an issue for reception, being able to support incoming messages that has one or the other, and also an issue of allowing easy programmer implementation of keypress-monitoring methods of real time text transmission. (My open source implementation uses the before-text and after-text comparision method to generate the real time text transforms) >> -- Remove the Reset code? <r/> >> This code is really simple, and this code is transmitted if the user >> clears their message before sending. >> LEANING: Keep code > > See above about having two ways to do that same thing. I'd like to keep <r/> and remove type="reset" >> -- Remove the 'msg' attribute? > We might not want to try to do everything in one spec. Small pieces > loosely joined, and all that. I'm going to remove msg, it can be added back later, or be used as an experimential extension in special niche markets (without interfering with interop, if done properly) >> -- Support for group chat. >> LEANING: Remove support for group chat. > > Yeah, this scares me somewhat -- although here again it might be useful > for certain specialized user communities. (See arguments for and against > chat state notifications in MUC.) I'm still intentionally keeping it compatible with the future addition of groupchat. >> -- Simplify, change or remove protocol negotiation? >> LEANING: Undecided. I feel more discussion is needed. For now, I'll >> keep until I'm almost done with other things. > > I think we can cover almost all of the use cases with disco and caps. We > prefer not to design for use cases we don't know about or can only > imagine at this time. Yes, I agree. But help me out, based on my written concerns: How do I ensure that the feature is turned on BOTH ends (disallow unidirectional real time text) -- with with BOTH of the users' informed consent? It's a can of worms, of privacy issues and/or mis-sync of enabled RTT state. I appreciate your comments. Thanks! Mark Rejhon
