I think this mail gets me up to date. On Mon, Jul 23, 2012 at 8:17 PM, Mark Rejhon <marky...@gmail.com> wrote: > Due to the large number of comments from a key person at XSF (you) I agree > with you. I have many comments and questions for you first, that I'd like > you to address. I will reply in two emails -- this email is regarding > section 1 through 5. I have prefaced with [Comment], [Question], and > [Change Made] in appropriate places for easy reading.
I stress that these are personal comments, not coming from Council. >> == Introduction == >> This seems mostly fine. I wonder about the reference to >> realjabber.org. Partly because it's a reference to a potentially less >> stable URL, and partly because I think the name is inflammatory - did >> the XSF or Cisco grant the trademark use? > > > [Question] > Understood -- animation really helps explains real-time text, if they > haven't seen it before. > Can we use a more well-known site (i.e. realtimetext.org?) since we can put > my animations there too? I think 'real time text' is a less contentious term than 'real Jabber', I'd feel a bit happier with a link there instead. >> "The bounds of seq is 31-bits, the range of positive values of a >> signed integer" - I'd be inclined to make this something like "The seq >> attribute has an upper bound of 2147483647 (2^31 - 1). If this upper >> bound is reached the following RTT element will reset the seq >> attribute to 0, i.e. at the upper bound the values would be (in >> successive stanzas) 2147483646, 2147483647, 0, 1)" or words to that >> effect. > > > [Comment & Question] > I agree, but I don't think it is worthwhile cluttering it by explaining > wraparound: > -- Incrementing only occurs once every second or slightly less (0.7 > seconds). In practical situations, wraparounds will never happen. If you're starting from a random point, wraparounds may happen. If you're starting from zero they're effectively impossible, as you note. >> It's not clear to me why setting seq to a random initial value should >> help with MUC or multi-resource cases - in these cases you know the >> full JID of the entities involved and a random start point seems to >> make it harder to understand what's going on, rather than easier. > > > [Question] > Imagine a simultaneous login, both logins somehow started typing and the > client doesn't distinguish the two. If both started at the same seq number > (0), then there will be some situations where the seq looks like they are > incrementing when recieving a <rtt/> from one client than an <rtt/> from a > different client. This will cause occasional text scrambling to occur > (until it disppears in the next Message Reset). Your argument elsewhere has been, I think, that it's fine to track RTT by bare-JID because you won't have multiple clients for the same user sending you RTT at the same time. If this is an expected use, we need to track RTT full-JID. If it's not, I don't think it's a problem to start from zero. >> "The event attribute MAY be omitted from the <rtt/> element during >> regular real-time text transmission" - what is the the alternative >> you're allowing clients, and what is "regular real-time text >> transmission"? > > > [Change made] > Clarification made: "The event attribute is NOT required for <rtt/> when > transmitting changes to an existing real-time message." I'm not fond of either MAY or not required here - it seems like the behaviour isn't optional in any way, but firmly defined depending on the content of the stanza. It's not immediately clear to me what the right wording is, but it seems like it should be tighter. >> Choice 1) If you implement 308 and you also implement 301 you MUST >> support (at least receiving) RTT correction and ids are not OPTIONAL >> and MUST be included on the correction RTT. >> Choice 2) You can implement 308 and 301 yet not support RTT >> correction - in which case supporting RTT correction is OPTIONAL, but >> if you do you MUST advertise appropriate disco features and MUST >> include ids etc. > > > [Comment & Question] > If you implement 308 and 301, you can still do RTT correction without the > 'id'. The main difference is that the real-time text will show up where the > new message normally is (i.e. it becomes a copy of the previous message). I > explained this carefully in a long email a few days ago to the standards > mailing list -- this is because a Message Reset is done when switching > between messages, so the real-time mesage will still continue to function > even when doing RTT without the 'id' attributes. Right. I understand that it's going to mostly work. >> 4.5 - "the recipient can watch the sender" - this isn't quite right >> (similar to previous comment). > > [Change Made] > I have replaced the word "watch" with "see", because "see" is compatible > with a software viewpoint. (interpreted as "The software sees the changes > to the message" even if the message is not displayed) -- To keep things > simple for a wider variety of readers, I prefer terms that are both > human-compatible and machine-compatible, and seems acceptable in both > Merriam-Webster dictionary (meaning 2b, 3c) and Oxford dictionary (meaning > 2) My point, although this is being word-picky, was that what you're seeing is the message being constructed, not the sender constructing the message (i.e. you do not see the sender, only the message). >> 4.5.1 - I think this has been commented on elsewhere, but using >> 'characters' here seems to be less clear than talking about code >> points. I understand the desire to mask implementers from needing >> exposure to code points, but I don't think that's going to ultimately >> help uptake or interoperability. > > > [Comment] > Further discussion is welcome. In the definition of Character, do we now say both Unicode Character and Code Point, and make clear that these are the same thing? This would seem helpful, if not. /K
