[Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Mark Rejhon markybox at gmail.com
Fri Jul 27 14:19:53 UTC 2012

On Fri, Jul 27, 2012 at 5:50 AM, Kevin Smith <kevin at 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.

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.

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

>>> "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.

(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.

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

> 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).

Mark Rejhon

More information about the Standards mailing list