On 2012-07-27 16:19, Mark Rejhon wrote:
"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)
<GH>I suggest a random start seq with 30 bits for each session..
"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?
<GH> You can replace
"Theeventattribute MAY be omitted from the <rtt/> element during regular
real-time text transmission."
with
"Theeventattribute is used in situations specified below."
( each value is then well equipped with MUST or MAY for its specific
situation, so it should be sufficient to use the informal "is used".)
[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.
<GH> I do not think it is a good habit to edit previous without
indicating it with an id= attribute.
I have a feeling that all kinds of strange mixups can occur. E.g. if an
application provides history for the rtt.
So, I am leaning towards not allowing edit last without support of id=.
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
<GH>I returned to the definitions in Unicode now, and think now that
"character" is too vague. Unicode has in its glossary 4 different
meanings of character, and some of them certainly can result in multiple
code points. So, I hope you have formulated something that very reliably
tells that we count code points.
Even this description is hard to evaluate the nomenclature from:
http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf#G2212
I'm expecting to submit 0.6 by end of today (or tomorrow at latest).
Thanks
Mark Rejhon
Good.
Gunnar
