[Standards] review of XEP-0301 [ event='reset']

Gunnar Hellström gunnar.hellstrom at omnitor.se
Tue Aug 21 04:37:39 UTC 2012

On 2012-08-20 23:22, Mark Rejhon wrote:
> On Mon, Aug 20, 2012 at 5:13 PM, Gunnar Hellström
> <gunnar.hellstrom at omnitor.se> wrote:
>>>> That would include many <w/> elements.
>>>> If such a message refresh would be sent, it would take a long time to
>>>> display, with severe flicker as a result.
>>> That's right.  However, again, (1) it's not "enforceable", and (2) I
>>> don't want to confuse vendors about introducing a distinction (while
>>> legitimate), might lead to incompatible new/reset differences in some
>>> other implementations.  That is my fear.
>>> So that overrides a good reason to mention <w/> for reset, even though
>>> normally <w/> will never be used as the first element of a reset.
>>> So, I'm thinking of merging new/reset, once I hear Peter's response
>>> and some other responses from this mailing list.
>>>> Another (probably better) method would be to just recreate the resulting
>>>> text and send the retransmitted part as a single <t/> element, possibly
>>>> followed by new elements.
>>>> Therefore I think it is still valid to insert a sentence in 4.6.3
>>>> "When the sender composes the part of the refresh that has been
>>>> transmitted
>>>> before, <w/> elements shall not be included".
>>> If I do not merge new/reset, then I have a preference towards
>>> "Although there is no restriction on action element usage in
>>> new/reset, it is advisable that the first element of <rtt
>>> event='reset'/> is typically a <t/> whose purpose is to refresh the
>>> message."
>>> I'd rather say that sentence (or a improved derivative thereof).  It
>>> 100% perfectly meet time-smoothed needs, and you simply skip doing a
>>> time-smooth delay for the first <t/>.
>>> But give me a few days to test alternative protocol designs that
>>> resolves the confusion altogether, or alternative methods of wording
>>> the current protocol (using "Message Refresh" terminology instead of
>>> "Message Reset" terminology)
>>> Mark Rejhon
>> I do not at all mind if you settle the same rule for new as for reset. And I
>> do not mind if you merge them ( to a 'renew' ?)
>> I just wanted to make clear how the contents of the retransmitted part must
>> be composed for the refresh to work as intended.
>> Some implementers might get the impression that the event='new' or 'reset'
>> or 'renew' has some specific influence making the action elements read out
>> fast for the refresh action even if they include the old <w/> elements
>> already transmitted.
> Consider the scenario of when somebody immediately clears the
> whole buffer (e.g. select all text with mouse, then hits Delete, then
> starts typing), then the message reset starts shortly after.  There
> are many other edge cases that might cause a vendor to put legitimate
> <w/> elements at the start of a <rtt event='reset'/>  ...
> There is legitimate <w/> in this case because it's an intentional
> erased-message immediately followed by typing.   One can do an empty
> <t></t> to solve this problem of always expecting a <t> at the
> beginning of a reset, but I am not going to enforce it.  Implementer
> software should be designed to be able to handle all possible orders
> of action elements in <rtt/> ... I don't want to enforce anything
> beyond the most important item below:
> Anti-flickering is encouraged by, potentially adding this paragraph:
>   "Although there is no restriction on action element usage in
> new/reset, it is advisable that the first element of <rtt
> event='reset'/> is typically a <t/> whose purpose is to refresh the
> message.   In addition, all action elements at the beginning of <rtt/>
> containing either <rtt event='new'/> or <rtt event'='reset'/> must be
> processed immediately (up to the first Wait Interval, if any) after
> the moment of clearing the real-time message (as specified by event
> attributes of new or reset).  This is to prevent the flickering of a
> blank message in either situation, during regular [[[Message
> Refresh]]]"
> I don't want to introduce potential confusion so that specific
> implementations might cause problems or fail if they receive
> unexpected elements at the beginning of <rtt/>.  That's why I really
> explicitly mean that new/reset is exactly the same logically, and I
> don't want to define special behaviours other than the "immediate
> instant playback after clear" -- which is the only important thing
> that needs to be defined, that is currently missing, especially if I
> don't merge new/reset.
> Your suggested explanation would clear up your confusion, but would
> introduce new confusions for others about the distinction of
> new/reset. I am testing an alternate protocol that merges reset/new,
> but I might keep them separate -- I need some time to think about how
> to mitigate the risk of developers implementing incompatible
> behaviours for new vs. reset.  I'd rather come up with an
> _enforceable_ protocol, but ordering of action elemements is not
> _enforceable_ and there's no reason why it should be enforceable -- it
> should be able to gracefully continue, no matter what action element
> is the first action element of event=new/reset.
> Mark Rejhon
Mark, we are arguing for the exact same rules and behavior, so you can 
go ahead and propose text in next version and regard this issue solved.


More information about the Standards mailing list