Those are good questions, but I'm out of time for further discussion until (probably) Tuesday. I'll let other folks on the list reply.
On 3/3/11 4:15 PM, Mark Rejhon wrote: > 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
smime.p7s
Description: S/MIME Cryptographic Signature
