[Standards] XEP-0301 0.5 comments [Sections 1 through 5]
gunnar.hellstrom at omnitor.se
Fri Jul 27 17:58:30 UTC 2012
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
>>> [Comment & Question]
>>> I agree, but I don't think it is worthwhile cluttering it by explaining
>>> -- 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)
<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
>>> [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?
<GH> You can replace
"Theeventattribute MAY be omitted from the <rtt/> element during regular
real-time text transmission."
"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:
> I'm expecting to submit 0.6 by end of today (or tomorrow at latest).
> Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards