On Fri, Jul 27, 2012 at 5:50 AM, Kevin Smith <ke...@kismith.co.uk> wrote: > I think 'real time text' is a less contentious term than 'real > Jabber', I'd feel a bit happier with a link there instead.
[Change Made] It now links to realtimetext.org instead of realjabber.org There's already an old animation there; it'll do for now -- so I've made the change immediately. I will be creating a new generic animation for it, within a reasonable amount of time, so I'll probably be submitting a draft redone cover page for R3TF sometime in the near future. >>> "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. [Comment] In the subsequent sentence in the spec document, It already says you should be randomizing to a small number (e.g. we're nowhere near maximum integer), so wraparounds won't be happening either. So we're getting the best of both worlds. Also, for simultaneous logins in MUC, the full JID may not even exist, and there may not be <thread/> either. Resetting to 0 will then cause message corruption far more often than simply letting it continue to increment, or even better, randomizing. Therefore, resetting to 0 is not an acceptable recommendation, even if it will generally work in any implementation. Any other ideas / comments? I think it's not a high priority during LC, because I do say that any seq value can be used, just that randomizing is the best practice here. More field testing would seem to be required. It is worded in a way so that changing the standard of resetting seq in the future, will not break compatibility. So I think the randomization can stay for LC -- unless there's a superior idea (robust and simple for implementers) > 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. [Comment] Full JID may not be available in a MUC. Here, resetting to 0 potentially becomes a major problem. I could REQUIRE senders to send <thread/> and recipients to distinguish by <thread/>, but I feel that is a more onerous requirement than simply recommending randomizing seq. >>> "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. [Comment] (c/NOT required/NOT REQUIRED/) Basic Real-Time Text allows you to transmit message changes via Message Reset, so there are situations where you're always using an 'event' attribute for all <rtt/> elements. How can the wording be tweaked, so that circumstance is accomodated for? >> [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. [Comment] Some implementers will also put the real-time message in a separate pane, pop-up balloon, or something outside of the lineage of the message history. So for such implementations, the 'id' attribute matters less for these situations. > 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. [Change Made] I've now added this clarification to Summary of Attribute Values I'm expecting to submit 0.6 by end of today (or tomorrow at latest). Thanks Mark Rejhon
