[Standards] XEP-0301 Real-time text feedback response

[Gunnar Hellstrom]

Version 0.11 of XEP-0301 is published and available at
http://xmpp.org/extensions/xep-0301.html

*This version is intended to contain changes corresponding to Kevin's 
last call feedback from July, 2.

*
Comments and answers #1-#6 have been submitted before, but are included 
here to make the list of changes from version 0.10 complete.
By this we regard all comments received so far during the last call 
period to be handled.

The comments and answers are the following:


COMMENT #1:
6.4.4 -- seq numbers in example are not in sequence. Why?

ANSWER #1
Need to reference section 4.3 to remind reader:
ADD just after table:
"Note: The seq attribute can be restarted at any value with event='reset'/> and . See [[[Processing Rules]]]."



COMMENT #2:
4.8.2 -- Kevin said "In addition, XML character entities are counted as 
a single character." is redundant.


ANSWER #2
It is already mentioned in "including entities converted to characters)" 
in a subsequent paragraph.  The latter mention alone, is sufficient.
DELETE: "In addition, XML character entities are counted as a single 
character."



COMMENT #3:
4.7 Bare JID handling may not be clear why it is simpler.  Also, Kevin 
said "I think that some of the earlier instructions will be incompatible 
with having multiple RTT messages per full-JID. It would be worth 
someone else checking."


ANSWER #3
The paragraph had several weaknesses, so the paragraph has been reworded 
in several places.
-- Remove "For implementation simplicity" phrase.  There are good 
reasons why it was preferred by both RealJabber client and the TAP 
client, but it may not be a good idea to universally have this phrase.
-- Change "sender" to "contact" for consistency with RFC6121 in using 
"contact" towards bare JID / full JID / thread terminology.
-- Mention use case of only one typist per contact, as a clarifying 
rationale.

-- Word the last sentence in a more similar way to the second sentence.

CHANGE:
FROM: "Recipient clients MUST keep track of separate real-time messages 
on a per-sender basis, including tracking independent seq 
 values. For 
implementation simplicity, recipient clients MAY track incoming  
elements per bare JID  
 to keep only one real-time message per 
sender. Recipient client handling of conflicting  elements (e.g. 
coming concurrently from separate Simultaneous Logins 
) is 
described in the remainder of this section. Alternatively, recipient 
clients MAY keep track of separate real-time messages per full JID 
 
and/or per  (Best 
Practices for Message Threads 
 [9 
])."


INTO: "Recipient clients MUST keep track of separate real-time messages 
on a per-contact basis, including tracking independent 
/[[[seq]]]/ values. Recipient clients MAY track incoming  elements 
per bare JID   to 
keep only one real-time message per contact. The remainder of this 
section automatically handles conflicting  elements (e.g. typing 
coming concurrently from separate [[[Simultaneous Logins]]], contrary to 
the common case of one typist per contact). Alternatively, recipient 
clients MAY track incoming  elements per full JID 
 
and/or per , to keep 
multiple separate real-time messages for the same contact.  For more 
information about , see Best Practices for Message Threads 
 [9 
]."



COMMENT #4:
4.7.3 -- Decouple two conformance requirements. (A) Requirement of
regularity of transmission versus the size of the transmission
interval, and (B) clearly indicating that the 10 seconds is a default.

ANSWER #4:

CHANGE: "The message refresh SHOULD be transmitted regularly at an
average interval of 10 seconds during active typing or composing. This
interval is frequent enough to minimize user waiting time, while being
infrequent enough to not cause a significant bandwidth overhead. This
interval MAY vary, or be set to a longer time period, in order to
reduce average bandwidth (e.g. long messages, infrequent or minor
message changes)."

INTO: "The message refresh SHOULD be transmitted at intervals during active
 typing or composing. The RECOMMENDED interval is 10 seconds. This 
interval is frequent

 enough to minimize user waiting time during out-of-sync conditions,
while being infrequent enough to not cause a significant bandwidth 
overhead.
The interval can be varied, or be set to a longer time period, when so 
needed
to reduce average bandwidth (e.g. in case of long messages, infrequent 
or minor

message changes).
___

COMMENT #5:
10.1 Some clients pop up chat windows when incoming messages are
received - This may not be appropriate to enab

Re: [Standards] 301 feedback part1

[Gunnar Hellstrom]

On 2013-07-07 19:50, Mark Rejhon wrote:

Regarding XEP-0301 --
http://www.xmpp.org/extensions/xep-0301.html
Totally agree with the vast majority of Gunnar's answers.  Just some 
very minor tweaks needed.



On Sun, Jul 7, 2013 at 1:31 PM, Gunnar Hellstrom 
mailto:gunnar.hellst...@omnitor.se>> wrote:


ADD just before table:


For consistency, the text may need to be added afterwards the table 
(other parts of XEP-0301 put such table-describing text afterwards)
No problem, just make sure that the reader sees it before starting to 
wonder why the seq are not in sequence in this example.


COMMENT #4
4.7 "Alternatively, recipient clients MAY keep track of separate
real-time messages
per full JID 
<mailto:localp...@domain.tld/resource> and/or per  (Best
Practices for Message Threads [9])."
I think that some of the earlier instructions will be incompatible
with having multiple RTT messages per full-JID.
It would be worth someone else checking.

ANSWER #4
The sentence may be confusing, it is only when multiple threads
are used that multiple real-time messages
per full JID are needed.

CHANGE:  "Alternatively, recipient clients MAY keep track of
separate real-time messages
per full JID 
<mailto:localp...@domain.tld/resource> and/or per  (Best
Practices for Message Threads [9])."

INTO:  "Alternatively, recipient clients MAY keep track of one
real-time message per full JID 
<mailto:localp...@domain.tld/resource> or
one per full JID and thread if threads are used. See (Best
Practices for Message Threads [9])."


Let's discuss this a bit further with Kevin:
This type of wording change may not be sufficient.
There are these theoretical situations:
1. bare JID handling, ignoring  (execting 4.7 out-of-sync 
handling on any collisions)
2. bare JID handling, interpreting  (execting 4.7 
out-of-sync handling on conflicting full JID's)
3. full JID handling, ignoring  (execting 4.7 
out-of-sync handling on conflicting )

4. full JID handling, separate 

XEP-0301 would work fine with all the above scenarios.  The user 
experience would vary, but none of the scenarios would make XEP-0301 
unusuable because, in principle, there's typically only one typist 
coming from bare JID.  The major usability divergences do begins to 
occur when multiple typists start to use the same account (e.g. a wife 
and a spouse sharing the same Jabber login).  In this event, the 
out-of-sync handling behaviour differences become apparent (Simple 
worst case scenario: Thrashing of real-time text from one buffer to 
the other buffer in a once-every-10-second cycle, in the rare 
situation of simultaneous typists.  But when hitting Enter, the two 
separate messages will still successfully be delivered)


Now, as both me and Chris has expressed that we should leave it to the 
implementer to decide how it handled -- e.g. decide on what handling 
to do that allows simplification of implementation to just 
"one-real-time-buffer-per-chat" -- then I would prefer it that way, as 
typical scenario (>99% of use cases) is one active typist per bare JID 
(e.g. simply switching between devices) and all 1/2/3/4 works just 
fine in that scenario in a very interoperable manner; it's mostly a UX 
variance.  The implementor does not have to merge window handling and 
real-time-message-buffer handling, but the option is easily there, if 
the implementer shall choose to do so; to simplify & improve UX.


Obviously, MUC would require support for multiple real time message 
buffers per window, and thus would make it fairly easy to handle (4). 
 But not all clients want to support MUC, and thus would be quite a 
lot simpler (multiple implementers agree with me) for such clients to 
just follow (1).   As a result, I want to word things in a way that 
allows the implementer to decide what is easiest;


Thanks!
Mark Rejhon
My proposal did not aim at explaining lower number of real-time 
messages. It aimed at what I thought was Kev's question.  "having 
multiple RTT messages per full-JID". So,
I inserted the explanation that it was only when there are multiple 
threads per full JID that you MAY want to use one real-time message per 
thread and therefore more than one for the full JID.


Kev, was that your question?

Thanks,

Gunnar

Re: [Standards] 301 feedback part1

[Gunnar Hellstrom]

Kevin and all,

We are glad to get a prolonged Last Call on XEP-0301 to get a chance 
handle Kevin's questions.
A first set of answers to your questions, and proposals for 
corresponding edits are provided here.

They relate to
http://xmpp.org/extensions/xep-0301.html

The set provided now are the simple ones resulting in minor modifications.

Answers on two more questions ( #7 and #8 ) are forthcoming, with 
answers on the normative-related discussion related to sections 4.2.2 
and 6.2.1.


_


COMMENT #1:
6.4.4 -- seq numbers in example are not in sequence. Why?
ANSWER #1
Need to reference section 4.3 to remind reader:

ADD just before table:

"Note: The seq values are not in sequence in this example because all 
messages contain event 'new' or 'reset' and section
Section [[4.3 Processing Rules]] allows  andevent='reset'/> to restart seq numbering at any value."



COMMENT #2:
4.8.2 -- Kevin said "In addition, XML character entities are counted
as a single character." is redundant.

ANSWER #2
It is already mentioned in
"including entities converted to characters)" in a subsequent
paragraph.  The latter mention alone, is sufficient.

DELETE: "In addition, XML character entities are counted as a single 
character."


COMMENT #3:
4.7 Bare JID handling may not be clear why it is simpler.

ANSWER #3
 There are good reasons why it was preferred by both RealJabber client 
and the TAP

client, but it may not be a good idea to universally have the phrase "For
implementation simplicity".

CHANGE:
FROM: "For implementation simplicity, recipient clients MAY track
incoming  elements per bare JID  to keep
only one real-time message per sender"

INTO: "Recipient clients MAY track incoming  elements per bare
JID  to keep only one real-time message per
sender. (Also see 6.6.4.2 Simultaneous Logins)."


COMMENT #4
4.7 "Alternatively, recipient clients MAY keep track of separate 
real-time messages
per full JID  and/or per  (Best 
Practices for Message Threads [9])."
I think that some of the earlier instructions will be incompatible with 
having multiple RTT messages per full-JID.

It would be worth someone else checking.

ANSWER #4
The sentence may be confusing, it is only when multiple threads are used 
that multiple real-time messages

per full JID are needed.

CHANGE:  "Alternatively, recipient clients MAY keep track of separate 
real-time messages
per full JID  and/or per  (Best 
Practices for Message Threads [9])."


INTO:  "Alternatively, recipient clients MAY keep track of one real-time 
message per full JID  or
one per full JID and thread if threads are used. See (Best Practices for 
Message Threads [9])."


COMMENT #5:
4.7.3 -- Decouple two conformance requirements. (A) Requirement of
regularity of transmission versus the size of the transmission
interval, and (B) clearly indicating that the 10 seconds is a default.

ANSWER #5:

CHANGE: "The message refresh SHOULD be transmitted regularly at an
average interval of 10 seconds during active typing or composing. This
interval is frequent enough to minimize user waiting time, while being
infrequent enough to not cause a significant bandwidth overhead. This
interval MAY vary, or be set to a longer time period, in order to
reduce average bandwidth (e.g. long messages, infrequent or minor
message changes)."

INTO: "The message refresh SHOULD be transmitted during active
 typing or composing. It is RECOMMENDED to transmit the message
refresh at regular intervals of 10 seconds. This interval is frequent
 enough to minimize user waiting time during out-of-sync conditions,
while being infrequent enough to not cause a significant bandwidth 
overhead.
The interval can be varied, or be set to a longer time period, when so 
needed
to reduce average bandwidth (e.g. in case of long messages, infrequent 
or minor

message changes).



COMMENT #6:
10.1 Some clients pop up chat windows when incoming messages are
received - This may not be appropriate to enable RTT right away upon popup.

ANSWER #6
CHANGE:
FROM: "With real-time message editing, recipients can watch all text
changes that occur in the sender's text, before the sender finishes
the message."
INTO: "There can also be implications for chat clients that suddenly
pop up a chat window upon incoming messages and take focus, as the 
sender can

unexpectedly start typing sensitive information into the wrong window.
Such risks should be avoided by good UI design. They are also apparent
 for traditional chat but are more obvious for real-time
 text because with real-time message editing,
recipients can watch all text changes that occur in the
sender's text, before the sender finishes the message."

--
COMMENTS NOT YET ANSWERED

COMMENT #7
 4.2.2 - I'm aware than we've had debates in the past about how much 
needs to be MTI.
As things currently stand, the XEP is fairly clear and straightforward, 
and I wonder
 if making all of these MTI would be much of an imposition on 

Re: [Standards] 301 feedback

[Gunnar Hellstrom]

On 2013-07-02 20:28, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/2/13 11:46 AM, Mark Rejhon wrote:

On Tue, Jul 2, 2013 at 12:23 PM, Kevin Smith mailto:ke...@kismith.co.uk>> wrote:

4.2.2  - I'm aware than we've had debates in the past about how
much needs to be MTI. As things currently stand, the XEP is fairly
clear and straightforward, and I wonder if making all of these MTI
would be


MTI?

MTI = "Mandatory to Implement"

I don't want to put words in his mouth, but I think Kev might be
wondering why guidelines that seem implementation-specific are
mandated in the specification, since it could be argued that they are
not critical from a protocol perspective and relate more to user
experience than to network communication.

I have another set of words to put in Kev's mouth.

I think Kev meant that all shall be required to support.
In a straightforward protocol, having options just increases risks for 
malfunctions and interop problems.


On recipient side it might be a good idea, but mandating support on 
sender side does not make sense.

Some specific applications simply do not need to send all these.

I hope Kev can explain now which interpretation was right.

Gunnar



Peter

- -- 
Peter Saint-Andre

https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR0xu9AAoJEOoGpJErxa2pFloQAIQzQ83vaDov7lyhn33dWkmx
G60I+YsndpRBY87j0zdOSoRxK4TiUea5+JtAeptuo97gTlL4NqM78qtmUf9PDvGj
hCL8VQ4Odsy7iBw1vd2rwTgBeCWRK+VES+d+0QZ2+EOyT+schQv+YITaDbKsEoNf
zUHWOILRaOrUIc9OJ6prIoQBmKw8WqKBDn8PmKmGBlnWrMBr6kpGMICSCheBrnlN
rL0OpY4kZDMtXySsqYbSK9kAAD1RdmOMtpRNme5Mh/gSlbiBUllFhDu1oZ7tPElO
Os5vj6kSvhAjg4nkgERDN/XnYUb8uZTC0avTD4LrEAB/iaguidwhJJ6MdE4rdvhF
gOAzTMDiGCWG6GiOrxnzouVfoAv0uTmhiV2ZkKGbl9ADtFC3fpUPWeTCnGU1tFVr
BBHMdNNnkmU/O9Iyus03MLmtlJ0YReD59vInQxhcJdhLb4Vmo2f52pUaLQbOfbZO
c5Zu8W+uPtNm7Go/uELpEgvgZOIToBqMacvK1Wym4XRAoDKBdtqiwYxcr6JXRqf/
V58L4CQ1qXH7I4JvQlZh4A4tgtMqJ6d0KmA0TrDuDb8x0v/83CXHz0SbQfYxWDV2
VZOBlo6hG6gMf9paQtHSMU1MgYRyJjL9r/THdb7NMp8xSVkVV9skybHDI6918yNg
9yEaJC5Y5H6Sp9lAY16E
=5xTv
-END PGP SIGNATURE-

Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)

[Gunnar Hellstrom]

On 2013-05-28 22:30, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0301 
(In-Band Real Time Text).

Abstract: This is a specification for real-time text transmitted in-band over 
an XMPP session.
   Real-time text is text transmitted instantly while it is being typed or
   created.

URL: http://xmpp.org/extensions/xep-0301.html

This Last Call begins today and shall end at the close of business on 
2013-06-28.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:
Being a co-author, I feel that I should anyway express my view of this 
specification.

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?

Yes, it fills a gap.

2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes.

3. Do you plan to implement this specification in your code? If not, why not?

Yes.

4. Do you have any security concerns related to this specification?

No.
We are just asked to explain better a security related question on 
transmission timing attacks, placed by Peter Saint-Andre. It has a 
positive answer.

5. Is the specification accurate and clearly written?

Yes.


Your feedback is appreciated!
I am glad to be part of this work initiated by Mark Rejhon. I think it 
contributes in a good way to usability enhancement of XMPP.


Regards
Gunnar Hellström
Omnitor

Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)

[Gunnar Hellstrom]

Peter,

On 2013-06-05 04:34, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/28/13 2:30 PM, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on
XEP-0301 (In-Band Real Time Text).

Abstract: This is a specification for real-time text transmitted
in-band over an XMPP session. Real-time text is text transmitted
instantly while it is being typed or created.

URL: http://xmpp.org/extensions/xep-0301.html

This Last Call begins today and shall end at the close of business
on 2013-06-28.

Please consider the following questions during this Last Call and
send your feedback to the standards@xmpp.org discussion list:

I have one additional question: do both of the authors (re-)affirm
that they are contributing this specification in conformance with the
XSF's IPR Policy?

http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/

Yes, confirmed.


In addition, are the authors personally aware of any patents over
their contribution, whether those patents might be held or applied for
by the authors or any other persons or organizations they know of?

No.

Regards

Gunnar

Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)

[Gunnar Hellstrom]

On 2013-05-20 00:52, Peter Saint-Andre wrote:

On 5/19/13 7:51 AM, Edward Tie wrote:

Mark,

It's done and ready for LAST CALL .

Yes, I've already brought that to the attention of the XMPP Council,
which is next meeting this Wednesday.

Good.
The issues in version 0.8 discussed in the list are solved.
The existence of two well interoperating implementations in different 
technologies is a good extra indication of the maturity and 
implementability.


/Gunnar


Peter

Re: [Standards] XEP-0301: Javascript implementation of in-band real-time text

[Gunnar Hellstrom]

On 2013-04-23 05:50, Mark Rejhon wrote:
On Mon, Apr 22, 2013 at 10:06 PM, Christian Vogler 
> wrote:


the Technology Access Program at Gallaudet University is pleased to
announce a Javascript implementation of XEP-0301 in-band real-time
text. It is available for hands-on testing at
http://tap.gallaudet.edu/rtt/


Chris,
Thanks so much for your hard work in implementing the XEP-0301 
specification!
It is far by the easiest way to demo real-time text -- working on all 
smartphones, tablets, and computers running modern web browsers 
(HTML5/AJAX).


I agree. It is very good to have the two openly available independent 
implementations of XEP-0301.

I have run brief interop tests that they pass very well.

Thanks Christian.

/Gunnar

Re: [Standards] XEP-0301 (In-Band Real Time Text) - review observations

[Gunnar Hellstrom]

On 2013-04-20 17:09, Christian Vogler wrote:

Mark,

can you describe exactly how the link to Section 6.5 solves the 
problem of  interval backlog? The last version I saw made Section 
6.5 look like a suggestion (clients "can" ), rather than something 
that is mandatory. I might not be up to date with respect to the most 
recent changelog there - but based on experience I now believe that 
implementing it has to be mandatory, rather than optional.


In order to avoid both jerky playout and excessive delay, I want to 
propose the algorithm for catch up  in 6.5 to be changed from
"Recipients can avoid excess lag by monitoring the queue for excess  
action elements (e.g. unprocessed  elements from two  elements 
ago) and then ignoring or shortening the intervals in  elements."


"Recipients can avoid excess lag by monitoring the queue for unprocessed 
 action elements from more than one  elements, and then 
shortening the intervals in  elements so that the sum equals the sum 
of  elements in the latest  element."



I think that is the best way to handle jitter in a smooth way.

6.5 is not mandatory, so it would be interesting to see how well it is 
encouraged from section 4.


Gunnar



Christian


On Thu, Apr 18, 2013 at 6:57 PM, Mark Rejhon > wrote:


Addendum:

On Thu, Apr 18, 2013 at 6:39 PM, Mark Rejhon mailto:marky...@gmail.com>> wrote:

*WORTHY -- BUT POSTPONE TO 2014*
It makes a lot of sense but I'm going to postpone this change
for now, because of unanticipated side effects of minor
wording tweaks.
Both me and Chris treat  intervals accumulating on a system
time since the beginning of , so slow local performance
doesn't cause  to


Incomplete sentence noticed; completing it as:

Both me and Chris treat  intervals accumulating on a system
time since the beginning of , so slow local performance
doesn't cause  to cause a backlog.   Even if it did cause a
backlog, handling for backlogged  (which is the bigger
problem and chief cause of lag), that is already written in the
spec (with improved wording), can already adequately handle this
scenario in XEP-0301 clients that used a "wait since last action
element" methodology."

In other words, the problem is already indirectly solved by the
Version 0.8 of XEP-0301 (existing section 6.5)




--
Christian Vogler, PhD
Director, Technology Access Program
Department of Communication Studies
SLCC 1116
Gallaudet University
http://tap.gallaudet.edu/
VP: 202-250-2795

Re: [Standards] XEP-0301 (In-Band Real Time Text) - review observations

[Gunnar Hellstrom]

On 2013-04-19 10:16, Kevin Smith wrote:

On Fri, Apr 19, 2013 at 9:03 AM, Gunnar Hellstrom
 wrote:

We are clearly down
to issues where it would be better to take it through last call.

Ignoring everything else as I've not found time to read the thread
yet, I'll point out that up until LC the authors are free to edit the
document as they please - this stops being true once it's been LCd.
For it to get to Draft it's going to need to have the open issues
cleared up (i.e. knowing there are open issues and "We're intending
further developing it in 2014" is a reason to not send it to Draft
IMO), and once Draft all changes have to go through Council. Changes
/can/ be made to Draft XEPs, but other than tidying of things found in
deployment it needs to by and large remain the same.

I agree completely.
I meant:

We are clearly down
to issues where it would be better to*/stop raising these minor issues and 
instead/  *take it through last call.

Thanks,

/Gunnar


/K

Re: [Standards] XEP-0301 (In-Band Real Time Text) - review observations

[Gunnar Hellstrom]

On 2013-04-19 00:39, Mark Rejhon wrote:

Gunnar, see the bottom of this message for a positive surprise
Thank you for the honour, much appreciated to be even more part of this 
important improvement of communication opportunities.


Firstly, I want to stress the importance of minimum changes.
I already privately emailed to XSF team and would prefer to submit 
Version 0.9 with *almost NO CHANGE*.
Submitting 0.9 with many changes will automatically break my promise 
and *will reduce the likelihood of last call approval.*
Agreed. The new items I included are results of a review. I wanted to 
report them, but I agree that they are of a kind and on a level that can 
be left without action.
I dont like saving things for a 2014 update. It is so much harder to get 
a good effect of additions to a protocol when you already have an 
installed park. But we can after discussion deem some not sufficiently 
important to allow modification of the document now, or not mature enough.



On Thu, Apr 18, 2013 at 5:53 PM, Gunnar Hellstrom 
mailto:gunnar.hellst...@omnitor.se>> wrote:


7.
 Section 4.2.1 or 4.3 last bullet.
Insert:
"NOTE: Wrap-around may occur when incrementing  if the
randomly selected start value was close to the upper border of
. "
NOT DONE


I am against adding too much text about seq without removing other 
text about seq *in the "Protocol" section*.   I think we already talk 
too much about trivial seq issues right now as-is.  One idea is that I 
can delete most of the seq text and create a much bigger seq section 
in the "*Implementation Notes*" section.   The simple sentence about 
the 31-bit bounds is currently sufficient (maybe a minor sentence 
tweak if necessary), we know that properly following "*Keeping 
Real-Time Text Synchronized*" indicates clients MUST not assume 
incrementing seq values will always happen, so it already successfully 
catches seq going backwards in time, which is exactly the wraparound 
condition too, unless both ends do the wrap properly.


In addition to my preference, XSF has already complained that we are 
already too much like a lower-layer protocol.  Expanding the talk 
about *seq* is against this goal, especially as the safeguards are 
already sufficient now, in my opinion.
The only acceptable reason to not put this in is that we agree that 
programmers are so well aware of handling incrementing sequence numbers 
with upper bounds and risk for wrap around that it is safe to not 
mention the risk.


The reasoning that if handling wrap around is wrongly programmed, then 
it only halts presentation of text until the message is complete or a 
new REFRESH is received is not sufficient reasoning for not entering the 
note.


So, what is the habit in this environment? Do we trust programmers to 
remember the wrap-around case? If so, we may leave it out.
Please do not change and move text just because of this. It is only a 
one line note I ask for.



9.
Section 4.6.3.3 Insert
"Recipients SHALL avoid excess lag by monitoring the queue for
excess  action elements (e.g. unprocessed  elements from
two  elements ago) and then ignoring or shortening the
intervals from the  elements. This allows lagged real-time
text to "catch up" quickly."
( consider removing or reword the similar sentence from 6.5 so
that we do not have repetitions )
NOT DONE


*DONE (indirectly)*
What I did was simply make 4.6.3.3 link to section 6.5.
I did the change in a different way.  It's a good change.  It is not 
an interoperability issue that belongs in the Protocol section (*I am 
_extremely_ adamant to keep Section 4 as compact as I can, and 
additionally also have been previously told by XSF to also keep 
Section 4 "Protocol" as simple as possible.*).
This is an important performance issue. If the means for catch up 
described in 6.5 are not implemented, then delay of one  message 
will proliferate through a complete sequence of continous typing. Since 
chapter 6 is not supposed to have SHALLs, I suggested to move this to 
chapter 4.
But of course, chapter 6 contains a lot of good advice that we can 
expect implementors to follow. So if you have put in a pointer from 
4.6.3.3 to 6.5 and sharpened up the wording in 6.5 it can be sufficient.


The actions against proliferating delays described in 6.5 should in fact 
be developed into a smooth adaptive jitter buffer algorithm, that 
results in low delays and small jerkiness at late delivery of an  
element, rather than a constant longer delay and always true 
reproduction of key press intervals. That can be done within the frames 
allowed by 6.5.


In summary: I accept your proposal.



10. Is there a risk for delay introduced in the description of  ?
   In beginning of 4.6.3.3 it is said that  represent time
between key presses.
  in 6.1.2 it says that  represent wait between Action

[Standards] XEP-0301 (In-Band Real Time Text) - review observations

[Gunnar Hellstrom]

Here is a summary of changes from XEP-0301 version 0.8, some done in 
Mark's own 0.9 draft, marked "DONE".
I do not remember what has been discussed in the list and not, so here 
are all points, some still under discussion.

http://xmpp.org/extensions/xep-0301.html


1.
Section 4.2.1:
- Move "The bounds of seq is 31-bits, the range of positive values for a 
signed 32-bit integer." from section 4.3 to section 4.2.1.

DONE

2.
Section 4.6.3.2 :
- Change: "Excess backspaces MUST be ignored."
- To: "Excess backspaces MUST be ignored by the receiving client."
DONE

3.
Section 6.2.2:
- Fix a link error
DONE

4.
Section 6.5:
- Change: "Recipients can avoid excess lag by monitoring the queue for 
excess  action elements (e.g. unprocessed  elements from two 
 elements ago) and then ignoring or shortening the intervals in 
 elements. "
- To: "Recipients can avoid excess sustained lag by monitoring the queue 
for excess  action elements (e.g. unprocessed  elements from 
more than one  element before the latest received) and then 
ignoring or shortening the intervals in  elements."

DONE

5.
Section 6.5:
- Demote bullet 3 into a separate paragraph later into the section:
"Upon receiving a [[[Body Element]]] indicating a completed message, it 
is acceptable for the full message text from  to be displayed 
immediately in place of the real-time message, and discard any 
unprocessed action elements. This prevents any delay in displaying the 
final message delivery, however, this may cause a sudden surge of text 
in some situations."

DONE

6.
Section 10.3:
- Fix a link error
DONE

7.
 Section 4.2.1 or 4.3 last bullet.
Insert:
"NOTE: Wrap-around may occur when incrementing  if the randomly 
selected start value was close to the upper border of . "

NOT DONE

8.
Change SHOULD to MAY in 4.6.3.3 for  displaying body immediately.
DONE

9.
Section 4.6.3.3 Insert
"Recipients SHALL avoid excess lag by monitoring the queue for excess 
 action elements (e.g. unprocessed  elements from two  
elements ago) and then ignoring or shortening the intervals from the 
 elements. This allows lagged real-time text to "catch up" quickly."
( consider removing or reword the similar sentence from 6.5 so that we 
do not have repetitions )

NOT DONE

10. Is there a risk for delay introduced in the description of  ?
   In beginning of 4.6.3.3 it is said that  represent time between 
key presses.
  in 6.1.2 it says that  represent wait between Action Elements 
.
Assuming that key presses are momentary, but it takes some milliseconds 
to complete some action elements this will introduce on the receiving 
side a sum of waits and action element performance time that is more 
than the transmission interval. Thus, delays will be introduced during 
times of continous typing.

Do we need to be more concise with what time  represents?

Should 6.1.2 be modified to say Is it "wait from end of latest wait"  or 
"wait from beginning of execution of latest action element ?


In 4.6.6.3, it says:
"Wait n milliseconds before processing the next action element."
proposed to be changed to:
"Wait until n milliseconds after end of latest wait, before processing 
the next action element, or if this is the first  in the current 
real-time message, then wait until n milliseconds after beginning 
handling presentation of that real-time message ."


In 6.1.2 it says:
" This is achieved using Element  – Wait Interval 
 
between other Action Elements 
. Sender 
clients can transmit the length of pauses between key presses,"

proposed new wording:
"This is achieved using Element  – Wait Interval 
 from 
previous  or beginning of the current  element. Sender clients 
can transmit the length of pauses between key presses,"


FOR DISCUSSION



11. Should we improve chances of smooth and low latency playout by 
putting XEP-0203 timestamps on the messages as a guide to when it should 
be played out.


E.g. by inserting this sentence in 6.1.2.

"For more accurate timing of beginning of playout of each  
element, it is recommended to insert a time stamp on the  elements 
by use of XEP-0203 time stamping, and on the receiving side let this 
value control when playout of the element starts rather than timing it 
only from the  elements throughout the whole real-time message."


Then, a reference to XEP-0203 needs to be added as well.
FOR DISCUSSION



The not done and for discussion items are all minor.


Regards

Gunnar

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?

[Gunnar Hellstrom]

On 2013-04-12 14:08, Christian Vogler wrote:


I hope you mean:
- on the sender and receiver side I do modulo 2**31 arithmetic

- on the sender side I limit the maximum random sequence restart
number to 2**30.



actually yes, I do - but the difference between 2**31 and 2**30 is a 
cool billion, so wraparound really is never ever going to happen if 
the sender implements this strategy. Under these circumstances, doing 
modulo arithmetic is a mere precaution against clients that ignore 
this issue. I'm fine with specifying something re the wraparound in 
the standard, though - in fact, I would feel better if there were 
something.



Right, I agree, it is sufficient the way you state it.


-
Looking at how others have handled wrap around issues, I found this 
exotic but relevant statement in RFC 3550 RTP section 4 on NTP wrap around:


The NTP timestamp will wrap around to zero some time in the year 2036, 
but for RTP purposes, only differences between pairs of NTP timestamps 
are used. So long as the pairs of timestamps can be assumed to be within 
68 years of each other, using modular arithmetic for subtractions and 
comparisons makes the wraparound irrelevant.

--


So, we are in good company if we devote a few words to rare wrap-around 
issue prevention.


/Gunnar

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?

[Gunnar Hellstrom]

On 2013-04-12 01:41, Christian Vogler wrote:
One thing to remember, I think, is that individually the cases are 
going to be incredibly rare, but in the case of widespread adoption, 
these once-in-a-lifetime cases will pop up for *someone* out there on 
a frequent basis. While I agree that the worst thing that can happen 
is a 10-second pause, I don't see a compelling need to allow them to 
happen - and they will, even though most users will never see them - 
when preventing them is so simple. The purpose of RTT, in the first 
place, is not to have these kinds of delays.


I do two things to prevent this from happening:

- on the receiver side I do modulo 2**31 arithmetic
- on the sender side I limit the maximum random sequence restart 
number to 2**30.



I hope you mean:
- on the sender and receiver side I do modulo 2**31 arithmetic
- on the sender side I limit the maximum random sequence restart number 
to 2**30.


That seems to be a good conclusion from version 0.7 that you had at hand 
when you made your implementation.

---
I cannot find that we discussed and concluded in the list to delete the 
precaution for effects of wrap-around. Therefore I expected it to be 
included in v.0.8, and suggest that it is put in again.


/Gunnar




Christian


On Thu, Apr 11, 2013 at 7:14 PM, Mark Rejhon <mailto:marky...@gmail.com>> wrote:


Regarding:
http://xmpp.org/extensions/xep-0301.html


On Thu, Apr 11, 2013 at 4:45 PM, Gunnar Hellstrom
mailto:gunnar.hellst...@omnitor.se>>
wrote:
> On 2013-04-11 00:09, Gunnar Hellstrom wrote:
>> I remember that there was a discussion on the risk for wrap-over in
>> handling seq. Is the wording now in line with the outcome of
the discussion?
>> Was it acceptable as it is now, with no mentioning about the
risk for
>> wrap-around when incrementing seq. Maybe all implementors
should be wise
>> enough to handle wrap around properly. Or did the discussion
end up with the
>> conclusion that a requirement should be inserted about usual
handling of the
>> counter wrapping around?

Wraparound risk is so low:
(1) The damage of a seq wraparound is insignificant
(2) If both ends use the same seq wrapping bounds, both ends will
wraparound simultaneously and real time text continues;
(3) In the worst-case scenario (seq values diverges during wraparound)
section "Keeping Real Time Text Synchroized" will simply freeze the
text for 10 seconds until the next Message Refresh, at which point seq
gets re-initialized.
http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized
(4) It is unlikely that seq would be randomized very near the top
bounds of seq for a specific 10 second window, to cause another
wraparound.

IMHO, it is almost a waste of text to expand XEP-0301 any further for
something so harmless/rare as this.  Presently, a seq wraparound has
never ever happened in the history of XEP-0301 to the best of my
knowledge, and even when programmatically forced to do so, situation
(2) typically happens -- both ends wrap automatically from
2,147,483,647 directly to 0 simultaneously -- and the real-time text
continues synchronized.

Can anybody illustrate any use-cases why this discussion is important?


> It was handled in a mail of July 27, 2012, where you said about
text about
> the initial value on SEQ for section 4.2.1:
>
> I already say "Senders MAY limit the size of the new starting seq
> value, to keep  compact while allowing plenty of incrementing
> room without overflow." which already provides the umbrella for
this.
>
> I found no further change on this, so I think the sentence in" "
above
> should be in section 4.2.1

I have a better idea: I should move the sentence mentioning "The
bounds of seq are 31-bits, the range of positive values for a signed
32-bit integer."


It should be specified where seq itself is specified.



Wraparounds are completely harmless if proper wraparound is done, and
simply results in situation (2) if followed.  The additional talk is
simply "just in case" stuff in case the wraparound logic on both ends
is different, and even when the wraparound logic is
different/buggy/poorly done, the side effects are quite harmless, like
a "once-in-a-century" 10 second pause.


It was agreed in July and not discussed after that so it should stay in.



Thanks,
Mark Rejhon




--
Christian Vogler, PhD
Director, Technology Access Program
Department of Communication Studies
SLCC 1116
Gallaudet University
http://tap.gallaudet.edu/
VP: 202-250-2795

/Gunnar

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?

[Gunnar Hellstrom]

On 2013-04-11 00:09, Gunnar Hellstrom wrote:


I remember that there was a discussion on the risk for wrap-over in 
handling seq. Is the wording now in line with the outcome of the 
discussion?
Was it acceptable as it is now, with no mentioning about the risk for 
wrap-around when incrementing seq. Maybe all implementors should be 
wise enough to handle wrap around properly. Or did the discussion end 
up with the conclusion that a requirement should be inserted about 
usual handling of the counter wrapping around?


I found it.
It was handled in a mail of July 27, 2012, where you said about text 
about the initial value on SEQ for section 4.2.1:


I already say "Senders MAY limit the size of the new starting seq
value, to keep  compact while allowing plenty of incrementing
room without overflow." which already provides the umbrella for this.

I found no further change on this, so I think the sentence in" " above 
should be in section 4.2.1



Gunnar

[Standards] XEP-0301 (In-Band Real Time Text) contradicting information on smoothness

[Gunnar Hellstrom]

On 2013-04-08 17:47, XMPP Extensions Editor wrote:

Version 0.8 of XEP-0301 (In-Band Real Time Text) has been released.
URL: http://xmpp.org/extensions/xep-0301.html

There is a bit contradicting information on how to handle the  
element and smoothness of presentation.


In 6.1.2 Preserving key-press intervals, it is said:
"For high quality presentation of real-time text, the original 
look-and-feel of typing can be preserved independently of the 
transmission interval. This is achieved usingElement  -- Wait 
Interval 
between otherAction 
Elements ."


This gives an impression that it is important to provide this 
look-and-feel of typing.


But in 4.6.3.3   Wait interval, it is said:
"Upon receiving aBody Element 
, recipient 
clients SHOULD interrupt all pending pauses for the current real-time 
message, in order to prevent a delay in displaying the final message."   
A similar instruction is found in 6.5 point 3.


This instruction introduces a risk that many times, the end of a message 
is presented in a jerky fashion, suddenly abandoning all smoothness. 
There may up to 1.4 seconds of buffered typing, ( but more often between 
0 and 700 ms ) that 6.1.2 instructs to show immediately.


I think the sentences in 4.6.3.3 and 6.5 point 3 should be deleted, and 
let smooth presentation continue until end of message. The reader is 
anyway way ahead of any reader not having real-time text, who had 
nothing at all to read while the sender composed the message.


I have reacted a couple of times about the jerks at end of message. What 
is your experience?


Gunnar

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?

[Gunnar Hellstrom]

On Mon, Apr 8, 2013 at 11:47 AM, XMPP Extensions Editor > wrote:


Version 0.8 of XEP-0301 (In-Band Real Time Text) has been released.
Abstract: This is a specification for real-time text transmitted
in-band over an XMPP session.
  Real-time text is text transmitted instantly while it is being
typed or created.

URL: http://xmpp.org/extensions/xep-0301.html


I would like people's opinion on the brand new "4.3 Processing Rules" 
section:

http://xmpp.org/extensions/xep-0301.html#processing_rules

It actually significantly shortened/simplified the "4.2 RTT 
Attributes" section

http://xmpp.org/extensions/xep-0301.html#rtt_attributes
It recently helped some implementers (including one from Gallaudet 
University who just joined this mailing list).


On the other hand, parts of it feels somewhat redundant to some text 
already in "4.7 Keeping Real-Time Text Synchronized"
http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized 



Comments?

Initially it looks good with the new 4.3..

But there is at least one case where it has introduced an unfavorable 
distribution of information where I think it was better concentrated in 
version 0.7.


That is for the seq attribute.

It is defined in 4.2.1

But in this version you moved part of the definition, its range, to 4.3.

I think that makes it harder to find all required fact about 
implementation of the attribute seq.


At least the last sentence of the seq paragraph in 4.3 was better placed 
in 4.2.1 where it could be located by browsing the contents if you were 
interested in rules for the seq attribute.



I remember that there was a discussion on the risk for wrap-over in 
handling seq. Is the wording now in line with the outcome of the discussion?
Was it acceptable as it is now, with no mentioning about the risk for 
wrap-around when incrementing seq. Maybe all implementors should be wise 
enough to handle wrap around properly. Or did the discussion end up with 
the conclusion that a requirement should be inserted about usual 
handling of the counter wrapping around?



Regards

Gunnar




Thanks,
Mark Rejhon

Re: [Standards] XEP-0301 (In-Band Real Time Text) v0.8 erasure and lag

[Gunnar Hellstrom]

On 2013-04-10 21:42, Mark Rejhon wrote:
On Tue, Apr 9, 2013 at 5:36 PM, Gunnar Hellstrom 
mailto:gunnar.hellst...@omnitor.se>> wrote:


Mark,
You must have thought that I proposed another change than I really
did for issue 1.
The only change I proposed was

--
In 4.6.3.2, change:
"Note: Excess backspaces MUST be ignored. Thus, text is backspaced
only to the beginning of the message, in situations where n is
larger than p."
to
"Note: Excess backspaces MUST be ignored by the receiving client.
Thus, text is backspaced only to the beginning of the message, in
situations where n is larger than p."

--



On the first read, it sounded like you wanted to make changes to XEP-0308.
After some more thought, this appears to be an acceptable change since 
no mention of 0308 is made, and this is true regardless of whether 
0308 is applied or not.


This specific change is good and has nothing contentious related to it.

Good, thanks.

/Gunnar


Thanks
Mark Rejhon

Re: [Standards] XEP-0301 (In-Band Real Time Text) v0.8 erasure and lag

[Gunnar Hellstrom]

Mark,
You must have thought that I proposed another change than I really did 
for issue 1.


The only change I proposed was
--
In 4.6.3.2, change:
"Note: Excess backspaces MUST be ignored. Thus, text is backspaced only 
to the beginning of the message, in situations where n is larger than p."

to
"Note: Excess backspaces MUST be ignored by the receiving client. Thus, 
text is backspaced only to the beginning of the message, in situations 
where n is larger than p."

--
This is a note just intended to remind developers of receiving clients 
to code for robustness. If the transmitting side happens to send more 
backspaces than there is message for, the excess shall be ignored by the 
receiver.


On the transmitting side the action on excess user backspaces depends on 
if XEP-0308 support is available of not. I suggest that nothing is added 
to describe what the transmitting side does when the user makes excess 
backspaces.


In reality, If XEP-0308 is supported and negotiated,  then section 6.6.3 
sufficiently describes what to do, and your view of what should be done 
is good:
For XEP-0308, senders should break a long backspace sequence into 
multiple , one for current message, and one for previous message. 
Since this is not ignoring excess backspaces, the note is false as it is 
and needs my adjustment to be valid only for receivers.


If XEP-0308 is not supported, and the transmitting user makes excess 
backspaces, then it is true that they should be ignored, but I do not 
want to complicate the sentence by including the different cases for the 
transmitter.


4.6.3.2 is too early to start discussing what to do when XEP-0308 is 
supported, and what to do when it is not, so I suggest instead just to 
be silent here about what transmitters should do with excess 
backspaces.  It is possible to compose a sentence on it but I do not 
think it is necessary. Agree?


Thanks for agreeing on issue 2 on excessive lag

Gunnar





On 2013-04-09 15:33, Mark Rejhon wrote:

Hello Gunnar,

Thanks for your comments about XEP-0301 In-Band Real-Time Text:


On Tue, Apr 9, 2013 at 2:02 AM, Gunnar Hellstrom 
mailto:gunnar.hellst...@omnitor.se>> wrote:


It is good to see a new version of the XMPP Real Time Text extension.

[snip]

On 2013-04-08 17:47, XMPP Extensions Editor wrote:

URL: http://xmpp.org/extensions/xep-0301.html

[/snip]


The general impression is that it is in a good and mature condition.
I have a couple of small comments.

1. Erasure over message border.
In 4.6.3.2, it is said about the Erase element:
"Note: Excess backspaces MUST be ignored. Thus, text is backspaced
only to the beginning of the message, in situations where n is
larger than p."
This can be perceived in three ways. Support of XEP-0308 for last
message correction may change the situation a bit.

1. Seen from the transmitting user perspective, with XEP-0308
support, backspacing over the message border may be the natural
way to return to the previous message and make a small correction.
Without XEP-0308 support, the statement is true.

2. Seen from the transmitting client perspective. If XEP-0308 is
supported, then a user backspace at the beginning of the message
should not be ignored, but instead activate last message
correction, providing a  and start acting in the previous
message. IF XEP-0308 is not supported, then the statement is true.

3. Seen from the receiving client perspective, the statement is
true. "Excess" backspaces shall be caught by the transmitting
client and either ignored or caused to generate the move to the
previous message before continuing to erase, depending on XEP-0308
support.

I suggest that the XEP-0308 influence is kept largely isolated to
section 6.6.3 and therefore no discussion on its influence put in
here.


This proposed change would increase client complexity (on average) for 
BOTH the sender and recipient.  Not good.
For XEP-0308, senders should break a long backspace sequence into 
multiple , one for current message, and one for previous message.

This is simpler and isolates complexity only to senders.

See this section to understand why your change is bad:
http://xmpp.org/extensions/xep-0301.html#usage_with_last_message_correction

1. Refer to previous discussions, many hours were spent (in two 
different months, I believe) discussing over:

- XEP-0301 and XEP-0308 sent to clients

Re: [Standards] XEP-0301 (In-Band Real Time Text) v0.8 erasure and lag

[Gunnar Hellstrom]

It is good to see a new version of the XMPP Real Time Text extension.


On 2013-04-08 17:47, XMPP Extensions Editor wrote:

Version 0.8 of XEP-0301 (In-Band Real Time Text) has been released.

Abstract: This is a specification for real-time text transmitted in-band over 
an XMPP session.
   Real-time text is text transmitted instantly while it is being typed or
   created.
Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.7/vs/0.8

URL: http://xmpp.org/extensions/xep-0301.html


The general impression is that it is in a good and mature condition.

I have a couple of small comments.

1. Erasure over message border.
In 4.6.3.2, it is said about the Erase element:
"Note: Excess backspaces MUST be ignored. Thus, text is backspaced only 
to the beginning of the message, in situations where n is larger than p."


This can be perceived in three ways. Support of XEP-0308 for last 
message correction may change the situation a bit.


1. Seen from the transmitting user perspective, with XEP-0308 support, 
backspacing over the message border may be the natural way to return to 
the previous message and make a small correction.  Without XEP-0308 
support, the statement is true.


2. Seen from the transmitting client perspective. If XEP-0308 is 
supported, then a user backspace at the beginning of the message should 
not be ignored, but instead activate last message correction, providing 
a  and start acting in the previous message. IF XEP-0308 is not 
supported, then the statement is true.


3. Seen from the receiving client perspective, the statement is true. 
"Excess" backspaces shall be caught by the transmitting client and 
either ignored or caused to generate the move to the previous message 
before continuing to erase, depending on XEP-0308 support.


I suggest that the XEP-0308 influence is kept largely isolated to 
section 6.6.3 and therefore no discussion on its influence put in here.


Instead, if anything shall be done, I suggest to just insert words "by 
the receiving client", so that the note reads:


"Note: Excess backspaces MUST be ignored by the receiving client. Thus, 
text is backspaced only to the beginning of the message, in situations 
where n is larger than p."


2. Risk for excessive lag.
In "6.5 Receiving Real-Time Text", I think this text is scaring:
"In processing Element  -- Wait Interval 
, 
excess lag in incoming real-time text might occur if multiple delayed 
 elements suddenly get delivered"


I think that in most applications, the users prefer rapid presentation 
over exact replication of timing of typing.

An easy way out is to be just a little bit more prescriptive:

"In processing Element  -- Wait Interval 
, 
excess lag in incoming real-time text might occur if multiple delayed 
 elements suddenly get delivered (e.g. congestion, intermittent 
wireless reception). Recipients should avoidexcess sustained lag by 
monitoring the queue for excess  action elements (e.g. unprocessed 
 elements from more than one  element before the latest 
received ) and then ignoring or shortening the intervals in  
elements. This allows lagged real-time text to "catch up"  quickly."


Another action would be to introduce timestamping of rtt elements rather 
than acting from their time of delivery if this is a real issue.


These two comments are on a level that could be left without action. I 
think that the draft is good now and can be taken through last call as 
was discussed already for the previous version.


/Gunnar

Re: [Standards] UPDATED: XEP-0308 (Last Message Correction) - editorial change request withdrawn.

[Gunnar Hellstrom]

While I was composing the mail below based on version 0.2 of XEP-0308, 
the release of version 1.0 of XEP-0308 took place.


Therefore I withdraw my request for the editorial change in section 4, 
and want to congratulate the author of XEP-0308 to a very useful XMPP 
extension.


Regards
Gunnar


On 2013-04-08 19:04, Gunnar Hellstrom wrote:
Rechecking XEP-0308, I noticed a wording that appeared because of the 
latest changes, but I think should be changed:


In the middle of section 4, there is this statement:

"It is expected that the receiver SHOULD then treat the new stanza as 
complete replacement for all the payloads received in the original 
stanza."


The "expected - SHOULD" combination looks strange.  I assume that the 
intention was:


"The receiver SHOULD then treat the new stanza as complete replacement 
for all the payloads received in the original stanza."


It is editorial.

-

XEP-0301 became available in a new version 0.8 today. XEP-0301 has a 
dependency on XEP-0308. It would be good if XEP-0308 could move on 
through another last call.


Regards

Gunnar

On 2013-02-27 17:30, XMPP Extensions Editor wrote:

Version 0.2 of XEP-0308 (Last Message Correction) has been released.

Abstract: This specification defines a method for indicating that a message is 
a correction of the last sent message.

Changelog: Updates to address Last Call feedback. (kis)

Diff:http://xmpp.org/extensions/diff/api/xep/0308/diff/0.1/vs/0.2

URL:http://xmpp.org/extensions/xep-0308.html

Re: [Standards] UPDATED: XEP-0308 (Last Message Correction)

[Gunnar Hellstrom]

Rechecking XEP-0308, I noticed a wording that appeared because of the 
latest changes, but I think should be changed:


In the middle of section 4, there is this statement:

"It is expected that the receiver SHOULD then treat the new stanza as 
complete replacement for all the payloads received in the original stanza."


The "expected - SHOULD" combination looks strange.  I assume that the 
intention was:


"The receiver SHOULD then treat the new stanza as complete replacement 
for all the payloads received in the original stanza."


It is editorial.

-

XEP-0301 became available in a new version 0.8 today. XEP-0301 has a 
dependency on XEP-0308. It would be good if XEP-0308 could move on 
through another last call.


Regards

Gunnar

On 2013-02-27 17:30, XMPP Extensions Editor wrote:

Version 0.2 of XEP-0308 (Last Message Correction) has been released.

Abstract: This specification defines a method for indicating that a message is 
a correction of the last sent message.

Changelog: Updates to address Last Call feedback. (kis)

Diff: http://xmpp.org/extensions/diff/api/xep/0308/diff/0.1/vs/0.2

URL: http://xmpp.org/extensions/xep-0308.html

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

[Gunnar Hellstrom]

On 2013-02-24 17:20, Kevin Smith wrote:

On Sat, Oct 13, 2012 at 6:46 AM, Gunnar Hellström
 wrote:

My conclusions are:
1. The feature will be allowed. ( deduced from your answer that Kev is asked
do do an update )
2. How edits are presented to the receiving user is out of scope, but a
recommendation to make it clearly displayed that there was an edit will be
included.
3. Edit any previous will be included. It is up to the transmitter to use it
or not. Receivers should be prepared to act on editing any previous.

I have updated 308 in Git. I believe I've addressed all feedback other
than allowing editing of any previous - for this I've made a note that
the protocol can be used as such, but that signalling is out of scope
and so 308 without further negotiation is only for the last message.
That is fine. I fully respect your decision and am glad that XEP-0308 
will be rescued from deferred state.


/Gunnar

[Standards] XEP-0308 (Last Message Correction) correct last or any previous message

[Gunnar Hellstrom]

On 2012-08-31 14:27, Kurt Zeilenga wrote:

On Aug 31, 2012, at 4:09 AM, Dave Cridland  wrote:


I'm still concerned that replacing any but the author's last message is likely 
to cause problems with accurately presenting the data.

I generally think it best to separately display the corrected text (as a new 
message) in the presentation stream with annotations that it is a replacement 
for a previously presented text, whether it's the last message or not.  This 
not only for security reasons, but to maintain conversational flow.

-- Kurt

It has been silent around XEP-0308 some time now.

XEP-0301 In-Band Real-time text is about to be published in a new 
version. It refers to XEP-0308 for editing earlier messages.
I have not yet seen a conclusion on the issue in XEP-0308, if it will 
enable correction of only the last message or any previous.


The decision influences language in XEP-0301, so I would appreciate to 
know the decision.
I have no strong argument for any specific decision, but I can express a 
slight preference for the "any previous" option.
It would of course also be good to see XEP-0308 move on through a 
successful Last Call.


 /Gunnar