On 6/23/11 12:41 AM, Mark Rejhon wrote: > Re: http://xmpp.org/extensions/inbox/realtimetext.html > Hello Peter, -- thank you so much for your comments. > I've addressed some of the comments in my reply to Kevin. > I wrote a very good response to Kevin. > > > On Thu, Jun 23, 2011 at 12:03 AM, Peter Saint-Andre <[email protected] > <mailto:[email protected]>> wrote: > > "Reliable message delivery." > > > Changed to "Reliable real-time text delivery." which is actually the intent. > > > > > 4.2.2 Why SHOULD 0 (rather than MUST)? > +1 to MUST. > > > It's not necessary for a MUST because the 'seq' synchronizes everytime > type='new' because of Section 4.6.3 in Error Recovery. One end may > disconnect and reconnect, so seq may be far away from 0. > That said, I've changed it to a MUST anyway -- it's no harm.
OK. > > 4.2.3.3 - Start shouldn't be used for discovery, disco/caps should. > > > We want to address this too, but a clarification: start isn't used for > disco, it's used for signalling: > "Experimentation during the Experimental stage is needed to determine > best interoperability for the process of /starting// /a real-time-text > session and /signalling/ the remote end that a session has started (in > the future, it might be a process where one end starts a session, and > the other end does an Accept/Reject -- similiar to AOL AIM Real Time IM. > Or it might be a different preferred method of starting a RTT > session). Due to section 4.3.1, failure of signalling is not a > catastrophe at this early experimental stage." .... OK, I'll put more thought into the start process. Somehow I think a Jingle negotiation would be overkill. ;-) Something along the lines of XEP-0084 might be appropriate (and you might be able to borrow some text). > > 4.3.2 Seems inappropriate - we should only be suggesting UI > > behaviours, where they're not security critical, not mandating them. That was Kev, not me. :) > Section 4.3.2 is not UI -- it is a critical feature of XMPP Real Time Text. > For an animation that explains why 4.3.2 is necessary: > http://www.marky.com/realjabber/real_time_text_demo.gif > It also maintains backwards compatibility too with non-RTT clients. Kev meant we don't need to use MUST or SHOULD with regard to user interface, instead we can use gentler words like "clients are encouraged to..." and such. > Looking at the text and examples, I wonder if just sending a message > with a <body/> is enough information for the recipient to present the > messages appropriately. Consider this example: > > <message to='[email protected]' from='[email protected]/orchard' > type='chat' id='a01'> > <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'> > <t>Hello, </t> > </rtt> > </message> > > <message to='[email protected]' from='[email protected]/orchard' > type='chat' id='a02'> > <rtt xmlns='urn:xmpp:rtt:0' seq='1'> > <t>my </t> > </rtt> > </message> > > <message to='[email protected]' from='[email protected]/orchard' > type='chat' id='a03'> > <rtt xmlns='urn:xmpp:rtt:0' seq='2'> > <t>Juliet!</t> > </rtt> > </message> > > <message to='[email protected]' from='[email protected]/orchard' > type='chat' id='a04'> > <body>Dude, what happened to my message?</body> > </message> > > > It's legitimate -- it also happens in the real world: > Somebody immediately copies and pastes a message on top of the old > message, and then hits Enter immediately. > > A client could do it fraudulently or by bug, but there are many things > that an XMPP client can also do fraudulently, too. It is however, quite > obvious, and users would complain about the 'bug' Or even just misbehavior by the other party. There are no good technical solutions to social problems. :) > How does the recipient know that the last message is related or > unrelated to the previous RTT fragments? > > > That is possible to happen, especially if there's out-of-order message > delivery, but I was told that does not happen -- so I removed the > message identifier that was in the 0.0.1 spec. I was not concerned about out-of-order stanza processing. > We might consider including something like this in the last message: > > <message to='[email protected]' from='[email protected]/orchard' > type='chat' id='a04'> > <rtt xmlns='urn:xmpp:rtt:0' event='done'> > <body>Hello, my Juliet!</body> > </message> > > That raises the question of whether we need identifiers for each RTT > "sequence", as so: > > > I used to have message identifiers in XMPP RTT specification version > 0.0.1 as the "msg" attribute! > I removed them. They can still be used as a private extension, but I > removed them from the spec, because the message identifier was > apparently not necessary for things to work reliably. I'd had preferred > to keep it included (as you apparently prefer!). But then, > simplification became a high priority. I don't prefer them. I was asking a question, not putting forth preferences. We use this list as a venue for just thinking, sometimes. :) > From what I recall, I think Kevin agreed on erring on the side of > simplifying, when I asked if I should remove the msg identifier from the > last spec. It can be re-added as an optional feature, as an additional > integrity layer to error recovery. > > (At this stage, I'd like to hear agreement from several people first > though about this detail.) Kev was right about simplification. I just wanted to gain some clarity on whether we had a problem to be solved here. > > 4.5.1.1 insert is ambiguous - what does 'at position p' mean? > > Forward delete should be explicitly rightwards, if that's > the intent. > > How does this play with RTL languages? > Good questions. > > > Forward Delete is a leftwards delete in Arabic, according to Wikipedia, > and in Apple Mac's help file. > I'm adding clarifying wording, though. Excellent. > > 4.5.1.3 Why are we dealing with utf-16 when everything is mandated > utf-8? > > UTF-8 FTW. > > > What do you think of Simon's suggestion? > I am switching to "code point" (UCS4 counting) method. > > In many languages (i.e. Java) it is difficult to easily calculate > positioning and indexing UTF-8 because most programming languages do not > have convenient routines for string-indexing UTF-8. It is necessary to > come to a simple programming standard, due to the Unicode considerations > such as multiple Unicode characters representing one displayable Unicode > character. > > XMPP RTT is essentially a standard for editing an array of 16-bit > integers (counting on "code units"), and UTF-8 has variable character > lengths that complicate programming significantly. > > However, I am thinking of following Simon's excellent suggestion. > > What do you think of his suggestion of using "code point" counting for > length and position attributes? > That'd pretty much essentially turn XMPP RTT equivalently into a > standard for editing an array of 32-bit integers instead (allow use of > native UCS4 string functions in programming languages that stores > strings in UCS4 format). It makes my 16-bit programming slightly more > complicated, but much easier than counting in UTF8. It might be a > better long term goal. > > Opinion? On the wire is no such thing as a code point, there are only code points that are encoded using an encoding form like UTF-8 or UTF-16. For details, see: http://tools.ietf.org/html/draft-ietf-appsawg-rfc3536bis-02 Given that XMPP is pure UTF-8, I don't see a compelling reason to count UTF-16-encoded code points or UTF-32-encoded code points. > Also, this seems inconsistent with the forward delete function: > > "If the p attribute is omitted, the default value for p is the length of > the current real-time message." > > How is that applied to the <d/> element? Is the 'p' attribute REQUIRED > in that context? (You can't forward delete beyond the end of the > message.) > > > Excess backspaces and deletes are ignored, so that ends up becoming a > do-nothing element. > Useless action elements shouldn't be used for bandwidth reasons, perhaps > I should mention that detail in the spec. (making note to mention this.) Thanks. > In Section 6.4: > > <message to='[email protected] <mailto:[email protected]>' > from='[email protected]/home <http://[email protected]/home>' > type='chat' > id='a01'> > <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'> > <t>Hello Bob, this is Alice!</t><d n='4' p='5'/> > </rtt> > </message> > > Why not send two stanzas? > > > That can be done. The examples are merely at educating people on real > time text, at progressively more difficult levels. > > In reality, the real world transmissions in all my test software, more > resemble section 6.9 with everything at a very fine-grain level. There > are over 60 action elements per second when you hold a key down (30 > characters per second, with 30 key press intervals embedded within), and > results in approximately 700-byte <rtt> elements. > > Section 6.9 (the one that should happen in the real world with > RECOMMENDED key press intervals, which has high acclaim and rave > reviews) however, is the most complex example. So I wrote the examples > in a progressively-more-complex way in an attempt to educate the reader. Yes, I figured that out, I just wasn't sure why we needed that kind of complexity. I'll look at it again. > Section 7.1 talks about interoperability with RFC 4103 and T.140. How > does an XMPP entity negotiate an RTT session with a SIP entity? (I'm > wondering if we need a Jingle application type for RTT...) > > > The RFC4103 people are covering that. I've published a SUPPLEMENT > document on realjabber.org <http://realjabber.org> that briefly touches > upon this; and will be expanded. Gunnar Helstrom of Omnitor, is the > go-to guy for this. OK. For XMPP<=>SIP interworking here, we might need to use Jingle, since I would imagine that SIP uses standard session management techniques (e.g., SDP) to establish an RTT session. Peter -- Peter Saint-Andre https://stpeter.im/
