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

[Peter Saint-Andre]

On 7/27/12 8:19 AM, Mark Rejhon wrote:

 "The event attribute MAY be omitted from the  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  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  elements.
> How can the wording be tweaked, so that circumstance is accomodated for?

There's no such thing as NOT REQUIRED in RFC 2119. I suggest changing it
to "The event attribute is not necessary..."

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

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

[Peter Saint-Andre]

On 7/23/12 1:17 PM, Mark Rejhon wrote:

> [Question]
> Understood -- animation really helps explains real-time text, if they
> haven't seen it before.
> Can we use a more well-known site (i.e. realtimetext.org
> ?) since we can put my animations there too?
>  Alternatively, can we embed an image, like XEP-0071 has an embedded
> image?  (If I make a generic animation, and convert it to animated GIF
> format)

I think it would be great to host a sample animated GIF at xmpp.org, for
archival purposes.

> /P.S. Will inquire about the name concern (private inquiry to Peter).  I
> had talked to many at Cisco over the last two years. Paul E. Jones is a
> a member of R3TF who works at Cisco.  Nobody has ever brought up concern
> about the RealJabber name, but I will now inquire specifically about this./

Just because someone works at Cisco doesn't mean they would have any
awareness of the JABBER trademark. But we can chat about that off-list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

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

[Kevin Smith]

On Sat, Jul 28, 2012 at 8:30 AM, Mark Rejhon  wrote:
> On Sat, Jul 28, 2012 at 1:22 AM, Gunnar Hellström
>  wrote:
>>>
>>> No, please make a MUST for id=  in edit previous. I can imagine
>>> presentation cases when it is absolutely necessary to know what message
>>> the
>>> edits belong to. Why do you want to introduce so many options? Strict
>>> requirements are usually much more fruitful.

 But I do not understand why you want to introduce the risk of confusing
 presentation by telling that it is possible to do last message edit
 without
 id= , when you have specified that feature for exactly that function.
 At the moment we have no backwards compatibility to bother about. Why not
 get it right from the beginning?

 Gunnar
>>>
>>> Again, Kevin now needs to explain why a third disco case was needed
>>> (he suggested one in addition to the existing 0301 and 0308 disco).
>>> Kevin originally said it was for allowing 0308 to be used without 0301
>>> retroactive editing.  This was a solution to succeed on this feature
>>> without requiring a third disco to be added.
>>>
>>> Also, the change will still be be permitted under XEP-0001 draft rules
>>> -- making it stricter is a fully backwards-compatible change.  Kevin
>>> -- are you fine with always requiring 0301 to use 'id' attribute --
>>> for a client that implements both 0308 and 0301?
>>>
>>> Mark Rejhon
>>
>>  A MUST for supporting reception of id= when you have negotiated both
>> 0301 and 0308 is the logical conclusion.
>> And if you transmit rtt during the correction then that MUST be marked with
>> id= .
>> And you at least SHOULD support transmission of rtt during the correction.
>> I do not see a need for an extra negotiation of the combination of 0301 and
>> 0308. I think the idea behind it would be that it can be complex to present
>> the edit last in rtt mode when you have already transmitted the beginning of
>> next message. But that must be manageable.
>>
>> Allowing rtt without id= during correction could end up in confusing
>> presentation.
>>
>> Example: A and B are negotiating a payment.
>>
>> This is the way it will be displayed if there was not id= support during rtt
>> A: I will give you 100 EUR
>> B: Not enough
>> A: I add 50 EUX
>> (A discovers the mistake. With edit last support without id= support, the
>> corrected sentence would be displayed as new until it is completed)
>> A: I add 50 EUR and this is my last bid, take it or leave it, I want to get
>> this done, tomorrow is my daughter's birthday and I do not have time
>> B: ( while A is typing ) Great 200 agreed
>>
>> When finally A completes the sentence, the corrected message should replace
>> the one with EUX, but that may be too late. The confusion has already caused
>> harm.
>>
>> With id= support in rtt, you will instead see the EUX changed to EUR, no
>> duplication of text, and the correct deal achieved without confusion.
>> I recommend that we avoid this risk for confusion by requiring support of
>> id= if both 0301 and 0308 are negotiated
>>
>> Gunnar
>
> Good use case -- but --
> This still makes the current version of 0301+0308 (even without 'id'')
> superior to older suggestions of 0301+0308 (without any real time text
> at all, for retroactive)
>
> Since this is for the next version after 0.6, the two obvious choices are:
> -- Change to require retroactive  whenever 0301+0308 is both active
> -- Keep my existing method (which I feel is still superior, for
> Gunnar's use case, to Kevin's original method that suggested a third
> disco be used)
>
> Comments from Kevin?  He's the author of 0308, so I'd like agreement from him.

I think that if you're sending an RTT correction, your client needs to
know that you support it, because otherwise you end up with goofy (and
harmful) situations as Gunaar suggests. I see two ways of ensuring
this:

1) Mandate that if you advertise support for both RTT and Correct that
you understand RTT Corrections.
2) Have a third disco feature for RTT Corrections.

I'm reasonably opposed to the situation where a sender's client is
sending RTT Corrections without any way of knowing if the recipient
supports them - which can lead to the recipient /user/ thinking
they're reading a new message, but aren't. You've previously said that
people tend to use RTT without pressing Enter and sending a message,
using the structure of the text for message boundaries. This doesn't
seem to mesh well with users not knowing if what they're reading is a
new message or an update to an existing message.

I don't think the argument of "Well, the recipient will be able to
render /something/ it just won't by able to render the right thing
(or, rather won't be in the right context)" is terribly satisfying
here.

/K

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

[Mark Rejhon]

On Sat, Jul 28, 2012 at 1:22 AM, Gunnar Hellström
 wrote:
>>
>> No, please make a MUST for id=  in edit previous. I can imagine
>> presentation cases when it is absolutely necessary to know what message
>> the
>> edits belong to. Why do you want to introduce so many options? Strict
>> requirements are usually much more fruitful.
>>>
>>> But I do not understand why you want to introduce the risk of confusing
>>> presentation by telling that it is possible to do last message edit
>>> without
>>> id= , when you have specified that feature for exactly that function.
>>> At the moment we have no backwards compatibility to bother about. Why not
>>> get it right from the beginning?
>>>
>>> Gunnar
>>
>> Again, Kevin now needs to explain why a third disco case was needed
>> (he suggested one in addition to the existing 0301 and 0308 disco).
>> Kevin originally said it was for allowing 0308 to be used without 0301
>> retroactive editing.  This was a solution to succeed on this feature
>> without requiring a third disco to be added.
>>
>> Also, the change will still be be permitted under XEP-0001 draft rules
>> -- making it stricter is a fully backwards-compatible change.  Kevin
>> -- are you fine with always requiring 0301 to use 'id' attribute --
>> for a client that implements both 0308 and 0301?
>>
>> Mark Rejhon
>
>  A MUST for supporting reception of id= when you have negotiated both
> 0301 and 0308 is the logical conclusion.
> And if you transmit rtt during the correction then that MUST be marked with
> id= .
> And you at least SHOULD support transmission of rtt during the correction.
> I do not see a need for an extra negotiation of the combination of 0301 and
> 0308. I think the idea behind it would be that it can be complex to present
> the edit last in rtt mode when you have already transmitted the beginning of
> next message. But that must be manageable.
>
> Allowing rtt without id= during correction could end up in confusing
> presentation.
>
> Example: A and B are negotiating a payment.
>
> This is the way it will be displayed if there was not id= support during rtt
> A: I will give you 100 EUR
> B: Not enough
> A: I add 50 EUX
> (A discovers the mistake. With edit last support without id= support, the
> corrected sentence would be displayed as new until it is completed)
> A: I add 50 EUR and this is my last bid, take it or leave it, I want to get
> this done, tomorrow is my daughter's birthday and I do not have time
> B: ( while A is typing ) Great 200 agreed
>
> When finally A completes the sentence, the corrected message should replace
> the one with EUX, but that may be too late. The confusion has already caused
> harm.
>
> With id= support in rtt, you will instead see the EUX changed to EUR, no
> duplication of text, and the correct deal achieved without confusion.
> I recommend that we avoid this risk for confusion by requiring support of
> id= if both 0301 and 0308 are negotiated
>
> Gunnar

Good use case -- but --
This still makes the current version of 0301+0308 (even without 'id'')
superior to older suggestions of 0301+0308 (without any real time text
at all, for retroactive)

Since this is for the next version after 0.6, the two obvious choices are:
-- Change to require retroactive  whenever 0301+0308 is both active
-- Keep my existing method (which I feel is still superior, for
Gunnar's use case, to Kevin's original method that suggested a third
disco be used)

Comments from Kevin?  He's the author of 0308, so I'd like agreement from him.

Thanks,
Mark Rejhon

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

[Gunnar Hellström]

On 2012-07-27 23:48, Mark Rejhon wrote:

No, please make a MUST for id=  in edit previous. I can imagine
presentation cases when it is absolutely necessary to know what message
the
edits belong to. Why do you want to introduce so many options? Strict
requirements are usually much more fruitful.

But I do not understand why you want to introduce the risk of confusing
presentation by telling that it is possible to do last message edit without
id= , when you have specified that feature for exactly that function.
At the moment we have no backwards compatibility to bother about. Why not
get it right from the beginning?

Gunnar

Again, Kevin now needs to explain why a third disco case was needed
(he suggested one in addition to the existing 0301 and 0308 disco).
Kevin originally said it was for allowing 0308 to be used without 0301
retroactive editing.  This was a solution to succeed on this feature
without requiring a third disco to be added.

Also, the change will still be be permitted under XEP-0001 draft rules
-- making it stricter is a fully backwards-compatible change.  Kevin
-- are you fine with always requiring 0301 to use 'id' attribute --
for a client that implements both 0308 and 0301?

Mark Rejhon
 A MUST for supporting reception of id= when you have negotiated 
both 0301 and 0308 is the logical conclusion.
And if you transmit rtt during the correction then that MUST be marked 
with id= .

And you at least SHOULD support transmission of rtt during the correction.
I do not see a need for an extra negotiation of the combination of 0301 
and 0308. I think the idea behind it would be that it can be complex to 
present the edit last in rtt mode when you have already transmitted the 
beginning of next message. But that must be manageable.


Allowing rtt without id= during correction could end up in confusing 
presentation.


Example: A and B are negotiating a payment.

This is the way it will be displayed if there was not id= support during 
rtt

A: I will give you 100 EUR
B: Not enough
A: I add 50 EUX
(A discovers the mistake. With edit last support without id= support, 
the corrected sentence would be displayed as new until it is completed)
A: I add 50 EUR and this is my last bid, take it or leave it, I want to 
get this done, tomorrow is my daughter's birthday and I do not have 
time

B: ( while A is typing ) Great 200 agreed

When finally A completes the sentence, the corrected message should 
replace the one with EUX, but that may be too late. The confusion has 
already caused harm.


With id= support in rtt, you will instead see the EUX changed to EUR, no 
duplication of text, and the correct deal achieved without confusion.
I recommend that we avoid this risk for confusion by requiring support 
of id= if both 0301 and 0308 are negotiated


Gunnar

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

[Mark Rejhon]

On Fri, Jul 27, 2012 at 5:35 PM, Gunnar Hellström
 wrote:
> On 2012-07-27 23:24, Mark Rejhon wrote:
>>
>> On Fri, Jul 27, 2012 at 4:31 PM, Gunnar Hellström
>>  wrote:
>>>
>>> No, please make a MUST for id=  in edit previous. I can imagine
>>> presentation cases when it is absolutely necessary to know what message
>>> the
>>> edits belong to. Why do you want to introduce so many options? Strict
>>> requirements are usually much more fruitful.
>>
>> Kevin needs to explain why a third disco case was needed.
>>
>> I don't see it as a LC holdup, and it will be a while before 0301+0308
>> implementations show up, so leaving it unchanged to 0.6 which is
>> already in freeze & being converted for emailing to Peter
>>
>> Thanks
>> Mark rejhon
>
>
>  Yes, if you have frozen the version for last call, let it go. I hope we
> are allowed to decide on this during LC. But the less we change the better.
>
> But I do not understand why you want to introduce the risk of confusing
> presentation by telling that it is possible to do last message edit without
> id= , when you have specified that feature for exactly that function.
> At the moment we have no backwards compatibility to bother about. Why not
> get it right from the beginning?
>
> Gunnar

Again, Kevin now needs to explain why a third disco case was needed
(he suggested one in addition to the existing 0301 and 0308 disco).
Kevin originally said it was for allowing 0308 to be used without 0301
retroactive editing.  This was a solution to succeed on this feature
without requiring a third disco to be added.

Also, the change will still be be permitted under XEP-0001 draft rules
-- making it stricter is a fully backwards-compatible change.  Kevin
-- are you fine with always requiring 0301 to use 'id' attribute --
for a client that implements both 0308 and 0301?

Mark Rejhon

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

[Gunnar Hellström]

On 2012-07-27 23:24, Mark Rejhon wrote:

On Fri, Jul 27, 2012 at 4:31 PM, Gunnar Hellström
 wrote:

No, please make a MUST for id=  in edit previous. I can imagine
presentation cases when it is absolutely necessary to know what message the
edits belong to. Why do you want to introduce so many options? Strict
requirements are usually much more fruitful.

Kevin needs to explain why a third disco case was needed.

I don't see it as a LC holdup, and it will be a while before 0301+0308
implementations show up, so leaving it unchanged to 0.6 which is
already in freeze & being converted for emailing to Peter

Thanks
Mark rejhon


 Yes, if you have frozen the version for last call, let it go. I 
hope we are allowed to decide on this during LC. But the less we change 
the better.


But I do not understand why you want to introduce the risk of confusing 
presentation by telling that it is possible to do last message edit 
without id= , when you have specified that feature for exactly that 
function.
At the moment we have no backwards compatibility to bother about. Why 
not get it right from the beginning?


Gunnar

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

[Mark Rejhon]

On Fri, Jul 27, 2012 at 4:31 PM, Gunnar Hellström
 wrote:
> No, please make a MUST for id=  in edit previous. I can imagine
> presentation cases when it is absolutely necessary to know what message the
> edits belong to. Why do you want to introduce so many options? Strict
> requirements are usually much more fruitful.

Kevin needs to explain why a third disco case was needed.

I don't see it as a LC holdup, and it will be a while before 0301+0308
implementations show up, so leaving it unchanged to 0.6 which is
already in freeze & being converted for emailing to Peter

Thanks
Mark rejhon

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

[Gunnar Hellström]

Further comments inline,
On 2012-07-27 21:00, Mark Rejhon wrote:

Unicode talk and 'seq' talk replied to, under their appropriate thread
titles -- to compartmentalize the topics better. (those are
potentially contentious items during reviews)


"The event attribute MAY be omitted from the  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  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  elements.
How can the wording be tweaked, so that circumstance is accomodated for?

 You can replace
"The event attribute MAY be omitted from the  element during regular
real-time text transmission."
with
"The event attribute is used in situations specified below."

[Change Made]
"The use of  elements without an event attribute is for
transmitting changes to an existing real-time message. The event
attribute is used in the situations specified below:

Note: I need to explain to the reader, which situations  can be
transmitted without an event attribute, so the extra preceding
sentence becomes necessary.  Some may comment I should change the
phrase "is used" to a "MUST be used".  That said, I already define the
RFC2119 normatives in the table below the sentence, so that likely is
sufficient.
Yes, it would not fit well with MUST in the introductory sentence 
and MAY for the two optional values.

Your proposed sentence looks ok to me.



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

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

It's a very edge case, and even that edge case can be resolved by
determining if the suceeding  is a  event.  This
allows post-processing of linking real-time text to the correct
message, without the help of an 'id' attribute.
I agree on making it a SHOULD, but not a REQUIRED.
No, please make a MUST for id=  in edit previous. I can imagine 
presentation cases when it is absolutely necessary to know what message 
the edits belong to. Why do you want to introduce so many options? 
Strict requirements are usually much more fruitful.


Gunnar

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

[Mark Rejhon]

Unicode talk and 'seq' talk replied to, under their appropriate thread
titles -- to compartmentalize the topics better. (those are
potentially contentious items during reviews)

> "The event attribute MAY be omitted from the  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  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  elements.
> How can the wording be tweaked, so that circumstance is accomodated for?
>
>  You can replace
> "The event attribute MAY be omitted from the  element during regular
> real-time text transmission."
> with
> "The event attribute is used in situations specified below."

[Change Made]
"The use of  elements without an event attribute is for
transmitting changes to an existing real-time message. The event
attribute is used in the situations specified below:

Note: I need to explain to the reader, which situations  can be
transmitted without an event attribute, so the extra preceding
sentence becomes necessary.  Some may comment I should change the
phrase "is used" to a "MUST be used".  That said, I already define the
RFC2119 normatives in the table below the sentence, so that likely is
sufficient.


> [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.
>
>  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=.

It's a very edge case, and even that edge case can be resolved by
determining if the suceeding  is a  event.  This
allows post-processing of linking real-time text to the correct
message, without the help of an 'id' attribute.
I agree on making it a SHOULD, but not a REQUIRED.

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

[Gunnar Hellström]

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

I suggest a random start seq with 30 bits  for each session..

"The event attribute MAY be omitted from the  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  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  elements.
How can the wording be tweaked, so that circumstance is accomodated for?

 You can replace
"Theeventattribute MAY be omitted from the  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. 
 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
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

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

[Mark Rejhon]

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

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

[Comment]
Full JID may not be available in a MUC.  Here, resetting to 0
potentially becomes a major problem.   I could REQUIRE senders to send
 and recipients to distinguish by , but I feel that
is a more onerous requirement than simply recommending randomizing
seq.


>>> "The event attribute MAY be omitted from the  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  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  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.

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


> 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 b

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

[Kevin Smith]

I think this mail gets me up to date.

On Mon, Jul 23, 2012 at 8:17 PM, Mark Rejhon  wrote:
> Due to the large number of comments from a key person at XSF (you) I agree
> with you.I have many comments and questions for you first, that I'd like
> you to address. I will reply in two emails -- this email is regarding
> section 1 through 5.  I have prefaced with [Comment], [Question], and
> [Change Made] in appropriate places for easy reading.

I stress  that these are personal comments, not coming from Council.


>> == Introduction ==
>> This seems mostly fine. I wonder about the reference to
>> realjabber.org. Partly because it's a reference to a potentially less
>> stable URL, and partly because I think the name is inflammatory - did
>> the XSF or Cisco grant the trademark use?
>
>
> [Question]
> Understood -- animation really helps explains real-time text, if they
> haven't seen it before.
> Can we use a more well-known site (i.e. realtimetext.org?) since we can put
> my animations there too?

I think 'real time text' is a less contentious term than 'real
Jabber', I'd feel a bit happier with a link there instead.



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


>> It's not clear to me why setting seq to a random initial value should
>> help with MUC or multi-resource cases - in these cases you know the
>> full JID of the entities involved and a random start point seems to
>> make it harder to understand what's going on, rather than easier.
>
>
> [Question]
> Imagine a simultaneous login, both logins somehow started typing and the
> client doesn't distinguish the two.  If both started at the same seq number
> (0), then there will be some situations where the seq looks like they are
> incrementing when recieving a  from one client than an  from a
> different client.   This will cause occasional text scrambling to occur
> (until it disppears in the next Message Reset).

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. If it's not, I don't think it's a problem to
start from zero.


>> "The event attribute MAY be omitted from the  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  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.


>>   Choice 1) If you implement 308 and you also implement 301 you MUST
>> support (at least receiving) RTT correction and ids are not OPTIONAL
>> and MUST be included on the correction RTT.
>>   Choice 2) You can implement 308 and 301 yet not support RTT
>> correction - in which case supporting RTT correction is OPTIONAL, but
>> if you do you MUST advertise appropriate disco features and MUST
>> include ids etc.
>
>
> [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.


>> 4.5 - "the recipient can watch the sender" - this isn't quite right
>> (similar to previous comment).
>
> [Change Made]
> I have replaced the word "watch" with "see", because "see" is compatible
> with a software viewpoint.  (interpreted as "The software sees the changes
> to the message" even if the message is not displayed) -- To keep things
> simple for a wider variety of 

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

[Kevin Smith]

On Thu, Jul 26, 2012 at 10:30 PM, Mark Rejhon  wrote:
> here), but this email aims to reduce workload for Kevin.

Thanks.

> On Mon, Jul 23, 2012 at 3:17 PM, Mark Rejhon  wrote:
> I believe that this email addresses most of Kevin's concerns for
> section 1-5, with the exception of the Unicode concerns, and the
> concerns about bare vs full JID.  (These topics have already been
> forked to separate email threads)
> Hope this email at least reduces Kevin's workload, and allows me to
> publish Version 0.6 before the end of the week (So Matt et cetra can
> read it)

Everything in this latest mail seems sensible at first glance, thanks.

/K

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

[Kevin Smith]

On Tue, Jul 24, 2012 at 10:37 PM, Lance Stout  wrote:
> " The  element is transmitted at regular intervals by the sender
> client while a message is being composed"
>
>
> If we're going to be picky about what the first example demonstrates, it
> should probably also be noted in this sentence that the regular intervals
> are intended to be temporal, and not simply "every N characters". Thus, if
> any change is to be made, we should make sure that each RTT in the example
> does not have the same number of characters, for the same reasons as have
> been discussed.

My examples did that ;)

/K

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

[Mark Rejhon]

More changes made, after thought and consultations.
I think I've now addressed 90% of the section 1-5 concerns by Kevin.
Some small unanswered questions in the original email (not included
here), but this email aims to reduce workload for Kevin.


On Mon, Jul 23, 2012 at 3:17 PM, Mark Rejhon  wrote:
>> == Requirements ==
>> 2.3.4 doesn't seem quite right - what we want is for it to be possible
>> to produce gateways for interoperability - not that XEP 301
>> implementations themselves interop with other networks?
>> 2.4 Doesn't seem to be about Accessibility.
>> 2.4.4 Doesn't make much sense to me.
>
> [Question]
> Peter (or anyone else at XSF), any comments about these?
> I'd like a second set of comments on these points, and then I'd like to 
> confer with the R3TF group about revisions.

[Change Made]
-- 2.3.4 bullet clarified to say "Allow use within gateways to
interoperate with other real-time text protocols, including RFC 4103
and ITU-T T.140." ... This feature is a critical requirement for some
parties, including Omnitor (Gunnar Helstrom).
-- 2.4 heading remains unchanged for 0.6, I would appreciate wider
comment for renaming this heading while keeping accessibility.
-- 2.4.4 bullet changed to "Allow immediate conversational text
through mobile phone text messaging and mainstream instant messaging."
... A major goal of XEP-0301 is to permit existing texting
environments to be used conversationally.  It's worth noting that this
bullet acknowledges the use of XMPP in environments normally used for
SMS (e.g. Apple iMessenger, Google Talk Android, etc)


>> 4.2.2 - "Recipients MUST treat 'reset' the same as 'new'." - I'm not
>> sure that's quite right. If recipients want to render 'new'
>> differently that seems to be fine. Maybe "Recipients MUST reset the
>> state of the current real-time message when receiving a 'reset'
>> (returning the real-time message to the same state as when receiving a
>> 'new')"?
>
> [Comment & Question]
> Yes, rendering 'new' and 'reset' is the reason that the two still are treated 
> separate.
> However:
> (1) It's possible to receive  without ever receiving an 
> .  (e.g. recipient logs on after sender starts composing, 
> MUC participant joins, stanza with 'new' is lost, etc).
> (2) Basic Real-Time Text at 
> http://xmpp.org/extensions/xep-0301.html#basic_realtime_text
> (3) The 'new' _also_ resets any existing real-time message if any is shown.  
> There is always only one real-time message per sending client.
> [snip]

[Change Made]
event='new'
Senders MUST use this value when transmitting the first  element
containing [[[Action Elements]]] (i.e. the first character(s) of a new
message). Recipient clients MUST initialize a new real-time message
for display, and then process action elements within the 
element. If a real-time message already exists in the same chat
session, its content MUST be replaced (i.e. cleared prior to
processing action elements). Senders MAY send subsequent 
elements that do not contain an event attribute.

event='reset'
For recipients, both 'new' and 'reset' are logically identical, and
differ only for implementation purposes (e.g. highlighting
newly-started messages). Recipient clients MUST initialize a new
real-time message for display, and then process action elements within
the  element. If a real-time message already exists in the same
chat session, its content MUST be replaced (i.e. cleared prior to
processing action elements). Senders MAY send subsequent 
elements that do not contain an event attribute. Recipients MUST be
able to process 'reset' without first receiving 'new'. See [[[Message
Reset]]], used for [[[Keeping Real-Time Text Synchronized]]] and
[[[Basic Real-Time Text]]].


>> 4.5.3.2 - This might become clearer later, but at this stage it's not clear 
>> what 'positions' are.

[Change Made]
Section 4.5.2: Improved the first two bullets, for definition of
position and length:

- For [[[Element  – Erase Text]]]:
The n attribute is a length value, in number of characters. If n is
omitted, the default value of n MUST be 1.
- For [[[Element  – Insert Text]]] and [[[Element  – Erase Text]]]:
The p attribute is an absolute position value, as a character position
index into the message, where 0 represents the beginning of the
real-time message. If p is omitted, the default value of p MUST point
to the end of the message (i.e. p is set to the current length of the
real-time message).


>> 4.5.3.3 - Apart from adding complexity I'm not sure what forward
>> delete is buying us vs. backspace.

[Change Made]
Background information: After a few hours of tests and consultations,
several implementers have agreed the merger has more advantages than
disadvantages.  There are several reasons posted in my last reply,
including time-smoothed display, and accurate journalling of edits
(recipient being able to tell Backspace keypresses apart from Delete
keypresses).  However, I have now consulted several known
implementations, and we have all, so far,

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

[Mark Rejhon]

On Tue, Jul 24, 2012 at 5:37 PM, Lance Stout  wrote:

> " The  element is transmitted at regular intervals by the sender
> client while a message is being composed"
>
> If we're going to be picky about what the first example demonstrates, it
> should probably also be noted in this sentence that the regular intervals
> are intended to be temporal, and not simply "every N characters". Thus, if
> any change is to be made, we should make sure that each RTT in the example
> does not have the same number of characters, for the same reasons as have
> been discussed.
>

Right -- It is temporal.  And yes, I agree with you too.
Though it doesn't have to be an exact clock --- it is permitted to
temporally vary (e.g. word transmission of captioning / transcription,
meaning  is timed with the bursts from a transcription engine).   I
do give some coverage of that later in the specification.

Mark Rejhon

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

[Lance Stout]

> " The  element is transmitted at regular intervals by the sender client 
> while a message is being composed"

If we're going to be picky about what the first example demonstrates, it should 
probably also be noted in this sentence that the regular intervals are intended 
to be temporal, and not simply "every N characters". Thus, if any change is to 
be made, we should make sure that each RTT in the example does not have the 
same number of characters, for the same reasons as have been discussed.

-- Lance

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

[Mark Rejhon]

On Tue, Jul 24, 2012 at 5:18 PM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

>  Both Kevin and me detected the little logic gap in the text of section
> 4.1 and the example.
>

That's because you two are smart implementers.
You have to factor in all implementers
- Implementers who just go straight to examples
- Implementers who read linearly
- Implementers who jump all over
- Implementers who make assumptions
- Implementers who figure out quickly
- Implementers that take a long time to figure things out
- Etc.
I feel I have chosen the best compromise to accomodate the above.  You've
already figured it out.  So?
Anyway, I'll leave this till LAST CALL.

There are more pressing matters to discuss, including discussion about the
merger of  and  elements, which is far more important and
disruptive to protocol.   I am eagerly awaiting Kevin's comments about
this.   Please move on to pressing matters.

Thank you,
Mark Rejhon

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

[Gunnar Hellström]

On 2012-07-24 19:21, Mark Rejhon wrote:
[About changing XEP-0301 introductory example to transmit fragmented 
words versus whole words]


On Tue, Jul 24, 2012 at 1:15 PM, Mark Rejhon > wrote:


Right now, votes are roughly evenly split (half a dozen Yea's, and
half a dozen Nay's over the last 2 years)


Note -- this includes offline discussion with companies on three 
different continents, as well as members within the Real Time Text 
Taskforce, etc.


There should be no need for voting here. It is just about clear logic 
and trying to make the specification consistent and understandable.


Both Kevin and me detected the little logic gap in the text of section 
4.1 and the example.


The text says:
" The  element is transmitted at regular intervals by the sender 
client while a message is being composed"


The example shows  elements perfectly divided in the words "Hello" 
, "my", "Juliet".


The reader just starting to try to grasp the protocol will of course 
wonder "H, how come that the typer has completed the words on these 
regular intervals? Is there some other meaning buried here with even 
words that I have not yet understood?" And from that on, the reader will 
be less receptive to grasp the details of the protocol but will merely 
search for the answers on these questions.


So, I again suggest that you let the first example just show what the 
text says by a more random division of the transmitted text.


The word-by-word thoughts can be saved for 6.1.4.


/Gunnar

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

[Mark Rejhon]

[About changing XEP-0301 introductory example to transmit fragmented words
versus whole words]

On Tue, Jul 24, 2012 at 1:15 PM, Mark Rejhon  wrote:

> Right now, votes are roughly evenly split (half a dozen Yea's, and half a
> dozen Nay's over the last 2 years)
>

Note -- this includes offline discussion with companies on three different
continents, as well as members within the Real Time Text Taskforce, etc.

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

[Mark Rejhon]

On Tue, Jul 24, 2012 at 11:31 AM, Gregg Vanderheiden wrote:

> I agree
>
> the word by word is often brought up -- but never implemented.  It make
> little sense to add this here and confuse the discussion.  You can't do
> word by word without XEP-0301 == and if doing XEP-0301 you can do   NT or
> WbWord or SbSentence or CbClause whatever you want.  But I would not get
> into discussing or mentioning them except to say that you can allow any of
> them as options in a client but should be on the receiving side as a
> preference.
>
> Talking about doing word by word but sending fragments if person is slow
> etc is just confusing this standard.   Keep it simple I think.
>

That's why I kept the Introductory Example quite simple for this.

In order of preference, I like:
1. Natural Typing
2. Time-Smoothed
3. Word Transmission
4. Fragment Transmission
5. Whole Message Transmission (unless in an "email" mood)

The Introduction goes as high as possible (#3) without going into the
complicated territory.

Right now, votes are roughly evenly split (half a dozen Yea's, and half a
dozen Nay's over the last 2 years), and I refuse to budget at the moment,
barring a huge vote surge in one direction or another

Mark Rejhon

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

[Edward Tie]

BUT..

I think about different languages about chinese , thais.  If you make 
wrong word. (invalid word), you need correct this word with back.



Op 24/07/2012 17:31, Gregg Vanderheiden schreef:

I agree

the word by word is often brought up -- but never implemented.  It 
make little sense to add this here and confuse the discussion.  You 
can't do word by word without XEP-0301 == and if doing XEP-0301 you 
can do   NT or WbWord or SbSentence or CbClause whatever you want. 
 But I would not get into discussing or mentioning them except to say 
that you can allow any of them as options in a client but should be on 
the receiving side as a preference.


Talking about doing word by word but sending fragments if person is 
slow etc is just confusing this standard.   Keep it simple I think.



/Gregg/

Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org   --- http://GPII.net








On Jul 24, 2012, at 10:01 AM, Gunnar Hellström wrote:


On 2012-07-24 01:41, Mark Rejhon wrote:
On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström 
mailto:gunnar.hellst...@omnitor.se>> 
wrote:


On 2012-07-23 21:17, Mark Rejhon wrote:


Example 1: I suggest that this could be better demonstrated
by not
cutting at the word boundaries "He", "llo, m", "y Juliet!"
maybe, or
something like that. Experience and/or cynicism say that
implementers
are quite likely to look at the examples, ignore the text, and
misunderstand what's going on if the examples provide
convenient
semantics not required by the protocol.


[Comment]
I don't like this change.  Are you sure?
In some earlier messages, I mentioned that word transmission is
**greatly preferable* *to broken-word transmission.
Also, if an implementer misunderstands, this detail is a more
harmless misunderstanding than broken-word transmission.

There are other examples in the spec.
Comments welcome from people other than Kevin and Gunnar -- I
need more comments because I have comments that they prefer
this Introduction, so I need to reconcile conflicting advice
about the Introductory example.  XEP-0301 permits you to
transmit real-time text any way you want: character-at-a-time,
word-at-a-time, word bursts, original typing intervals,
time-smoothed, etc.   The Introductory Example is unable to
demonstrate all of the possible methods.  IMHO, I chose the
'safest' introductory example.

Again, word transmission is greatly preferable over broken-word
transmission.  (There's been arguments in some accessibility
organizations in some countries, some say they prefer keypress
intervals, some prefer word transmission instead of keypresses,
etc.)   I am talking to a guy from a telco in UK, and he
informed me of a political debate.

Can at least a few more "outsiders" comment on this change,
please?  Thanks :-)


I have also noticed occasional theoretical discussions about
word transmission instead of real-time text. But that just
introduces delays. Long words can take long time to type on
small devices, and many times you have benefit of seeing the
word created in real-time so that you can keep your mind in sync
with the sender.


We discussed this before.  If a word takes longer than usual to 
type, you just simply transmit whatever the word is so far.  It will 
cause occasional broken words for those times that people take a 
long time to compose a word.   But that's OK.


Even if it could be mentioned somewhere, the spec is about
real-time text, and the first example, showing the very basic
features shall also show a realistic example of transmitting
real-time text. Not word-by-word.


I disagree. There are implementers demanding word transmission.
Your edit is rejected unless there's lots of demand (i.e. 5 people 
publicly agreeing with you with no further disagreements in the 
mailing list)


Word-by-word also have the risk of delaying the last typed word
from being transmitted. It must have some inactivity timeout and
transmit whatever is typed if the user just stops typing at the
end of a word without any space or punctuation mark. In order to
not interfere with slow typing, a timeout should likely be in
the order of 7 seconds. That is an unfortunate extra delay in
these circumstances.


That is not a problem, if you have a time limit for word composition 
(i.e. 1 second transmission interval, and reset the transmission 
interval everytime you hit the spacebar.  So that words come out 
very quickly, with no delays more than 1 second)


Please accept the proposals f

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

[Gregg Vanderheiden]

I agree

the word by word is often brought up -- but never implemented.  It make little 
sense to add this here and confuse the discussion.  You can't do word by word 
without XEP-0301 == and if doing XEP-0301 you can do   NT or WbWord or 
SbSentence or CbClause whatever you want.  But I would not get into discussing 
or mentioning them except to say that you can allow any of them as options in a 
client but should be on the receiving side as a preference.  

Talking about doing word by word but sending fragments if person is slow etc is 
just confusing this standard.   Keep it simple I think. 


Gregg

Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org   ---   http://GPII.net








On Jul 24, 2012, at 10:01 AM, Gunnar Hellström wrote:

> On 2012-07-24 01:41, Mark Rejhon wrote:
>> On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström 
>>  wrote:
>> On 2012-07-23 21:17, Mark Rejhon wrote:
>>> Example 1: I suggest that this could be better demonstrated by not
>>> cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or
>>> something like that. Experience and/or cynicism say that implementers
>>> are quite likely to look at the examples, ignore the text, and
>>> misunderstand what's going on if the examples provide convenient
>>> semantics not required by the protocol.
>>> 
>>> [Comment]
>>> I don't like this change.  Are you sure?   
>>> In some earlier messages, I mentioned that word transmission is *greatly 
>>> preferable* to broken-word transmission.
>>> Also, if an implementer misunderstands, this detail is a more harmless 
>>> misunderstanding than broken-word transmission.
>>> 
>>> There are other examples in the spec.
>>> Comments welcome from people other than Kevin and Gunnar -- I need more 
>>> comments because I have comments that they prefer this Introduction, so I 
>>> need to reconcile conflicting advice about the Introductory example.  
>>> XEP-0301 permits you to transmit real-time text any way you want: 
>>> character-at-a-time, word-at-a-time, word bursts, original typing 
>>> intervals, time-smoothed, etc.   The Introductory Example is unable to 
>>> demonstrate all of the possible methods.  IMHO, I chose the 'safest' 
>>> introductory example.
>>> 
>>> Again, word transmission is greatly preferable over broken-word 
>>> transmission.  (There's been arguments in some accessibility organizations 
>>> in some countries, some say they prefer keypress intervals, some prefer 
>>> word transmission instead of keypresses, etc.)   I am talking to a guy from 
>>> a telco in UK, and he informed me of a political debate.  
>>> 
>>> Can at least a few more "outsiders" comment on this change, please?  Thanks 
>>> :-)
>>> 
>> I have also noticed occasional theoretical discussions about word 
>> transmission instead of real-time text. But that just introduces delays. 
>> Long words can take long time to type on small devices, and many times you 
>> have benefit of seeing the word created in real-time so that you can keep 
>> your mind in sync with the sender. 
>> 
>> We discussed this before.  If a word takes longer than usual to type, you 
>> just simply transmit whatever the word is so far.  It will cause occasional 
>> broken words for those times that people take a long time to compose a word. 
>>   But that's OK. 
>> 
>> Even if it could be mentioned somewhere, the spec is about real-time text, 
>> and the first example, showing the very basic features shall also show a 
>> realistic example of transmitting real-time text. Not word-by-word.
>> 
>> I disagree. There are implementers demanding word transmission.  
>> Your edit is rejected unless there's lots of demand (i.e. 5 people publicly 
>> agreeing with you with no further disagreements in the mailing list)
>> 
>> Word-by-word also have the risk of delaying the last typed word from being 
>> transmitted. It must have some inactivity timeout and transmit whatever is 
>> typed if the user just stops typing at the end of a word without any space 
>> or punctuation mark. In order to not interfere with slow typing, a timeout 
>> should likely be in the order of 7 seconds. That is an unfortunate extra 
>> delay in these circumstances.
>> 
>> That is not a problem, if you have a time limit for word composition (i.e. 1 
>> second transmission interval, and reset the transmission interval everytime 
>> you hit the spacebar.  So that words come out very quickly, with no delays 
>> more than 1 second)
>> 
>> Please accept the proposals for the first example being a real-time text 
>> example.
>> 
>> I need comments from several people.  There are people (some of Darren 
>> Sturman's colleagues) who would disagree with you.
>> 
>> Thank you,
>> Mark Rejhon 
> The 

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

[Gunnar Hellström]

On 2012-07-24 01:41, Mark Rejhon wrote:
On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström 
mailto:gunnar.hellst...@omnitor.se>> wrote:


On 2012-07-23 21:17, Mark Rejhon wrote:


Example 1: I suggest that this could be better demonstrated
by not
cutting at the word boundaries "He", "llo, m", "y Juliet!"
maybe, or
something like that. Experience and/or cynicism say that
implementers
are quite likely to look at the examples, ignore the text, and
misunderstand what's going on if the examples provide convenient
semantics not required by the protocol.


[Comment]
I don't like this change.  Are you sure?
In some earlier messages, I mentioned that word transmission is
**greatly preferable* *to broken-word transmission.
Also, if an implementer misunderstands, this detail is a more
harmless misunderstanding than broken-word transmission.

There are other examples in the spec.
Comments welcome from people other than Kevin and Gunnar -- I
need more comments because I have comments that they prefer this
Introduction, so I need to reconcile conflicting advice about the
Introductory example.  XEP-0301 permits you to transmit real-time
text any way you want: character-at-a-time, word-at-a-time, word
bursts, original typing intervals, time-smoothed, etc.   The
Introductory Example is unable to demonstrate all of the possible
methods.  IMHO, I chose the 'safest' introductory example.

Again, word transmission is greatly preferable over broken-word
transmission.  (There's been arguments in some accessibility
organizations in some countries, some say they prefer keypress
intervals, some prefer word transmission instead of keypresses,
etc.)   I am talking to a guy from a telco in UK, and he informed
me of a political debate.

Can at least a few more "outsiders" comment on this change,
please?  Thanks :-)


I have also noticed occasional theoretical discussions about word
transmission instead of real-time text. But that just introduces
delays. Long words can take long time to type on small devices,
and many times you have benefit of seeing the word created in
real-time so that you can keep your mind in sync with the sender.


We discussed this before.  If a word takes longer than usual to type, 
you just simply transmit whatever the word is so far.  It will cause 
occasional broken words for those times that people take a long time 
to compose a word.   But that's OK.


Even if it could be mentioned somewhere, the spec is about
real-time text, and the first example, showing the very basic
features shall also show a realistic example of transmitting
real-time text. Not word-by-word.


I disagree. There are implementers demanding word transmission.
Your edit is rejected unless there's lots of demand (i.e. 5 people 
publicly agreeing with you with no further disagreements in the 
mailing list)


Word-by-word also have the risk of delaying the last typed word
from being transmitted. It must have some inactivity timeout and
transmit whatever is typed if the user just stops typing at the
end of a word without any space or punctuation mark. In order to
not interfere with slow typing, a timeout should likely be in the
order of 7 seconds. That is an unfortunate extra delay in these
circumstances.


That is not a problem, if you have a time limit for word composition 
(i.e. 1 second transmission interval, and reset the transmission 
interval everytime you hit the spacebar.  So that words come out very 
quickly, with no delays more than 1 second)


Please accept the proposals for the first example being a
real-time text example.


I need comments from several people.  There are people (some of Darren 
Sturman's colleagues) who would disagree with you.


Thank you,
Mark Rejhon
The word-by word issue is a theoretical one that has been up for 
discussion in the real-time text area occasionally through the years. ( 
especially in UK, I do not know why. ) I am not aware of any 
implementation or investigation that has shown that it has any benefit 
over Natural Typing or time smoothing. Even if you say that there is 
demand for word-by word, it should not be allowed to confuse the readers 
in the first example of a real-time text standard.


I propose that you follow the advice and do real-time text in the first 
example.


Please note that no explanations around example one says that it is 
intentionally made on word boundaries. It would be more logical to 
mention it in the text among implementation notes in chapter 6, and let 
the specification start with explaining the main implementation.


And, in fact word-by-word is mentioned in 6.1.4. It is not under a 
heading that would make you find it easily. You may change the heading 
or divide the section in two if you want it to be more visible.


Gunnar

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

[Mark Rejhon]

On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

>  On 2012-07-23 21:17, Mark Rejhon wrote:
>
>  Example 1: I suggest that this could be better demonstrated by not
>> cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or
>> something like that. Experience and/or cynicism say that implementers
>> are quite likely to look at the examples, ignore the text, and
>> misunderstand what's going on if the examples provide convenient
>> semantics not required by the protocol.
>
>
>  [Comment]
> I don't like this change.  Are you sure?
> In some earlier messages, I mentioned that word transmission is **greatly
> preferable* *to broken-word transmission.
> Also, if an implementer misunderstands, this detail is a more harmless
> misunderstanding than broken-word transmission.
>
>  There are other examples in the spec.
>  Comments welcome from people other than Kevin and Gunnar -- I need more
> comments because I have comments that they prefer this Introduction, so I
> need to reconcile conflicting advice about the Introductory example.
>  XEP-0301 permits you to transmit real-time text any way you want:
> character-at-a-time, word-at-a-time, word bursts, original typing
> intervals, time-smoothed, etc.   The Introductory Example is unable to
> demonstrate all of the possible methods.  IMHO, I chose the 'safest'
> introductory example.
>
>  Again, word transmission is greatly preferable over broken-word
> transmission.  (There's been arguments in some accessibility organizations
> in some countries, some say they prefer keypress intervals, some prefer
> word transmission instead of keypresses, etc.)   I am talking to a guy from
> a telco in UK, and he informed me of a political debate.
>
>  Can at least a few more "outsiders" comment on this change, please?
>  Thanks :-)
>
>  I have also noticed occasional theoretical discussions about word
> transmission instead of real-time text. But that just introduces delays.
> Long words can take long time to type on small devices, and many times you
> have benefit of seeing the word created in real-time so that you can keep
> your mind in sync with the sender.
>

We discussed this before.  If a word takes longer than usual to type, you
just simply transmit whatever the word is so far.  It will cause occasional
broken words for those times that people take a long time to compose a
word.   But that's OK.

Even if it could be mentioned somewhere, the spec is about real-time text,
> and the first example, showing the very basic features shall also show a
> realistic example of transmitting real-time text. Not word-by-word.
>

I disagree. There are implementers demanding word transmission.
Your edit is rejected unless there's lots of demand (i.e. 5 people publicly
agreeing with you with no further disagreements in the mailing list)

Word-by-word also have the risk of delaying the last typed word from being
> transmitted. It must have some inactivity timeout and transmit whatever is
> typed if the user just stops typing at the end of a word without any space
> or punctuation mark. In order to not interfere with slow typing, a timeout
> should likely be in the order of 7 seconds. That is an unfortunate extra
> delay in these circumstances.
>

That is not a problem, if you have a time limit for word composition (i.e.
1 second transmission interval, and reset the transmission interval
everytime you hit the spacebar.  So that words come out very quickly, with
no delays more than 1 second)

Please accept the proposals for the first example being a real-time text
> example.
>

I need comments from several people.  There are people (some of Darren
Sturman's colleagues) who would disagree with you.

Thank you,
Mark Rejhon

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

[Gunnar Hellström]

On 2012-07-23 21:17, Mark Rejhon wrote:


Example 1: I suggest that this could be better demonstrated by not
cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or
something like that. Experience and/or cynicism say that implementers
are quite likely to look at the examples, ignore the text, and
misunderstand what's going on if the examples provide convenient
semantics not required by the protocol.


[Comment]
I don't like this change.  Are you sure?
In some earlier messages, I mentioned that word transmission is 
**greatly preferable* *to broken-word transmission.
Also, if an implementer misunderstands, this detail is a more harmless 
misunderstanding than broken-word transmission.


There are other examples in the spec.
Comments welcome from people other than Kevin and Gunnar -- I need 
more comments because I have comments that they prefer this 
Introduction, so I need to reconcile conflicting advice about the 
Introductory example.  XEP-0301 permits you to transmit real-time text 
any way you want: character-at-a-time, word-at-a-time, word bursts, 
original typing intervals, time-smoothed, etc.   The Introductory 
Example is unable to demonstrate all of the possible methods.  IMHO, I 
chose the 'safest' introductory example.


Again, word transmission is greatly preferable over broken-word 
transmission.  (There's been arguments in some accessibility 
organizations in some countries, some say they prefer keypress 
intervals, some prefer word transmission instead of keypresses, etc.) 
  I am talking to a guy from a telco in UK, and he informed me of a 
political debate.


Can at least a few more "outsiders" comment on this change, please? 
 Thanks :-)


I have also noticed occasional theoretical discussions about word 
transmission instead of real-time text. But that just introduces delays. 
Long words can take long time to type on small devices, and many times 
you have benefit of seeing the word created in real-time so that you can 
keep your mind in sync with the sender.


Even if it could be mentioned somewhere, the spec is about real-time 
text, and the first example, showing the very basic features shall also 
show a realistic example of transmitting real-time text. Not word-by-word.


Word-by-word also have the risk of delaying the last typed word from 
being transmitted. It must have some inactivity timeout and transmit 
whatever is typed if the user just stops typing at the end of a word 
without any space or punctuation mark. In order to not interfere with 
slow typing, a timeout should likely be in the order of 7 seconds. That 
is an unfortunate extra delay in these circumstances.



Please accept the proposals for the first example being a real-time text 
example.


Gunnar