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

Any comments from XSF about the new "Processing Rules" section?
http://xmpp.org/extensions/xep-0301.html#processing_rules

On Wed, Apr 10, 2013 at 3:47 PM, Mark Rejhon  wrote:

> 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?
>
> Thanks,
> Mark Rejhon
>

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

On Fri, Apr 12, 2013 at 10:58 AM, Christian Vogler
 wrote:
> I agree - we are all on the same page with respect to randomization, I
> believe. Just a couple of things:
>
> 1. In the face of multiple sign-ons, the clients have different full JIDs
> (or at least, they should). If there is a JID mismatch I treat it as a RTT
> message from a different login and as a loss of sync until the next message
> refresh. It seems that Section 6.6.4.2 encourages this - so maybe it would
> make sense to make this more explicit as part of the processing rules?

Yes, a JID switch can treated as a valid "loss of sync" condition for
a client that keeps track of only one real-time message per window.
However, there are situations (e.g. Multi-User Chat) where you
definitely do want to display multiple real-time messages in the same
window even for simultaneous logins.   I leave it to the implementor
to decide.  Generally, clients that support MUC, would easily be able
to also support concurrent real-time messages coming from separate
full JID's of the same sender.

> 2. I like having a 2**30 space for randomization, rather than 2**20 because
> it makes the sequence a bit more unpredictable. I don't know if it it ever
> will make a difference, but it's one of those things that reduce potential
> attack vectors, and this, in my view is worth the tradeoff of having a few
> extra bytes for the decimal representation of the sequence number with the
> larger space.

RIght.  Though, the bounds of randomization is not mentioned, this is
left as an implementer decision.

Thanks
Mark Rejhon

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

2013-04-12 Thread Christian Vogler

I agree - we are all on the same page with respect to randomization, I
believe. Just a couple of things:

1. In the face of multiple sign-ons, the clients have different full JIDs
(or at least, they should). If there is a JID mismatch I treat it as a RTT
message from a different login and as a loss of sync until the next message
refresh. It seems that Section 6.6.4.2 encourages this - so maybe it would
make sense to make this more explicit as part of the processing rules?

2. I like having a 2**30 space for randomization, rather than 2**20 because
it makes the sequence a bit more unpredictable. I don't know if it it ever
will make a difference, but it's one of those things that reduce potential
attack vectors, and this, in my view is worth the tradeoff of having a few
extra bytes for the decimal representation of the sequence number with the
larger space.

Christian

On Fri, Apr 12, 2013 at 9:52 AM, Mark Rejhon  wrote:

> On Fri, Apr 12, 2013 at 9:47 AM, Mark Rejhon  wrote:
> > On Fri, Apr 12, 2013 at 2:48 AM, Gunnar Hellstrom
> >  wrote:
> >> - on the sender side I limit the maximum random sequence restart number
> to
> >> 2**30.
>
> Chris/Gunnar apologies, I may have mis-read:
> I may have answered as if:
> - on the sender side set sequence restart number to 2**30 (same number
> every time)
> Rather than:
> - on the sender side I limit the range of maximum random sequence
> restart number between 0 and 2**30.
>
> Since you both probably talked about the latter, then that was, of
> course, the intent of the standard to recommend randomization of seq.
>
> 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

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

2013-04-12 Thread 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?

On Fri, Apr 12, 2013 at 9:47 AM, Mark Rejhon  wrote:
> On Fri, Apr 12, 2013 at 2:48 AM, Gunnar Hellstrom
>  wrote:
>> - on the sender side I limit the maximum random sequence restart number to
>> 2**30.

Chris/Gunnar apologies, I may have mis-read:
I may have answered as if:
- on the sender side set sequence restart number to 2**30 (same number
every time)
Rather than:
- on the sender side I limit the range of maximum random sequence
restart number between 0 and 2**30.

Since you both probably talked about the latter, then that was, of
course, the intent of the standard to recommend randomization of seq.

Mark Rejhon

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

On Fri, Apr 12, 2013 at 2:48 AM, Gunnar Hellstrom
 wrote:
> - on the sender side I limit the maximum random sequence restart number to
> 2**30.

Your recommendation of restarting the number is NOT as safe as randomizing.
It increases the chances for collisions (temporary moments of corruption).

Same reason why it's not as recommended to restart seq values to 0
anymore, even though it would work fine for the vast majority of use
cases.

Consider the use case of simultaneous logins.
It's easier to do section "Keeping Real-Time Text Synchronized" if the
seq values of all conflicting senders are dramatically different.
Randomization ensures that the dramatic differences in seq values
happens.  That's for the use case if they don't keep track of separate
real-time messages per full JID, and no, I'm not going to enforce the
"full JID" requirement, since it complicates several implementations
far more than the simple action of randomizing seq.

Mark Rejhon

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

2013-04-12 Thread Christian Vogler

Hi Gunnar,

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


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.

Mark, I have not forgotten about putting up other comments on XEP-0301, but
this will have to wait for a few more days, while I take care of things
that cannot wait.

Best wishes
Christian

-- 
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] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?

2013-04-11 Thread 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 > 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?

2013-04-11 Thread Mark Rejhon

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

On Thu, Apr 11, 2013 at 7:41 PM, Christian Vogler
 wrote:
> 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.

That's a very good choice and should work well, though you could
easily limit to 2**20 to reduce the bandwidth of numbers being
represented as digits in UTF-8 instead of binary. (though after
compression, it might not matter).   I didn't specify a bounds for
randomization in 0.8.  Randomizing to 10,000 less than 2**31 would
also work too.   The smaller the randomization bounds, the bigger
chances of collisions

This mailing list would like to hear more about your XEP-0301
implementation(s), whenever you're ready to talk about it.
In addition, do you have any major comments in regards to the XEP-0301
spec that's currently published?

Thanks!
Mark Rejhon

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

2013-04-11 Thread Christian Vogler

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.

Christian


On Thu, Apr 11, 2013 at 7:14 PM, Mark Rejhon  wrote:

> Regarding:
> http://xmpp.org/extensions/xep-0301.html
>
>
> On Thu, Apr 11, 2013 at 4:45 PM, Gunnar Hellstrom
>  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."
>
> 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.
>
> 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

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

2013-04-11 Thread Mark Rejhon

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

On Thu, Apr 11, 2013 at 4:45 PM, Gunnar Hellstrom
 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."

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.

Thanks,
Mark Rejhon

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

2013-04-11 Thread 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

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

2013-04-10 Thread 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] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?

2013-04-10 Thread Mark Rejhon

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?

Thanks,
Mark Rejhon

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

2012-08-14 Thread Gunnar Hellström



Some comments on your comments included.
Issues where I find your proposals acceptable are deleted.

On 2012-08-13 17:29, Mark Rejhon wrote:

[ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ]

Hello Gunnar,

Thanks very much for the minor corrections to XEP-0301.  I have queued
your edits.  My present judgement is that your edits are safely queued
until LC, however, I'd like comments from other key XSF members:
There is ONE bullet meriting further discussion.  Talk related to
section 6.2 Activation/Deactivation.  Especially if
Kevin/Peter/M&M/etc has major comments about section 6.2 ... though
Kevin says it didn't need to be relocated to a "Business Rules"
section, and therefore is okay where it is for LC, I'm told.  But does
M&M disagree, for example?


On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström
 wrote:

3.   6.2.1 Activation guidelines

Can we really accept the weak indication that discovery is recommended? I think 
it shall be mandated.

Proposal:
c/Before sending real-time text, it is preferable for a sender client
to/Before sending real-time text, a sender client SHALL/

[Comment]
Peter told me that RFC2119 normatives do not belong in "Implementation Notes".
Therefore, if RFC2119 is used, the whole section 6.2 would
automatically need a relocation upwards closer to "Protocol" instead
of "Implementation Notes".
I'm open to suggestions by others, such as moving to a "Business
Rules" section (just below "Discovering Support" and above
"Implementation Notes")  However, Kevin of XSF said that it is fine
where it is.  However, I agree this is an item meriting some
discussion, though I'm not 100% sure if this needs to be addressed
before LC.
(Comments from others?  Does it?)
Section 6.2: 
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text

Right, I forgot about the informational chapter.
It sounds very strange with the "preferably" for a protocol element like 
this.  It does not match the stronger language of chapter 5.


The mentioning of discovery in 6.2 is in fact redundant. It is already 
described in chapter 5. Let us separate the topics into service 
discovery in chapter 5 and Activation in section 6.2

I suggest a change in 6.2.1:

s/Before sending real-time text, it is preferable for a sender client to 
explicitly discover whether the recipient client supports the protocol 
defined herein (using Determining Support <#determining_support>). In 
the absence of explicit discovery or negotiation, the sender client can 
implicitly request and discover the use of real-time text, by sending 
 upon activation./The sender client can request the 
use of real-time text, by sending  upon activation./

8.  4.1 xml:lang
Describe explicit or implicit use of the xml:lang attribute similarly as it
is described for  in RFC 6221.
This attribute can introduce alternative language variants of the text in
messages and other elements.
The use is described in RFC 6221.
For XEP-0301 it would be natural to offer the same opportunity to provide
the alternative languages in the same message.
This would at least go into section 4.2 RTT attributes and 4.5.3.1 
element

Each language will have its own editing elements and values, so the xml:lang
attribute should be on the  level.

I propose insertion a new subsection in 4.2
---
4.2.4 Language
Multiple instances of the  element MAY be included in a message stanza
for the purpose of providing alternate versions of the same real-time text,
but only if each instance possesses an 'xml:lang' attribute with a distinct
language value (either explicitly or by inheritance from the 'xml:lang'
value of an element farther up in the XML hierarchy, which from the sender's
perspective can include the XML stream header as described in RFC 6220 [
]). The support for language variants SHALL follow the principles of support
for language variants in message bodies specified in RFC 6221[   ].

This example provides a small part of real-time text in the default language
English and the alternative language Check.


   tho
ty
  

--
The second line from the bottom of 4.1 should be changed from
"There MUST NOT be more than one  element per  stanza."
to
"There MUST NOT be more than one  element per language variant in each
 stanza."
[Comment]
My judgement is I'm going to leave this out because it is a
non-typical case of real-time text.  People aren't going to send
multiple languages simultaneously, as people can't type in more than
one language simultaneously.   It is an edge case that would be useful
for things like European Union transcriptions and/or United Nations
transcriptions.   From what I can see, this edge case is easily
handled simply either by having se

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Logic of example 1.

2012-08-14 Thread Gunnar Hellström


On 2012-08-14 03:09, Mark Rejhon wrote:


Barry may have presented a compromise I can accept.  The first 
(introductory) stanza is still full word, and the second and third is 
not too difficult for most readers to figure out.


On 2012-08-13 8:44 PM, "Barry Dingle" > wrote:


Mark,

Regarding the example in 4.1, I agree with Gunnar. The first
example gives the wrong initial impression by sending only
complete words in the . (It made me go and double check how
the protocol worked.)

I suggest that we keep the first  as is, but slightly change
the second and third  text contents to:

*my J***

and

*uliet!*

respectively.

This retains the readability but also shows that the  is
sent independently of word boundaries.

Cheers,
/Barry



This was item #5  Let us try to keep track of the issue numbers and 
their state.


I accept the solution.

/Gunnar

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

2012-08-13 Thread Mark Rejhon

Barry may have presented a compromise I can accept.  The first
(introductory) stanza is still full word, and the second and third is not
too difficult for most readers to figure out.
 On 2012-08-13 8:44 PM, "Barry Dingle"  wrote:

> Mark,
>
> Regarding the example in 4.1, I agree with Gunnar. The first example gives
> the wrong initial impression by sending only complete words in the .
> (It made me go and double check how the protocol worked.)
>
> I suggest that we keep the first  as is, but slightly change the
> second and third  text contents to:
>
> *my J***
>
> and
>
> *uliet!*
>
> respectively.
>
> This retains the readability but also shows that the  is sent
> independently of word boundaries.
>
> Cheers,
> /Barry
>
> Barry Dingle
> Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578
> Fellow of University of Melbourne, Electrical and Electronic Eng.,
> Australia
> > Apple + Linux + Open Source software
>
>
> On Tue, Aug 14, 2012 at 1:29 AM, Mark Rejhon  wrote:
>
>> [ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ]
>>
>> Hello Gunnar,
>>
>> Thanks very much for the minor corrections to XEP-0301.  I have queued
>> your edits.  My present judgement is that your edits are safely queued
>> until LC, however, I'd like comments from other key XSF members:
>> There is ONE bullet meriting further discussion.  Talk related to
>> section 6.2 Activation/Deactivation.  Especially if
>> Kevin/Peter/M&M/etc has major comments about section 6.2 ... though
>> Kevin says it didn't need to be relocated to a "Business Rules"
>> section, and therefore is okay where it is for LC, I'm told.  But does
>> M&M disagree, for example?
>>
>>
>> On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström
>>  wrote:
>> > 1.   4.2.3 id
>> > The text should start with a description of what function this attribute
>> > supports.  Insert after the title:
>> > "The id attribute is used to enable real-time correction of the last
>> completed message."
>>
>> [Minor Clarification Change]
>> Good suggestion. I'll queue this edit till LC.
>> (unless a 0.8 is warranted prior, e.g. comments from m&m/peter/kevin et
>> cetra)
>>
>>
>> > Insert the title of XEP-0308
>> > XEP-0308 Last message correction
>> > 2.  4.2.3 id
>> > On second line. Reception must always be supported if both 0308 and
>> 0301 are
>> > supported. c/MUST use this attribute if/MUST support reception of this
>> attribute, and
>> > MUST transmit this attribute if/
>>
>> [Minor Clarification Change]
>> Clients that support incoming corrections don't necessarily do
>> outgoing corrections. Therefore, a different change is better:
>> c/clients MUST use this attribute if/clients MUST support this
>> attribute in situations where/
>> I'll queue this edit, too.
>>
>>
>> > 3.   6.2.1 Activation guidelines
>> >
>> > Can we really accept the weak indication that discovery is recommended?
>> I think it shall be mandated.
>> >
>> > Proposal:
>> > c/Before sending real-time text, it is preferable for a sender client
>> > to/Before sending real-time text, a sender client SHALL/
>>
>> [Comment]
>> Peter told me that RFC2119 normatives do not belong in "Implementation
>> Notes".
>> Therefore, if RFC2119 is used, the whole section 6.2 would
>> automatically need a relocation upwards closer to "Protocol" instead
>> of "Implementation Notes".
>> I'm open to suggestions by others, such as moving to a "Business
>> Rules" section (just below "Discovering Support" and above
>> "Implementation Notes")  However, Kevin of XSF said that it is fine
>> where it is.  However, I agree this is an item meriting some
>> discussion, though I'm not 100% sure if this needs to be addressed
>> before LC.
>> (Comments from others?  Does it?)
>> Section 6.2:
>> http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text
>>
>>
>> > 4. Section 1, intro, last bullet point, to make the description of
>> REACH112
>> > correct.:
>> > c/A component within Total Conversation, used by Reach112 [4] in
>> Europe, an
>> > accessible emergency service with real-time text./The real-time text
>> > component within Total Conversation, for example used by Reach112 [4] in
>> > Europe, a project for accessible communication services including
>> emergency
>> > service.
>>
>> [Minor Clarification Change]
>> Thanks for the Reach112 clarification.  I'll queue this edit, too.
>>
>>
>> > 5. Section 4.1 Example 1 should have a more natural distribution of
>> letters
>> > in the different  elements, appearing from the transmission in
>> regular
>> > intervals as specified in section 4.1. This comment has been made from
>> > different sources a number of times.
>>
>> [Comment]
>> I already mentioned that the existing example is more readable to a
>> wider variety of less experienced people.  The smart people (like us)
>> will figure it out just fine, and the other examples illustrate this
>> already.   I'm going to cater for the majority here.
>>
>>
>> > 6. 4.7 Third paragraph. Language correction. This is a

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

2012-08-13 Thread Barry Dingle

Mark,

Regarding the example in 4.1, I agree with Gunnar. The first example gives
the wrong initial impression by sending only complete words in the .
(It made me go and double check how the protocol worked.)

I suggest that we keep the first  as is, but slightly change the
second and third  text contents to:

*my J***

and

*uliet!*

respectively.

This retains the readability but also shows that the  is sent
independently of word boundaries.

Cheers,
/Barry

Barry Dingle
Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng.,
Australia
> Apple + Linux + Open Source software


On Tue, Aug 14, 2012 at 1:29 AM, Mark Rejhon  wrote:

> [ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ]
>
> Hello Gunnar,
>
> Thanks very much for the minor corrections to XEP-0301.  I have queued
> your edits.  My present judgement is that your edits are safely queued
> until LC, however, I'd like comments from other key XSF members:
> There is ONE bullet meriting further discussion.  Talk related to
> section 6.2 Activation/Deactivation.  Especially if
> Kevin/Peter/M&M/etc has major comments about section 6.2 ... though
> Kevin says it didn't need to be relocated to a "Business Rules"
> section, and therefore is okay where it is for LC, I'm told.  But does
> M&M disagree, for example?
>
>
> On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström
>  wrote:
> > 1.   4.2.3 id
> > The text should start with a description of what function this attribute
> > supports.  Insert after the title:
> > "The id attribute is used to enable real-time correction of the last
> completed message."
>
> [Minor Clarification Change]
> Good suggestion. I'll queue this edit till LC.
> (unless a 0.8 is warranted prior, e.g. comments from m&m/peter/kevin et
> cetra)
>
>
> > Insert the title of XEP-0308
> > XEP-0308 Last message correction
> > 2.  4.2.3 id
> > On second line. Reception must always be supported if both 0308 and 0301
> are
> > supported. c/MUST use this attribute if/MUST support reception of this
> attribute, and
> > MUST transmit this attribute if/
>
> [Minor Clarification Change]
> Clients that support incoming corrections don't necessarily do
> outgoing corrections. Therefore, a different change is better:
> c/clients MUST use this attribute if/clients MUST support this
> attribute in situations where/
> I'll queue this edit, too.
>
>
> > 3.   6.2.1 Activation guidelines
> >
> > Can we really accept the weak indication that discovery is recommended?
> I think it shall be mandated.
> >
> > Proposal:
> > c/Before sending real-time text, it is preferable for a sender client
> > to/Before sending real-time text, a sender client SHALL/
>
> [Comment]
> Peter told me that RFC2119 normatives do not belong in "Implementation
> Notes".
> Therefore, if RFC2119 is used, the whole section 6.2 would
> automatically need a relocation upwards closer to "Protocol" instead
> of "Implementation Notes".
> I'm open to suggestions by others, such as moving to a "Business
> Rules" section (just below "Discovering Support" and above
> "Implementation Notes")  However, Kevin of XSF said that it is fine
> where it is.  However, I agree this is an item meriting some
> discussion, though I'm not 100% sure if this needs to be addressed
> before LC.
> (Comments from others?  Does it?)
> Section 6.2:
> http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text
>
>
> > 4. Section 1, intro, last bullet point, to make the description of
> REACH112
> > correct.:
> > c/A component within Total Conversation, used by Reach112 [4] in Europe,
> an
> > accessible emergency service with real-time text./The real-time text
> > component within Total Conversation, for example used by Reach112 [4] in
> > Europe, a project for accessible communication services including
> emergency
> > service.
>
> [Minor Clarification Change]
> Thanks for the Reach112 clarification.  I'll queue this edit, too.
>
>
> > 5. Section 4.1 Example 1 should have a more natural distribution of
> letters
> > in the different  elements, appearing from the transmission in
> regular
> > intervals as specified in section 4.1. This comment has been made from
> > different sources a number of times.
>
> [Comment]
> I already mentioned that the existing example is more readable to a
> wider variety of less experienced people.  The smart people (like us)
> will figure it out just fine, and the other examples illustrate this
> already.   I'm going to cater for the majority here.
>
>
> > 6. 4.7 Third paragraph. Language correction. This is an enumeration of
> only
> > two elements. Connect them with or instead of comma:
> > s/ messages, incorrect/ messages or incorrect/
>
> [Minor Grammar]
> Thanks, I'll queue this edit, too.
> Note that "e.g." represents partial list of examples, and
> automatically assumes "etc." at the end.  So there are other
> situations as well, so it's not just two.  Even though only two are
> l

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

2012-08-13 Thread Mark Rejhon

[ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ]

Hello Gunnar,

Thanks very much for the minor corrections to XEP-0301.  I have queued
your edits.  My present judgement is that your edits are safely queued
until LC, however, I'd like comments from other key XSF members:
There is ONE bullet meriting further discussion.  Talk related to
section 6.2 Activation/Deactivation.  Especially if
Kevin/Peter/M&M/etc has major comments about section 6.2 ... though
Kevin says it didn't need to be relocated to a "Business Rules"
section, and therefore is okay where it is for LC, I'm told.  But does
M&M disagree, for example?

On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström
 wrote:
> 1.   4.2.3 id
> The text should start with a description of what function this attribute
> supports.  Insert after the title:
> "The id attribute is used to enable real-time correction of the last 
> completed message."

[Minor Clarification Change]
Good suggestion. I'll queue this edit till LC.
(unless a 0.8 is warranted prior, e.g. comments from m&m/peter/kevin et cetra)

> Insert the title of XEP-0308
> XEP-0308 Last message correction
> 2.  4.2.3 id
> On second line. Reception must always be supported if both 0308 and 0301 are
> supported. c/MUST use this attribute if/MUST support reception of this 
> attribute, and
> MUST transmit this attribute if/

[Minor Clarification Change]
Clients that support incoming corrections don't necessarily do
outgoing corrections. Therefore, a different change is better:
c/clients MUST use this attribute if/clients MUST support this
attribute in situations where/
I'll queue this edit, too.

> 3.   6.2.1 Activation guidelines
>
> Can we really accept the weak indication that discovery is recommended? I 
> think it shall be mandated.
>
> Proposal:
> c/Before sending real-time text, it is preferable for a sender client
> to/Before sending real-time text, a sender client SHALL/

[Comment]
Peter told me that RFC2119 normatives do not belong in "Implementation Notes".
Therefore, if RFC2119 is used, the whole section 6.2 would
automatically need a relocation upwards closer to "Protocol" instead
of "Implementation Notes".
I'm open to suggestions by others, such as moving to a "Business
Rules" section (just below "Discovering Support" and above
"Implementation Notes")  However, Kevin of XSF said that it is fine
where it is.  However, I agree this is an item meriting some
discussion, though I'm not 100% sure if this needs to be addressed
before LC.
(Comments from others?  Does it?)
Section 6.2: 
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text

> 4. Section 1, intro, last bullet point, to make the description of REACH112
> correct.:
> c/A component within Total Conversation, used by Reach112 [4] in Europe, an
> accessible emergency service with real-time text./The real-time text
> component within Total Conversation, for example used by Reach112 [4] in
> Europe, a project for accessible communication services including emergency
> service.

[Minor Clarification Change]
Thanks for the Reach112 clarification.  I'll queue this edit, too.

> 5. Section 4.1 Example 1 should have a more natural distribution of letters
> in the different  elements, appearing from the transmission in regular
> intervals as specified in section 4.1. This comment has been made from
> different sources a number of times.

[Comment]
I already mentioned that the existing example is more readable to a
wider variety of less experienced people.  The smart people (like us)
will figure it out just fine, and the other examples illustrate this
already.   I'm going to cater for the majority here.

> 6. 4.7 Third paragraph. Language correction. This is an enumeration of only
> two elements. Connect them with or instead of comma:
> s/ messages, incorrect/ messages or incorrect/

[Minor Grammar]
Thanks, I'll queue this edit, too.
Note that "e.g." represents partial list of examples, and
automatically assumes "etc." at the end.  So there are other
situations as well, so it's not just two.  Even though only two are
listed.

> 7. Appendix G:
> 4 s/ Reach112: European emergency service with real-time text./ Reach112:
> European accessible communication and emergency service project with total
> conversation including real-time text./

[Minor Clarification Change]
Thanks for the Reach112 clarification.  I'll queue this edit, too.

> 8.  4.1 xml:lang
> Describe explicit or implicit use of the xml:lang attribute similarly as it
> is described for  in RFC 6221.
> This attribute can introduce alternative language variants of the text in
> messages and other elements.
> The use is described in RFC 6221.
> For XEP-0301 it would be natural to offer the same opportunity to provide
> the alternative languages in the same message.
> This would at least go into section 4.2 RTT attributes and 4.5.3.1 
> element
>
> Each language will have its own editing elements and values, so the xml:lang
> attribute should

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

2012-08-12 Thread Gunnar Hellström


On 2012-08-09 17:09, XMPP Extensions Editor wrote:

Version 0.7 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.

Changelog: Simplifications and grammatical corrections. Some sections (1, 6.2, 
6.4) shortened with simpler language. (MDR)

Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.6/vs/0.7

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



Very good to see many of the discussed issues resolved in version 0.7.
Here are my findings in reviewing version 0.7.

---
1.   4.2.3 id
The text should start with a description of what function this attribute 
supports.


Insert after the title:
"The id attribute is used to enable real-time correction of the last 
completed message."


Insert the title of XEP-0308
XEP-0308 Last message correction

2.  4.2.3 id
On second line. Reception must always be supported if both 0308 and 0301 
are supported.
c/MUST use this attribute if/MUST support reception of this attribute, 
and MUST transmit this attribute if/


3.   6.2.1 Activation guidelines

Can we really accept the weak indication that discovery is recommended? 
I think it shall be mandated.


Proposal:
c/Before sending real-time text, it ispreferable for a sender client 
to/Before sending real-time text, a sender client SHALL/



4. Section 1, intro, last bullet point, to make the description of 
REACH112 correct.:
c/A component within Total Conversation, used byReach112 
[4 
] in 
Europe, an accessible emergency service with real-time text./The 
real-time text component within Total Conversation, for example used 
byReach112 [4 
] in 
Europe, a project for accessible communication services including 
emergency service.


5. Section 4.1 Example 1 should have a more natural distribution of 
letters in the different  elements, appearing from the 
transmission in regular intervals as specified in section 4.1. This 
comment has been made from different sources a number of times.


6. 4.7 Third paragraph. Language correction. This is an enumeration of 
only two elements. Connect them with or instead of comma:

s/messages, incorrect/messages or incorrect/

7. Appendix G:
4 s/Reach112: European emergency service with real-time text./Reach112: 
European accessible communication and emergency service project with 
total conversation including real-time text./


8.  4.1 xml:lang
Describe explicit or implicit use of the xml:lang attribute similarly as 
it is described for  in RFC 6221.
This attribute can introduce alternative language variants of the text 
in messages and other elements.

The use is described in RFC 6221.
For XEP-0301 it would be natural to offer the same opportunity to 
provide the alternative languages in the same message.


This would at least go into section 4.2 RTT attributes and 4.5.3.1  
element


Each language will have its own editing elements and values, so the 
xml:lang attribute should be on the  level.


I propose insertion a new subsection in 4.2
---
4.2.4 Language
Multiple instances of the  element MAY be included in a message 
stanza for the purpose of providing alternate versions of the same 
real-time text, but only if each instance possesses an 'xml:lang' 
attribute with a distinct language value (either explicitly or by 
inheritance from the 'xml:lang' value of an element farther up in the 
XML hierarchy, which from the sender's perspective can include the XML 
stream header as described in RFC 6220 [   ]). The support for language 
variants SHALL follow the principles of support for language variants in 
message bodies specified in RFC 6221[   ].


This example provides a small part of real-time text in the default 
language English and the alternative language Check.



  tho
   ty
 

--
The second line from the bottom of 4.1 should be changed from
"There MUST NOT be more than one  element per  stanza."
to
"There MUST NOT be more than one  element per language variant in 
each  stanza."



10. Appendix A, dependencies need updating.
[Discussion]
Dependencies: now only contain XMPP Core and XEP-0020.
XEP-0020 seems not to be used anymore, but at least XMPP IM, XEP-0030, 
XEP-0085, XEP-0115, XEP-0308


[Proposal]
Appendix A, dependencies,
s/XMPP Core, XEP-020/XMPP Core, XMPP IM XEP-0030, XEP--0085, XEP-0115, 
XEP-0308/


11. Appendix A. A short name should be assigned.
[Discussion]
Some possible short names:

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

2012-07-23 Thread Gunnar Hellström


On 2012-07-23 10:13, Kevin Smith wrote:

On Sun, Jul 22, 2012 at 11:00 PM, Gunnar Hellström
 wrote:

Yes, good to distinguish between service discovery, and activating support.
There is something missing in a sentence in version 0.4, chapter 5.
In order for an application to determine whether an entity supports this
protocol, where possible it SHOULD use the dynamic, presence-based profile
of service discovery defined in .


What was your intention after "in"?

I suspect you're looking at the xepdiff tool - some things don't get
correctly marked and one of them is sometimes that references won't be
rendered in the diff.

/K

Right, that was the reason.
Thanks

Gunnar

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

2012-07-23 Thread Kevin Smith

On Sun, Jul 22, 2012 at 11:00 PM, Gunnar Hellström
 wrote:
> Yes, good to distinguish between service discovery, and activating support.
> There is something missing in a sentence in version 0.4, chapter 5.
> In order for an application to determine whether an entity supports this
> protocol, where possible it SHOULD use the dynamic, presence-based profile
> of service discovery defined in .
>
>
> What was your intention after "in"?

I suspect you're looking at the xepdiff tool - some things don't get
correctly marked and one of them is sometimes that references won't be
rendered in the diff.

/K

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

2012-07-22 Thread Mark Rejhon

On Mon, Jul 23, 2012 at 12:17 AM, Mark Rejhon  wrote:

>  19. Edit deferred -- Explanation given in previous email. It helps
>>> reader associate WHICH definition of "character" we are using. Even the
>>> RFC's say that the word has multiple interpretations, so it's appropriate
>>> here in the title. The title is like a glossary entry, and the contents
>>> explain we're using code points as the method of counting characters.
>>>
>>  I still regard this dangerous and confusing. We are counting Unicode
>> code points, and that needs to be clear in all explanations.
>>
>
> We will have to agree to disagree -- I think it's safer and less confusing:
> Did you know there are 47 occurances of the word "character" in the whole
> document?
>
> Therefore, I prefer not to remove the word "Character" in the heading
> "Unicode Character Counting".  Thus, it is like the heading of an extended
> *glossary* definition here -- and it is in my opinion safer and less
> confusing.   Obviously, the section is too big to move to the glossary
> section, but I am open to alternate ideas of defining the word "character"
> from this mailing list.
> For this, I defer to public comment (once 0.5 is up).
>

Referring to: http://unicode.org/glossary/ , which says the following:

*Code Point *. (1) Any value in
the Unicode codespace; that is, the range of integers from 0 to 1016.
(See definition D10 in Section 3.4, Characters and
Encoding.)
Not all code points are assigned to encoded characters. See *code
point type
*. (2) *A value, or position, for a character, in any coded character set.*


Other rationale:
- Other XEP's use "character" terminology
- People are already familiar with "character" terminology.
- There's 47 occurances of word "character" in XEP-0301  (e.g.
"...Remove 1 character from...")
- Search-Replace all of them into "code points" would make document _even_
more confusing to those who are not familiar with "code point" terminology.
- Therefore, I feel that the lesser of evil is to treat "Unicode Character
Counting" as a definition of XEP-0301's use of the word "character". If an
implementer makes an error in interpreting the word "character" this this
section clarifies it.
- If several people here agree with Gunnar that "Unicode Character
Counting" should be renamed to "Unicode Code Point Counting", they would
probably also agree that the word still needs to be defined somewhere else
-- such as in the Glossary section.  (defining the word "character" from
the perspective of XEP-0301, since "character" has multiple
interpretations, so it is necessary to define the word "character", and I
chose "Unicode Character Counting" as the definition of "character")  I
am open to alternative methods of defining "character", but it needs to be
less confusing, not even more confusing.

I'd like to hear opinions from others about this matter, as well as general
comments about "Accurate Processing of Action Elements" (of which "Unicode
Character Counting" is included within).
http://xmpp.org/extensions/xep-0301.html#accurate_processing_of_action_elements

Thanks,
Mark Rejhon

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

2012-07-22 Thread Mark Rejhon

On Sun, Jul 22, 2012 at 11:11 PM, XMPP Extensions Editor wrote:

> Version 0.5 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.
> Changelog: Minor corrections and clarifications. (MDR)
> Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.4/vs/0.5
> URL: http://xmpp.org/extensions/xep-0301.html

Oh wow, just as a click "Send", this pops up in my Inbox.

This 0.5 spec incorporates the vast majority of Gunnar's suggestions.
0.5 diff is about 10 times less cluttered than diff 0.3->04
0.5 diff is about 100 times less cluttered than diff 0.2->0.3
So, I feel it is "getting there" to maturity.

Even so, the spec is largely backward compatible all the way back to 0.0.2,
despite some protocol changes since.  (I know it didn't need to stay
compatible during Experimental, but it happens most changes apparently
didn't affect compatibility.  I hope this is an indication of a protocol
that is mature enough to not even need any dramatic changes.)

I'd like comments from key people (Peter, Kevin, Matt, etc), to review the
whole specification, as well as review my reply to Gunnar.   Is it ready
for LAST CALL?

Thanks,
Mark Rejhon

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

2012-07-22 Thread Mark Rejhon

(Peter, please go ahead and proceed to publish 0.5 I submitted ASAP -- so
that people have context when reading this.   Fixes can go into 0.6, if
deemed important)

On Sun, Jul 22, 2012 at 6:00 PM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

>  11. Section 4.1, Example 1, Line 9 ,  make the text part "my Ju"  ,  so
>> that it is obvious that it is not about word by word transmission.
>> 12. Section 4.1, Example 1, Line 15 ,  make the text part "liet" only,
>> so that it is obvious that it is not about word by word transmission.
>>
>   13. Section 4.2.2 event='new' third line.  change "display, and then
>> process" to "reception, and then process text and". Because we must not
>> assume that all applications display the text. "
>>
>
>  11/12. Edit Deferred -- It is merely an introductory example. Also, if
> people chunk text instead of preserving key press intervals, then
> whole-word burst transmission is greatly preferred over broken-word burst
> transmission.
>
> But why do you want to confuse the reader with giving the impression that
> transmission is word-wise, when it is time-sampled in reality. I suggest to
> accept my edit proposal in order to not cause wrong impression what it is
> all about.
>

It's all a matter of perspective -- It is relative.  I suspect more than
half of people here would agree your suggestion is NOT simpler in this case
because:
... Primary reason: My opinion is that the first introductory example MUST
be as simple as possible.  I think most would agree with me here.  There is
no wrong impression to convey here, because other subsequent examples are
self explanatory on what's allowed (breaking up text, turning things into
single keypresses, key press intervals, and the new example I added to
v0.5, really makes it much easier to understand key press intervals.).  But
the bottom line, it is an introductory example, and the introductory
example must be as simple as possible to explain.
... Secondary explanation:  When displayed in forced-color-code XML on the
website (i.e. published at
http://www.xmpp.org/extensions/xep-0301.html)... the transmitted
real-time text words are no longer separately
color-highlighted like the draft copy in the Word version.  So the full
words make them easier to glance out than if they are fragmented words, too.
... Tertiary explanation: We need to view this specification from a less
experienced developer perspective. People who are less experienced with
protocols (we are protocol authors, other people are not), need to be able
to see the simplest possible example (see primary rason)
(Even if you only agree with one or two of the above reasons, that should
be good enough, no?)

18. Consider deleting the "Forward Delete" d action element. It cannot be
> used with the default value for p because that would point outside the
> real-time message. Therefore, a p must always be calculated and included.
> Then it is equal in complexity to use it as Backspace. Having both just
> seem to add complexity to implementations. ( It would have been different
> and of value if it worked from a current cursor position.)   But if you
> have good reasons, e.g. easily matching some editing operation result, you
> can keep it.
>
> 18. Edit deferred -- Explanation given in long email.
>
> Forward delete just introduces complexity. Since you do not have the
> concept of "current position" in the specification, a forward delete and a
> backspace of anything else than the last character are equally long in
> coding.  But, if you want to have these two codings of the same operation,
> I can accept it.
>

About complexity: It only adds 5 lines of complexity to the implementation:
http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java?r=24#551

About reasoning:
... Reason 1. There are situations where it made a lot of sense to have the
two separate, including recipient-side time-smoothed display which was
something you also suggested.  For example,  can
be automatically converted to the equivalent  for
time-smoothed display with the cursor animated backwards.  And  can automatically be converted to the equivalent  for time-smoothed display with
the cursor staying stationary.   If we merged the two, then we can't have
distinctive time-smoothed display of either. (As I recall, you're a strong
proponent of time-smoothed display)  But of course, it might not be that
important, even to you.
... Reason 2. Ability to do accurate journalling of edits, for emergency
purposes.  However, this reason can become moot, especially if we're not
using the 'n' argument, since a single-character backspace transmitted can
be indistinguishable from a single-character delete operation (even for
time-smoothed display).
... Reason 3. It slightly simplifies "Monitoring Key Presses Directly" for
senders
http://xmpp.org/extensions/xep-0301.html#monitoring_key_presses_directly ...
(I know that's not the preferred method)
... Reason 4. It simplifies visualizing o

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

2012-07-22 Thread Gunnar Hellström


On 2012-07-22 03:19, Mark Rejhon wrote:


Hello XSF members (Peter and Kevin, et cetra)

I incorporated Gunnar's edit today.  Do you prefer I submit an 0.5 
immediately before you review?  The only changes I did were editorial 
-- word edits, phrase edits and sentence edits/moves, in approximately 
15 locations, no protocol changes over 0.4.




Mark, thanks for taking the trouble to transpose my edit proposals to 
0.4 and creating and submitting 0.5.
Even if there are a few remaing items I am not in total agreement with 
you about, I think these could either be accepted as you have proposed 
them or be accepted as editorial changes during a last call.


See some comments on these below. ( stille referring to 0.3 section 
numbering)




11. Section 4.1, Example 1, Line 9 ,  make the text part "my Ju" 
,  so that it is obvious that it is not about word by word

transmission.
12. Section 4.1, Example 1, Line 15 ,  make the text part "liet"
only,   so that it is obvious that it is not about word by word
transmission.

13. Section 4.2.2 event='new' third line.  change "display, and
then process" to "reception, and then process text and".
Because we must not assume that all applications display the text. "


11/12. Edit Deferred -- It is merely an introductory example. Also, if 
people chunk text instead of preserving key press intervals, then 
whole-word burst transmission is greatly preferred over broken-word 
burst transmission.
But why do you want to confuse the reader with giving the impression 
that transmission is word-wise, when it is time-sampled in reality. I 
suggest to accept my edit proposal in order to not cause wrong 
impression what it is all about.


13. Edit Deferred -- It's a great suggestion in theory, but in all 
practicality, the change is too confusing. Most implementers of 
blind-assistive software will figure out "display" means "reception" 
or "present to the user"   The word "display" is pretty standard 
in many XEP's, from a search I did. Even it's an XML element in some, 
i.e. XEP-0202 (A Final standard) uses a  element.
I was thinking of non-displaying software as gateways, 
multi-party-bridges, applications etc. They never "initialize a new 
real-time message for display". But I can accept your proposal. The 
final intention is in most cases to display.


14. Section 4.2.2 event='cancel'.  How does this behave through
multi-user chat and multiple login situations? Is the
event='cancel' sent through to all? I see a risk that one user
sending event='cancel' would turn off rtt for all recipients. If
this is true, I see three solutions:
a) Delete event='cancel'. b) Add a sentence saying "event='cancel'
SHALL not be used in a MUC or multi-login session.  c) Add a
sentence saying "event='cancel' SHOULD be ignored in MUC and
multi-login sessions.
I have a slight preference for solution a), to delete cancel from
the specification.

If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing
with "cancel" shall be deleted.


14. Explanation -- Cancel is critical to the needs of several 
implementers. See Activating/Deactivating text section 
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text  
Also, cancel is 100% appropriate for multi-login session.   I 
clarified the MUC chapter to say that cancel should not deactivate 
outgoing transmission since it would allow one participant to suppress 
real-time text between other willing participants.  (senders may still 
use it, in order to discard their unfinished real-time message when 
logging off, etc)
However, an edit was made to the Activation/Deactivation section to 
clarify cancel behaviour during Multi-User Chat.

[2 sentences modified]


I need to see this before judging.



18. Consider deleting the "Forward Delete" d action element. It cannot 
be used with the default value for p because that would point outside 
the real-time message. Therefore, a p must always be calculated and 
included. Then it is equal in complexity to use it as Backspace. 
Having both just seem to add complexity to implementations. ( It would 
have been different and of value if it worked from a current cursor 
position.)   But if you have good reasons, e.g. easily matching some 
editing operation result, you can keep it.



18. Edit deferred -- Explanation given in long email.


Forward delete just introduces complexity. Since you do not have the 
concept of "current position" in the specification, a forward delete and 
a backspace of anything else than the last character are equally long in 
coding.
But, if you want to have these two codings of the same operation, I can 
accept it.





19. Section 4.5.2, third bullet point. I would like to see the
words "Unicode Code Points" replace "Unicode Character Counting".
Code points is the safe base that we count.
20. Section 4.5.4.1 At the end, insert paragraph: "Chara

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

2012-07-21 Thread Peter Saint-Andre

On 7/21/12 7:19 PM, Mark Rejhon wrote:
> Hello XSF members (Peter and Kevin, et cetra)
> 
> I incorporated Gunnar's edit today.  Do you prefer I submit an 0.5
> immediately before you review?  The only changes I did were editorial --
> word edits, phrase edits and sentence edits/moves, in approximately 15
> locations, no protocol changes over 0.4.

I see no harm in publishing 0.5 -- that way, folks will be reviewing the
latest and greatest.

Peter

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

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

Hello XSF members (Peter and Kevin, et cetra)

I incorporated Gunnar's edit today.  Do you prefer I submit an 0.5
immediately before you review?  The only changes I did were editorial --
word edits, phrase edits and sentence edits/moves, in approximately 15
locations, no protocol changes over 0.4.

On Sat, Jul 21, 2012 at 1:46 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

>  1.  Chapter 1, last line:  Move last sentence first. And make an empty
> line after it. Now it takes the whole chapter before we get to know what
> the specification is about.
>
2. Chapter 1, last bullet point. Change to: " As one medium in Total
> Conversation, e.g. deployed in the European project REACH112 [5] for
> accessible communication and emergency service."
> Motivation: ( Total conversation was the theme. It was
> about both person-to-person and emergency service)
> 3. Section 2.1, point 4.   add "and replication" after "transmission".  (
> just transmission is not sufficient for the intended effect.)
> 4. Section 2.2, point 3. change "traversal protocols" to "traversal
> mechanisms",   because they are more mechanisms than protocols.
>

1. Done [1 sentence move] -- Barry recommended it be a standalone sentence,
too.
2. Done [1 sentence edit] -- Made similiar but not identical edit
3. Done [2 words added] -- I used "and reproduction"
4. Done [1 word edit] -- Verbatim edit

 5. Section 2.4, Title. Change to "Usable for mainstream and accessibility
> purposes."
>
6. Section 2.4, point 1. Change word "accessibility" to "service
> description".   Because F.703 is a general standard. The total conversation
> part is of accessibility interest.
> 7. Chapter 3,  Real-time text. Change "in real time" to "instantly" , to
> match definition in chapter 1.
> 8. Chapter 3, Add "JID" and its explanation.
>

5. Edit deferred -- explanation given in earlier email message.
6. Done [1 word removed] -- I removed the word "accessibility"
7. Done [1 phrase edit] -- Verbatim edit
8. Edit deferred -- It is a standard XMPP Core terminology. Other specs
don't first explain JID (e.g. XEP-0296)

9. Section 4.1, second line.  Add "client" after "sender", to make it clear
> that the user dies not need to bother about transmission.
> 10. Section 4.1 Second paragraph. Change word "live" to "in real-time"
> to be consistent.
> 11. Section 4.1, Example 1, Line 9 ,  make the text part "my Ju"  ,  so
> that it is obvious that it is not about word by word transmission.
> 12. Section 4.1, Example 1, Line 15 ,  make the text part "liet" only,
> so that it is obvious that it is not about word by word transmission.
>
13. Section 4.2.2 event='new' third line.  change "display, and then
> process" to "reception, and then process text and". Because we must not
> assume that all applications display the text. "
>

9. Done [1 word added] -- Already done in v0.4
10. Done [1 phrase change] -- Verbatim edit
11/12. Edit Deferred -- It is merely an introductory example. Also, if
people chunk text instead of preserving key press intervals, then
whole-word burst transmission is greatly preferred over broken-word burst
transmission.
13. Edit Deferred -- It's a great suggestion in theory, but in all
practicality, the change is too confusing. Most implementers of
blind-assistive software will figure out "display" means "reception" or
"present to the user"   The word "display" is pretty standard in many
XEP's, from a search I did. Even it's an XML element in some, i.e. XEP-0202
(A Final standard) uses a  element.

> 14. Section 4.2.2 event='cancel'.  How does this behave through multi-user
> chat and multiple login situations? Is the event='cancel' sent through to
> all? I see a risk that one user sending event='cancel' would turn off rtt
> for all recipients. If this is true, I see three solutions:
> a) Delete event='cancel'. b) Add a sentence saying "event='cancel' SHALL
> not be used in a MUC or multi-login session.  c) Add a sentence saying
> "event='cancel' SHOULD be ignored in MUC and multi-login sessions.
> I have a slight preference for solution a), to delete cancel from the
> specification.
>
If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with
> "cancel" shall be deleted.
>

14. Explanation -- Cancel is critical to the needs of several implementers.
See Activating/Deactivating text section
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text

Also, cancel is 100% appropriate for multi-login session.   I clarified the
MUC chapter to say that cancel should not deactivate outgoing transmission
since it would allow one participant to suppress real-time text between
other willing participants.  (senders may still use it, in order to discard
their unfinished real-time message when logging off, etc)
However, an edit was made to the Activation/Deactivation section to clarify
cancel behaviour during Multi-User Chat.
[2 sentences modified]

> 15. Section 4.4, line 3, after "F.700" inser

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

2012-07-21 Thread Peter Saint-Andre

On 7/21/12 9:01 AM, Kevin Smith wrote:
> On Sat, Jul 21, 2012 at 3:56 PM, Mark Rejhon  wrote:
>> Can someone else outside the R3TF also comment about the inclusion of a
>> small TTY/textphone paragraph in Interoperability considerations?  (Yea's
>> and Nay's -- I know I've gotten a couple of Nay's already.)
> 
> It's an XMPP extension - I'm not sure it greatly benefits anything to
> include details of various related protocols that aren't pertinent to
> implementing this XEP.
> 
> (Nay)

I agree with Kev.

/psa

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

2012-07-21 Thread Kevin Smith

On Sat, Jul 21, 2012 at 3:56 PM, Mark Rejhon  wrote:
> Can someone else outside the R3TF also comment about the inclusion of a
> small TTY/textphone paragraph in Interoperability considerations?  (Yea's
> and Nay's -- I know I've gotten a couple of Nay's already.)

It's an XMPP extension - I'm not sure it greatly benefits anything to
include details of various related protocols that aren't pertinent to
implementing this XEP.

(Nay)

/K

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

*On Sat, Jul 21, 2012 at 10:32 AM, Edward Tie  wrote:
*
>
>  *I missed some articles at Capther 8
> *8. Interoperability Considerations
>  I missed some articles about Captional telephone  (SMS) and classic text
> telephones (V.18 and V.22 bis) .
>  Can you explain why do you not added a sub article about a gateway to
> classic textphones and Capational telephones?
>  Earlier week have some poeple dissussed about addional proposual article
> ?
>
We had a further internal discussion -- Info about it will instead be put
at the Interoperability section of the Real Time Text Taskforce -- I was
trying to shrink certain parts of the spec by optimizing sentences, and the
Interoperability section was one section that ended up getting shrunk
slightly.(XEP-0301 is one of the larger XEP's, even though it is much
smaller than the original 0.0.1 submission of this spec.)

Can someone else outside the R3TF also comment about the inclusion of a
small TTY/textphone paragraph in Interoperability considerations?  (Yea's
and Nay's -- I know I've gotten a couple of Nay's already.)

Thanks,
Mark Rejhon

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

2012-07-21 Thread Edward Tie


I missed some articles at Capther 8


   8. Interoperability Considerations


   I missed some articles about Captional telephone  (SMS) and classic
   text telephones (V.18 and V.22 bis) .


   Can you explain why do you not added a sub article about a gateway
   to classic textphones and Capational telephones?


   Earlier week have some poeple dissussed about addional proposual
   article ?






Op 21/07/2012 16:04, Mark Rejhon schreef:

Sending reply that covered the bullets.
Also, some of this is already outdated, as I already made some changes 
(independently).  You might want to review which bullets still apply, 
and which bullets are outdated.


-- Forwarded message --
From: *Mark Rejhon* mailto:marky...@gmail.com>>
Date: Mon, Jul 9, 2012 at 5:26 AM
Subject: Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
To: XMPP Standards mailto:standards@xmpp.org>>


On Mon, Jul 9, 2012 at 3:51 AM, Gunnar Hellström 
mailto:gunnar.hellst...@omnitor.se>> wrote:


This looks good. I have some comments, but very few influence the
protocol.
So even if there are minor adjustments to do, the spec looks mature.


Excellent comments, and the vast majority of your comments is useful 
-- most of your change will be implemented.

I will address comments to the ones that needs further discussion:


5. Section 2.4, Title. Change to "Usable for mainstream and
accessibility purposes."


The current heading is a single word: "Accessible" -- I prefer to keep 
it because it's correct, clear, and short.  It catches attention of 
the accessibility people better, including the Access Board that has 
already contacted us, about the specification too.  The word 
'mainstream" is also mentioned at end of section 1, also even in 
section 2.4, in section 6.2.  I therefore believe that I've carefully 
balanced accessibility and mainstream, and satisfied both targets, 
while aiming to achieve the goal of eventually becoming an important 
part of future Accessibility standards.

(That said, I'll fix the first bullet)


14. Section 4.2.2 event='cancel'.  How does this behave through
multi-user chat and multiple login situations? Is the
event='cancel' sent through to all? I see a risk that one user
sending event='cancel' would turn off rtt for all recipients. If
this is true, I see three solutions:
a) Delete event='cancel'. b) Add a sentence saying "event='cancel'
SHALL not be used in a MUC or multi-login session.  c) Add a
sentence saying "event='cancel' SHOULD be ignored in MUC and
multi-login sessions.


1. It is appropriate for a multi-login session; there is no issue with 
using the cancel during a multi-login -- it is completely appropriate 
for multi-login.  (Regardless of whether or not you cancel 
before/after switching, and regardless of whether or not you 
reactivate before/after switching logins.  All scenarios result in 
acceptable behavior.)
2. I already mention that it should not be used for MUC, in the MUC 
section: http://xmpp.org/extensions/xep-0301.html#multiuser_chat


I have a slight preference for solution a), to delete cancel from
the specification.
If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing
with "cancel" shall be deleted.


It is already optional.  But some implementations need it.
For example, one party clicks a button to turn off real-time text.
This specific implementation requires ability to synchronize the 
disabiling of real-time text.
How do we notify the other end of the intent to end a real-time text 
session?


Example use case:
- A party activates real-time text by pressing a button.
- Both ends synchronize the enabling of real-time text via event='start'/>.

- A party deactivates real-time text.
- Both ends synchronize the disabling of real-time text via event='cancel'/>.


Various methods of synchronizing activation/deactivation of real-time 
text is listed at:
http://www.xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text 
<http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text> 

Certainly, not all implementations necessarily need to follow the 
above behaviour (maybe your implementation doesn't need it).
However, there are other vendors that definitely need to be able to do 
this behaviour (after displaying a confirmation prompt)
As a result, I cannot remove event='cancel' and deny the other vendors 
the ability to synchronize the disabling of real-time text.
That said, unidirectional real-time text is allowed by XEP-0301, so 
synchronizing the enabling/disabling of real-time text is not a 
requirement, but some vendors require this ability (much like 
synchronizing enabling/disabling of audio/video after a confirmation 
prompt).  I intend to re

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

Sending reply that covered the bullets.
Also, some of this is already outdated, as I already made some changes
(independently).  You might want to review which bullets still apply, and
which bullets are outdated.

-- Forwarded message --
From: Mark Rejhon 
Date: Mon, Jul 9, 2012 at 5:26 AM
Subject: Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
To: XMPP Standards 

 On Mon, Jul 9, 2012 at 3:51 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

>  This looks good. I have some comments, but very few influence the
> protocol.
> So even if there are minor adjustments to do, the spec looks mature.
>

Excellent comments, and the vast majority of your comments is useful --
most of your change will be implemented.
I will address comments to the ones that needs further discussion:

5. Section 2.4, Title. Change to "Usable for mainstream and accessibility
> purposes."
>

The current heading is a single word: "Accessible" -- I prefer to keep it
because it's correct, clear, and short.  It catches attention of the
accessibility people better, including the Access Board that has already
contacted us, about the specification too.  The word 'mainstream" is also
mentioned at end of section 1, also even in section 2.4, in section 6.2.  I
therefore believe that I've carefully balanced accessibility and
mainstream, and satisfied both targets, while aiming to achieve the goal of
eventually becoming an important part of future Accessibility standards.
(That said, I'll fix the first bullet)

14. Section 4.2.2 event='cancel'.  How does this behave through multi-user
> chat and multiple login situations? Is the event='cancel' sent through to
> all? I see a risk that one user sending event='cancel' would turn off rtt
> for all recipients. If this is true, I see three solutions:
> a) Delete event='cancel'. b) Add a sentence saying "event='cancel' SHALL
> not be used in a MUC or multi-login session.  c) Add a sentence saying
> "event='cancel' SHOULD be ignored in MUC and multi-login sessions.
>

1. It is appropriate for a multi-login session; there is no issue with
using the cancel during a multi-login -- it is completely appropriate for
multi-login.  (Regardless of whether or not you cancel before/after
switching, and regardless of whether or not you reactivate before/after
switching logins.  All scenarios result in acceptable behavior.)
2. I already mention that it should not be used for MUC, in the MUC
section: http://xmpp.org/extensions/xep-0301.html#multiuser_chat

> I have a slight preference for solution a), to delete cancel from the
> specification.
> If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with
> "cancel" shall be deleted.
>

It is already optional.  But some implementations need it.
For example, one party clicks a button to turn off real-time text.
This specific implementation requires ability to synchronize the disabiling
of real-time text.
How do we notify the other end of the intent to end a real-time text
session?

Example use case:
- A party activates real-time text by pressing a button.
- Both ends synchronize the enabling of real-time text via .
- A party deactivates real-time text.
 - Both ends synchronize the disabling of real-time text via .

Various methods of synchronizing activation/deactivation of real-time text
is listed at:
http://www.xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text<http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text>
Certainly, not all implementations necessarily need to follow the above
behaviour (maybe your implementation doesn't need it).
However, there are other vendors that definitely need to be able to do this
behaviour (after displaying a confirmation prompt)
As a result, I cannot remove event='cancel' and deny the other vendors the
ability to synchronize the disabling of real-time text.
That said, unidirectional real-time text is allowed by XEP-0301, so
synchronizing the enabling/disabling of real-time text is not a
requirement, but some vendors require this ability (much like synchronizing
enabling/disabling of audio/video after a confirmation prompt).  I intend
to respect both behaviours.

16. Section 4.4, line 3, after "conversation", add "in most network
> conditions".   On GPRS, having 1.5 s network latency, the usability
> requirement will not be met, and that must be accepted. ( F.700 requires 2
> seconds end-to-end for usable real-time text and 1 second for good
> real-time text. )
>

Technically you're right.  I'll make this wording adjustment, since it is
what F.700 says for technical compliance purposes.
That said, real-world usability comment: I would like to comment that
the innovation of

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

On Sat, Jul 21, 2012 at 1:46 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

>  That was a huge amount of edits.
>

According to Einstien: "It's all relative"
Compare the 0.2-0.3 diff and the 0.3-0.4 diff.
 You'll notice that the 0.2-0.3 diff is impossible to track, while the
0.3-0.4 diff is now finally possible to track.

> However, I sent a bunch of edit hints on July 9, and see none of them
> applied.
> I would like to see them applied or commented why they should not be
> applied.
>

I saved lists from several people, and pinned them to my cubicle wall, as a
review and as TODO's.
Apparently, I missed this copy of your list.  My apologies.
(Surprisingly, you didn't remind me when I emailed you a preview -- but
we're all hard-working people with lots of projects, anyway!)

I think I already replied, so I'll dig up the reply and resend it, for
context -- but now I've saved your list.

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

2012-07-20 Thread Gunnar Hellström


On 2012-07-21 04:55, Mark Rejhon wrote:
On Fri, Jul 20, 2012 at 9:33 PM, XMPP Extensions Editor 
mailto:edi...@xmpp.org>> wrote:


Version 0.4 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.
Changelog: Spelling, grammar, and clarification edits, including
section clarifications recommended from public discussion. Interop
with XEP-0308 message correction. (MDR)
Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.3/vs/0.4
URL: http://xmpp.org/extensions/xep-0301.html

..
I would appreciate opinions about announcing LAST CALL, for this 
specification.

Thank you so much, everyone!

Mark Rejhon


Mark,
That was a huge amount of edits.
Luckily, very few of them affect protocol, so my judgement is still that 
the specification is mature and can go for Last Call if the XEP 
management so decides.


However, I sent a bunch of edit hints on July 9, and see none of them 
applied.
I would like to see them applied or commented why they should not be 
applied.


Here they are in their original form, relating to version 0.3.

These are my observations and propsals:

1.  Chapter 1, last line:  Move last sentence first. And make an empty 
line after it. Now it takes the whole chapter before we get to know what 
the specification is about.


2. Chapter 1, last bullet point. Change to: " As one medium in Total 
Conversation, e.g. deployed in the European project REACH112 [5] for 
accessible communication and emergency service."
Motivation: ( Total conversation was the theme. It 
was about both person-to-person and emergency service)


3. Section 2.1, point 4.   add "and replication" after "transmission".  
( just transmission is not sufficient for the intended effect.)


4. Section 2.2, point 3. change "traversal protocols" to "traversal 
mechanisms",   because they are more mechanisms than protocols.


5. Section 2.4, Title. Change to "Usable for mainstream and 
accessibility purposes."


6. Section 2.4, point 1. Change word "accessibility" to "service 
description".   Because F.703 is a general standard. The total 
conversation part is of accessibility interest.


7. Chapter 3,  Real-time text. Change "in real time" to "instantly" , to 
match definition in chapter 1.


8. Chapter 3, Add "JID" and its explanation.

9. Section 4.1, second line.  Add "client" after "sender", to make it 
clear that the user dies not need to bother about transmission.


10. Section 4.1 Second paragraph. Change word "live" to "in real-time"   
to be consistent.


11. Section 4.1, Example 1, Line 9 ,  make the text part "my Ju"  , so 
that it is obvious that it is not about word by word transmission.


12. Section 4.1, Example 1, Line 15 ,  make the text part "liet" only,   
so that it is obvious that it is not about word by word transmission.


13. Section 4.2.2 event='new' third line.  change "display, and then 
process" to "reception, and then process text and". Because we must 
not assume that all applications display the text. "


14. Section 4.2.2 event='cancel'.  How does this behave through 
multi-user chat and multiple login situations? Is the event='cancel' 
sent through to all? I see a risk that one user sending event='cancel' 
would turn off rtt for all recipients. If this is true, I see three 
solutions:
a) Delete event='cancel'. b) Add a sentence saying "event='cancel' SHALL 
not be used in a MUC or multi-login session.  c) Add a sentence saying 
"event='cancel' SHOULD be ignored in MUC and multi-login sessions.
I have a slight preference for solution a), to delete cancel from the 
specification.
If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with 
"cancel" shall be deleted.


15. Section 4.4, line 3, after "F.700" insert "usability requirement 
section A.3.2.1" so that the reader understands why this requirement 
exists and where to find it.


16. Section 4.4, line 3, after "conversation", add "in most network 
conditions".   On GPRS, having 1.5 s network latency, the usability 
requirement will not be met, and that must be accepted. ( F.700 requires 
2 seconds end-to-end for usable real-time text and 1 second for good 
real-time text. )


17. Section 4.5, last word. Replace "delivered" with "completed" .

18. Consider deleting the "Forward Delete" d action element. It cannot 
be used with the default value for p because that would point outside 
the real-time message. Therefore, a p must always be calculated and 
included. Then it is equal in complexity to use it as Backspace. Having 
both just seem to add complexity to implementations. ( It would have 
been different and of value if it worked from a current cursor 
position.)   But if you have good reasons, e.g. easily matching some 
editing operation result, you can keep it.


19. Section 4.5.2, third bullet point. I would like to see the words 
"Unicode Code Points" replace "Unicode Character C

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

2012-07-20 Thread Mark Rejhon

On Fri, Jul 20, 2012 at 9:33 PM, XMPP Extensions Editor wrote:

> Version 0.4 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.
> Changelog: Spelling, grammar, and clarification edits, including section
> clarifications recommended from public discussion. Interop with XEP-0308
> message correction. (MDR)
> Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.3/vs/0.4
> URL: http://xmpp.org/extensions/xep-0301.html


This is the version of the spec I would like to announce LAST CALL, if at
least a few people think it is ready. Peter Saint Andre mentioned he
believed it was ready, Gunnar has mentioned it is ready, but I would like
Peter's opinion again, as well as Kevin's opinion.

More detail about the changes made, based on discussion on this mailing
list, as well as within the Real Time Text Taskforce, and discussion to
other parties. The diff is much less dense than between 0.2->0.3, with
mainly hundreds of tiny edits (mostly grammatical and spelling), and at
least a couple of significant section changes/slight reordering.

- Protocol Change: (Backwards compatible) Add new optional 'id' attribute
for good compatibility with XEP-0308 Last Message Correction
- Editorial: Many minor grammar and spelling mistakes fixed (with help of
Microsoft Word)
- Editorial: Adjusted uppercase "And", "For", "With" in headings to
lowercase
- Editorial: "implementor" changed to "implementer" (consistent with usage
by other Final XEP's)
- Editorial: Vast majority of Barry Dingle's corrections incorporated
- Editorial: Minor changes to Multi-User Chat section
- Rename: "Real-Time Text Operations" renamed to "Real-Time Text Actions"
(consistency)
- Rename: "Element  - Interval" into "Element  - Wait Interval" in
order to reduce confusion with "Transmission Interval", and someone also
asked what "W" in  stood for.
- Optimization: Rewrote 6.1.2 "Preserving Key Press Intervals" to be much
clearer, while 15% smaller.
- Optimization: Section 1 "Introduction", optimized one sentence in last
paragraph. Shorter yet extolls additional mainstream advantages.
- Optimization: Section 8 "Interoperability Considerations" optimized by
approximately 40% in size, with no loss of info.
- Clarification: Section 4.1 first two paragraphs has very minor edits,
including four-word explanation why  is still used.
- Clarification: Added word "default" to 4.4 Transmission Interval.
- Clarification: Reorganize section 6.4 "Real-Time Text Transmission
Methodologies" to be more user-friendly (also based on Gunnar comments).
 Some section names have been changed, and information has been
recategorized in a different order.
- Clarification: Section 4.6.3 "Message Reset", changed third bullet to be
more appropriate, some sentences updated.
- Clarification: Section 5 "Determining Support" improvement, now includes
XEP-0115.  (Continues to allow XEP-0085 style fallback)
- Clarification: Clarification of several examples, new examples added to
Use Cases
NOTE: Despite the evolution of this specification, all versions of XEP-0301
since v0.1 have remained backwards compatible with each other (at least in
intended interpretation  -- wording is much more clarified in v0.4 thanks
to everyone's help!)

I would appreciate opinions about announcing LAST CALL, for this
specification.
Thank you so much, everyone!

Mark Rejhon

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

2012-07-10 Thread Gunnar Hellström


On 2012-07-10 17:32, Mark Rejhon wrote:
The only one I'd be cautious about is that 6.4.3 needs to be a 
distinct section; because it is less confusing to vendors trying to 
transmit from key press events; that way they can understand the 
"gotchas" of doing that (i.e. missed autospell fixes, missed 
copy+paste events, etc.) ... I've gotten feedback that gave an 
excellent rationale for 6.4.3 being part of 6.4


I found it strange, that 6.4 intended to be about real-time 
methodologies, and then 6.4.3 tells about a non-recommended method, but 
does not tell what to do instead. ( that is found in 6.4.4. )


I did want to start the advice in 6.4 subsections with something 
positive to follow in the normal case. Therefore 6.4.4 with added 
precaution in the beginning about why not using keypresses seemed to 
cause the best flow.


But if you want, you could start with 6.4.4, changing a little in the 
beginning so that it does not refer to something earlier discussed.


then follow on with 6.4.3   and add a conclusion at the end "Therefore 
it is better to use change detection instead of keypresses."


Then 6.4.1 and 6.4.2

Gunnar

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

2012-07-10 Thread Mark Rejhon

On Tue, Jul 10, 2012 at 11:58 AM, Edward Tie  wrote:

>  I have found a information about larger sms :
>
> Edward, thanks -- but I'm already aware of this.  Message Resets has no
size limit, so implementers need to decide when too big is too big.  I do
warn about bandwidth issues in that paragraph already, so that is
sufficient. The implementer is responsible for determining the maximum size
of messages, as an implementation issue, and is beyond the scope of the
protocol.

P.S. We want to limit out-of-scope discussion, please.  We're hogging the
mailing list, and I'd like to refocus discussions.
Thanks
Mark Rejhon

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

2012-07-10 Thread Edward Tie


Op 10/07/2012 17:32, Mark Rejhon schreef:
On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström 
mailto:gunnar.hellst...@omnitor.se>> wrote:


Mark,
I see that you in this version have introduced a couple of "odd"
real-time text transmission strategies in sections 6.4.1 and
6.4.2, based on the  'reset' event.

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


Gunnar -- several are excellent suggestions.

An explanation at the beginning of 6.4 The transmission strategy in 
6.4.1 and 6.4.2 is not recommended for messages bigger than 
approximately SMS size, for mobile devices that want to write very 
compact & simple implementations of real-time text that does not 
require much processing or battery -- and they can take advantage of 
stream compression to eliminate the redundancy disadvantage of message 
resets.  It was explained to me that it may actually use less 
bandwidth and less CPU in certain situations.   Even though it means a 
disadvantage of losing key press intervals (the intervals demonstrated 
at www.realjabber.org/anim/real_time_text_demo.html 
 ) which I 
already mention.

I have found a information about larger sms :


 Message size

Transmission of short messages between the SMSC and the handset is done 
whenever using the Mobile Application Part 
 (MAP) of the SS7 
 protocol. Messages are 
sent with the MAP MO- and MT-ForwardSM operations, whose payload length 
is limited by the constraints of the signaling protocol to precisely 140 
octets  (140 octets 
= 140 * 8 bits = 1120 bits). Short messages can be encoded using a 
variety of alphabets: the default GSM 7-bit alphabet 
, the 8-bit 
 data alphabet, and the 16-bit UCS-2 
 alphabet.^[35] 
 
Depending on which alphabet the subscriber has configured in the 
handset, this leads to the maximum individual short message sizes of 160 
7-bit  characters, 140 8-bit 
characters, or 70 16-bit characters. GSM 7-bit alphabet support is 
mandatory for GSM handsets and network elements,^[35] 
 
but characters in languages such as Arabic, Chinese, Korean, Japanese or 
Cyrillic alphabet languages (e.g. Russian, Serbian, Bulgarian, etc.) 
must be encoded using the 16-bit UCS-2 
 character encoding 
 (see Unicode 
). Routing 
 data and other metadata 
 is additional to the payload size.


*Larger content (concatenated SMS 
, multipart or segmented 
SMS, or "long SMS") can be sent using multiple messages, in which case 
each message will start with a user data header (UDH) containing 
segmentation information. Since UDH is part of the payload, the number 
of available characters per segment is lower: 153 for 7-bit encoding, 
134 for 8-bit encoding and 67 for 16-bit encoding. The receiving handset 
is then responsible for reassembling the message and presenting it to 
the user as one long message. **While the standard theoretically permits 
up to 255 segments,^[36] 
 6 to 8 
segment messages are the practical maximum, and long messages are often 
billed as equivalent to multiple SMS messages.*

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

2012-07-10 Thread Mark Rejhon

On Mon, Jul 9, 2012 at 8:20 PM, Barry Dingle  wrote:

> Mark,
>
> Really good job. My suggestions are mainly minor edits. Some (hopefully)
> improve the meaning.
>

Barry, excellent job -- I've saved your list, too.
It'll definitely reduce "last call" workload (if agreement is achieved with
Section 5)

Thanks,
Mark Rejhon

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

2012-07-10 Thread Mark Rejhon

On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

> Mark,
> I see that you in this version have introduced a couple of "odd" real-time
> text transmission strategies in sections 6.4.1 and 6.4.2, based on the
>  'reset' event.
> http://xmpp.org/extensions/**xep-0301.html#realtime_text_**
> transmission_methodologies

Gunnar -- several are excellent suggestions.

An explanation at the beginning of 6.4 The transmission strategy in 6.4.1
and 6.4.2 is not recommended for messages bigger than approximately SMS
size, for mobile devices that want to write very compact & simple
implementations of real-time text that does not require much processing or
battery -- and they can take advantage of stream compression to eliminate
the redundancy disadvantage of message resets.  It was explained to me that
it may actually use less bandwidth and less CPU in certain situations.
Even though it means a disadvantage of losing key press intervals (the
intervals demonstrated at
www.realjabber.org/anim/real_time_text_demo.html) which I already
mention.

Stream compression compensates for the bandwidth penalty of doing repeated
message resets as the method of a bare-bones implementation of XEP-0301.  I
also should additionally cite this as part of this paragraph, that if it's
done, it's a good idea to use stream compression, if available.   So when
done, the strategy isn't odd anymore :-)

> 3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method
> that is not recommended, and does not specify a solution, so it suits
> better as introductory warning words.  Use the title 6.4.3 Monitoring
> message changes.  delete title 6.4.4
>

The only one I'd be cautious about is that 6.4.3 needs to be a distinct
section; because it is less confusing to vendors trying to transmit from
key press events; that way they can understand the "gotchas" of doing that
(i.e. missed autospell fixes, missed copy+paste events, etc.) ... I've
gotten feedback that gave an excellent rationale for 6.4.3 being part of 6.4

Thanks
Mark Rejhon

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


Mark,
I see that you in this version have introduced a couple of "odd" 
real-time text transmission strategies in sections 6.4.1 and 6.4.2, 
based on the  'reset' event.

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

I get the impression that you have introduced them after getting 
feedback that it is complicated to detect and convey real-time editing 
within a real-time message.


6.4.1 proposes to send the whole real-time message for every 
transmission interval that there has been any addition or modification 
to it.
6.4.2 proposes to send the whole real-time message repeatedly while the 
user is editing within the real-time message.


They are certainly possible to use, but have, as you point out in the 
last sentence of each section, some obvious disadvantages. One is that 
the length of these messages can be very long if the user has the habit 
of seldom indicating end of message.  That behavior maybe becomes a 
common habit when you get used to real-time text.


A new reader of the specification would however maybe not detect that 
the methods are odd, but read the headings and get the impression that 
this is the normal way of transmitting real-time text. 6.4.1 has the 
heading "Basic Real-Time Text." leading to the conclusion that this is 
normal.


I suggest some reordering, modifications of headers and slight wording 
changes to amend this.


1. Insert explanation in 6.4
"This section describes alternatives for how to detect and compose what 
shall be transmitted during real-time text operation.


2. In first line of 6.4.4 insert after "method" : "to detect what 
changes to transmit"


3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method 
that is not recommended, and does not specify a solution, so it suits 
better as introductory warning words.  Use the title 6.4.3 Monitoring 
message changes.  delete title 6.4.4


4. Replace the second sentence in 6.4.3 (starting with "However..."), 
with "However, this method has disadvantages."


5. Rename 6.4.1 to "Using 'reset' events to transmit changes.

6. Include a new first sentence in 6.4.1: "As an alternative to 
detecting and transmitting only the changes in the real-time message, 
the following method can be considered."


7. Move 6.4.3 to become 6.4.1, pushing earlier 6.4.1 and 6.4.2 down to 
become 6.4.2 and 6.4.3 respectively.






___
Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se
+46708204288

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

2012-07-09 Thread Barry Dingle

Mark,

Really good job. My suggestions are mainly minor edits. Some (hopefully)
improve the meaning.

My Numbers relate to the Section numbers. They have reasons with them where
appropriate.
= = = =

*1.* (Edit) I think the last sentence should be a separate paragraph. (It
is not really part of the paragraph it is in now. And it will highlight the
sentence more which is needed.)

*4.* We need to add some context before we dive into the detail.

Add the following (before 4.1 heading):
"This specification is an extension of XMPP (*XMPP Core* [8]). It uses XMPP
terminology." (To this point in the specification it implies the use of
XMPP but it does not explicitly state it.)

*4.1* (Edit) Last sentence (immediately before Section 4.2)

Make the last sentence a new paragraph on its own. (It does not relate to
sentence before it and it is a requirement that should be highlighted.)

*4.2.1* (Edit) Add text to clarify meaning of last sentence of 2nd paragraph

". . . to keep compact, *but should allow for *plenty of
incrementing room without overflow."

*4.3* Clarify what happens in the 2nd sentence.

"The *content of the element in the *delivered message is displayed
instead of the *contents of the accumulated elements of
the*real-time text message."

*4.5* Clarify 2nd sentence of 2nd paragraph by removing the words 'before
sending' at the end of the sentence. The words removed are misleading when
present as the real-time text has been sent.

"The inclusion of real-time text functionality to existing client software,
needs to preserve the sender's existing expectation of being able to edit
their messages."

*4.5.4.1* (Edit) Last sentence.

“It is noted *that* conversion of line breaks into a single LINE FEED . . .
. “

*5.* 2nd last paragraph. Remove the word 'is' as it should not be there.

“Enabling/disabling of discovery *is* SHOULD NOT be the default method of
activating/deactivating real-time text.”
***6.2.1*In the first of the 4 bullet points – remove 'else' or remove
'as well' as this is repetitive.

Question – Do we need Either of those terms? Can we remove both of them?

In the 2nd bullet point, remove 'also'.

*6.3* 2nd paragraph 1st sentence – remove the 2 commas as they are not
needed.

*6.4.1* (Add) 2nd sentence – state what needs to happen

“. . . simply retransmitted every Transmission Interval *with
event='reset'* whenever there are any text changes.”

3rd sentence – add 'example' - “The *example* below . . . ”

*6.4.4.1* (Edit) 3rd bullet point – clarify and simplify end of sentence

“If there are no changes to the real-time message, then no element
needs to be transmitted.”

*6.4.4.2* (Edit) Spelling 'receiving' and remove the unnecessary 'that'
-

“in the order they are received.”

*6.5.1* Last paragraph – remove plurals – change

from “. . clients that sends” to “. . clients that send”

from “. . when messages reaches” to “. . when messages reach”

*6.5.4* Last paragraph - remove plurals 'resumes' and 'continues'

“Senders that *resume* composing a message (i.e. *continue* a ”

*6.5.5* 1st paragraph, 3rd sentence – remove plural

“Real-time messages *need* to be updated . . ”

*7.1* (Edit) Correct text after first message example. Change "HLLO" to
"HLL".

"The above code sends the misspelled "*HLL*", then backspaces 2
times, then sends "HELLO"."

The 3 examples have the words “The above code . . .”. It is not *code*.
All 3 cases should be changed to start with “The *example* above . . . “

***7.2.2* 1st sentence - Change “The below example . . “ to “The example
below . . “. Better English.

*7.3.1* 2nd last sentence - We should not be referring to code here.
Maybe try rewording the sentence like:

“This is because the text *"Hello Bob, this is Alice!"* is output then ** deletes 4 characters from position 5.”
(This improves consistency with explanatory text in other sections. )

*7.3.2* Same comment as 7.3.1 applies here with different details.

*7.3.3* Same comment as 7.3.1 applies here with different details.

*8*First paragraph – simplify wording to:

“There are other real-time text standards. Interoperability between those
standards and this specification may be required. For each environment
where interoperability is supported, an interoperability specification
needs to be documented that covers addressing, session control, media
negotiation and media transcoding.”

*8.2* 2nd paragraph – several small edits – see edited whole paragraph
below. Change 'addressing' to 'address' ; remove unnecessary commas, add
'for' ; add 'processing' to indicate what is being referred to.

“Interoperability implies *address* translation, media negotiation and
translation, and media transcoding. For media transcoding between this
specification and T.140/RFC 4103, the real-time text transcoding is
straight forward except *for* the editing feature of this specification.
Backwards positioning and insertion or deletion far back

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

2012-07-09 Thread Gregg Vanderheiden

Good -- but also misses a major other user for real-time text, especially with 
elders, and that is captioning.  Also for text one way and audio the next. 

Without making it much longer - we can include these important but often 
overlooked (in an attempt to be brief) methods of communication. 


Addition to what Gunnar Hellström wrote On Jul 9, 2012, at 5:24 PM, :

> 8.3 Textphones (Including TTY)
> Real-time text is implemented in assistive text telephone devices that 
> operate on the PSTN (called TTY in North America), using various text 
> telephone modulation protocols such as those specified in ITU-T V.18 and its 
> annexes (e.g. Baudot, DTMF). It is possible to implement gateways between 
> them and XEP-0301 based real-time text, that can be combined with an audio 
> protocol e.g. XEP-0166 (e.g. for alternating audio and text or text one way 
> and audio the other).  
 
 8.x  Use for Captioned Telephony
XEP-0301 based real-time text can be combined with an audio protocol e.g. 
XEP-0166 to provide captioned telephony and can interoperate via gateways with 
other IP-based captioned telephony protocols such as SIP VoIP with RFC 4103. 

smime.p7s
Description: S/MIME cryptographic signature

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



On 2012-07-09 09:51, Gunnar Hellström wrote:
14. Section 4.2.2 event='cancel'.  How does this behave through 
multi-user chat and multiple login situations? Is the event='cancel' 
sent through to all? I see a risk that one user sending event='cancel' 
would turn off rtt for all recipients. If this is true, I see three 
solutions:
a) Delete event='cancel'. b) Add a sentence saying "event='cancel' 
SHALL not be used in a MUC or multi-login session.  c) Add a sentence 
saying "event='cancel' SHOULD be ignored in MUC and multi-login sessions.
I have a slight preference for solution a), to delete cancel from the 
specification.
If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with 
"cancel" shall be deleted.


I noticed now that there is mentioning of cancel and MUC in section 6.5.3.1.
http://xmpp.org/extensions/xep-0301.html#multiuser_chat

"For  elements, the event <#event> attribute of 'init' or 'cancel' 
is not appropriate for MUC since they are intended for one-on-one use."


However, I do not think it is sufficient, and doubt that it is correct:

I see no problem with 'init' in the muc situation. So, I suggest that 
"init" is deleted.


The current wording says "is not appropriate for MUC".  I suggest that 
that is sharpened up a bit to say:


"For  elements, the event <#event> attribute of  'cancel' SHALL 
NOT be sent during MUC sessions and shall be ignored on reception in 
such sessions since it could cause all rtt actions to cease."


Also in the multiple login section 6.5.3.2 this must be mentioned:

"For  elements, the event <#event> attribute of  'cancel' SHALL 
NOT be sent during multiple login sessions and shall be ignored on 
reception in such sessions, since it could cause all rtt actions to cease."


4.2.2 I suggest that the non-use of 'cancel' in MUC and multiple login 
situations is mentioned already in section 4.2.2


Gunnar

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


On 2012-07-09 17:05, Mark Rejhon wrote:
I propose a shorter section added to Interoperability, since it is 
listed as one of the Requirements (TTY alternative) in Section 2, so 
it is very prudent that I expand on how it's accomplished, by adding 
this section to Interoperability:


*8.3 TTY and Textphones*
*Real-time text is implemented in assistive telephone devices that
operate on the PSTN (e.g. TTY in North America, textphone in
Europe), using various text telephone modulation protocols such as
those specified in ITU-T V.18 and its annexes (e.g. Baudot, DTMF).
It is possible to implement gateways between them and XEP-0301
based real-time text, and can be combined with an audio protocol
such as XEP-0166 (e.g. for Voice Carry Over). *


Good. Just one little modification. My view is that "textphone" or "text 
telephone" is the generic technical term for these devices. Then every 
country has their name for it. USA and Canada calls it TTY and mean then 
the TIA-825A equipped type. UK calls the same "Minicom" after the 
product name of the same. Italy calls their EDT equipped ones DTS . 
Switzerland calls them Schreibtelefon. France had Minitel, Sweden has 
Texttelefon, Denmark has Skrivtelefon, Holland has Schreibtelfon ( I think).
Summary. Use TTY for the North American type and Textphone as the 
general term.  I usually name TTY and Nrth America because Americans 
usually do not even realize that "textphone" is a wider used term for 
the same thing.


I also recommend that we do not introduce the old term "Voice Carry 
Over" that will raise new questions among the ones not knowing 
accessible communication history.


Therefore, I suggest some small modifications resulting in this:

   *8.3 Textphones (Including TTY)
   *
   *Real-time text is implemented in assistive text telephone devices
   that operate on the PSTN (called TTY in North America),
   using various text telephone modulation protocols such as those
   specified in ITU-T V.18 and its annexes (e.g. Baudot, DTMF). It is
   possible to implement gateways between them and XEP-0301 based
   real-time text, that can be combined with an audio protocol e.g.
   XEP-0166 (e.g. for alternating audio and text).
   *


Gunnar

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


Op 09/07/2012 17:05, Mark Rejhon schreef:
I propose a shorter section added to Interoperability, since it is 
listed as one of the Requirements (TTY alternative) in Section 2, so 
it is very prudent that I expand on how it's accomplished, by adding 
this section to Interoperability:


*8.3 TTY and Textphones*
*Real-time text is implemented in assistive telephone devices that
operate on the PSTN (e.g. TTY in North America, textphone in
Europe), using various text telephone modulation protocols such as
those specified in ITU-T V.18 and its annexes (e.g. Baudot, DTMF).
It is possible to implement gateways between them and XEP-0301
based real-time text, and can be combined with an audio protocol
such as XEP-0166 (e.g. for Voice Carry Over). *


It satisfies everyone concerns I hope, because:
1. Its first sentence is jargon-free
2. It is reasonably short.
3. I use "various text modulation protocols" to include any possible 
text modulation protocols, not just those in V.18 (I only use the 
phrase "such as" -- which keeps the door open to anything)

4. Any audio protocol may be used.
5. Further implementation details are left out of this; and best 
covered by a FAQ site (like the one I eventually plan to create)

I agree with you.

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

2012-07-09 Thread Mark Rejhon

I propose a shorter section added to Interoperability, since it is listed
as one of the Requirements (TTY alternative) in Section 2, so it is very
prudent that I expand on how it's accomplished, by adding this section to
Interoperability:

*8.3 TTY and Textphones*
*Real-time text is implemented in assistive telephone devices that operate
on the PSTN (e.g. TTY in North America, textphone in Europe), using various
text telephone modulation protocols such as those specified in ITU-T V.18
and its annexes (e.g. Baudot, DTMF). It is possible to implement gateways
between them and XEP-0301 based real-time text, and can be combined with an
audio protocol such as XEP-0166 (e.g. for Voice Carry Over). *


It satisfies everyone concerns I hope, because:
1. Its first sentence is jargon-free
2. It is reasonably short.
3. I use "various text modulation protocols" to include any possible text
modulation protocols, not just those in V.18 (I only use the phrase "such
as" -- which keeps the door open to anything)
4. Any audio protocol may be used.
5. Further implementation details are left out of this; and best covered by
a FAQ site (like the one I eventually plan to create)


On Mon, Jul 9, 2012 at 10:57 AM, Edward Tie  wrote:

>  Op 09/07/2012 16:30, Gunnar Hellström schreef:
>
> On 2012-07-09 13:31, Edward Tie wrote:
>
> 8.3 Textphones and TTYs in the PSTN (Informational)
> Real-time text is also implemented in the PSTN, through various text
> telephone modulation protocols specified in ITU-T V.18 *or V.22 or 300
> baud ASCII or DTMF.*  It is possible to implement gateways between audio
> and XEP-0301 based real-time text in IP networks and textphones (called TTY
> in North America)  based on V.18* or V.22 or *any of its Annexes in the
> PSTN. When designing such gateways, the limitations in speed, transmission
> direction, character sets and media simultaneity valid for these textphone
> protocols must be taken into consideration as well as the user need to be
> able to at least alternate between audio and real-time text during the
> call.
>
>
> Edward,
> We shall not try to tell the whole story about PSTN text telephony (and
> TTY) in this XMPP document.
> I rather want to follow Peter's advice to reduce it.
>
>  XEP-0301 has its important role as improvement of user experience of
> XMPP text messaging. Details on interoperability should be specified
> elsewhere.  I suggest a very brief paragraph to be kept about legacy
> textphone interoperability. (coming soon)
>
>
> -
> Anyway, for your info,
> ITU-T V.18 has one annex for each of the legacy textphone protocols:
> Baudot (=TTY), V.21, DTMF, V.23(Minitel and even Prestel), Bell
> 103("ASCII"), and even for V.18 itself. You wanted to add V.22 to the list.
> I know it is in use in The Netherlands, but The Netherlands never wanted it
> to be included in V.18.
>
> yes. it's true
>
> So, V.22 is not standardized anywhere as a textphone transport, and as I
> understand it,
>
> Only Dutch next generation textphone (HGT teksttelefoon) supports V.22
> (1200) and V.22bis. It called TDD.
>  See dutch summery:
> http://home.planet.nl/~hgtgm000/Downloads/TT_appendix_A_en_B.pdf
>
>
>  all Dutch V.22 textphones can also do automatic switching to DTMF based
> text telephony.
>
> Yes. Dutch old generation textphones (Goedhart visicom and PTT
> teksttelefoon) supports only DTMF.
>
>
>
>

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


Op 09/07/2012 16:30, Gunnar Hellström schreef:

On 2012-07-09 13:31, Edward Tie wrote:

8.3 Textphones and TTYs in the PSTN (Informational)
Real-time text is also implemented in the PSTN, through various text 
telephone modulation protocols specified in ITU-T V.18 *or V.22 or 
300 baud ASCII or DTMF.*  It is possible to implement gateways 
between audio and XEP-0301 based real-time text in IP networks and 
textphones (called TTY in North America)  based on V.18*or V.22 or 
*any of its Annexes in the PSTN. When designing such gateways, the 
limitations in speed, transmission direction, character sets and 
media simultaneity valid for these textphone protocols must be taken 
into consideration as well as the user need to be able to at least 
alternate between audio and real-time text during the call.


Edward,
We shall not try to tell the whole story about PSTN text telephony 
(and TTY) in this XMPP document.

I rather want to follow Peter's advice to reduce it.

XEP-0301 has its important role as improvement of user experience of 
XMPP text messaging. Details on interoperability should be specified 
elsewhere.  I suggest a very brief paragraph to be kept about legacy 
textphone interoperability. (coming soon)


-
Anyway, for your info,
ITU-T V.18 has one annex for each of the legacy textphone protocols: 
Baudot (=TTY), V.21, DTMF, V.23(Minitel and even Prestel), Bell 
103("ASCII"), and even for V.18 itself. You wanted to add V.22 to the 
list. I know it is in use in The Netherlands, but The Netherlands 
never wanted it to be included in V.18. 

yes. it's true

So, V.22 is not standardized anywhere as a textphone transport, and as 
I understand it,
Only Dutch next generation textphone (HGT teksttelefoon) supports V.22 
(1200) and V.22bis. It called TDD.
 See dutch summery: 
http://home.planet.nl/~hgtgm000/Downloads/TT_appendix_A_en_B.pdf



all Dutch V.22 textphones can also do automatic switching to DTMF 
based text telephony.
Yes. Dutch old generation textphones (Goedhart visicom and PTT 
teksttelefoon) supports only DTMF.

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


On 2012-07-09 13:31, Edward Tie wrote:

8.3 Textphones and TTYs in the PSTN (Informational)
Real-time text is also implemented in the PSTN, through various text 
telephone modulation protocols specified in ITU-T V.18 *or V.22 or 300 
baud ASCII or DTMF.*  It is possible to implement gateways between 
audio and XEP-0301 based real-time text in IP networks and textphones 
(called TTY in North America)  based on V.18*or V.22 or *any of its 
Annexes in the PSTN. When designing such gateways, the limitations in 
speed, transmission direction, character sets and media simultaneity 
valid for these textphone protocols must be taken into consideration 
as well as the user need to be able to at least alternate between 
audio and real-time text during the call.


Edward,
We shall not try to tell the whole story about PSTN text telephony (and 
TTY) in this XMPP document.

I rather want to follow Peter's advice to reduce it.

XEP-0301 has its important role as improvement of user experience of 
XMPP text messaging. Details on interoperability should be specified 
elsewhere.  I suggest a very brief paragraph to be kept about legacy 
textphone interoperability. (coming soon)


-
Anyway, for your info,
ITU-T V.18 has one annex for each of the legacy textphone protocols: 
Baudot (=TTY), V.21, DTMF, V.23(Minitel and even Prestel), Bell 
103("ASCII"), and even for V.18 itself. You wanted to add V.22 to the 
list. I know it is in use in The Netherlands, but The Netherlands never 
wanted it to be included in V.18. So, V.22 is not standardized anywhere 
as a textphone transport, and as I understand it, all Dutch V.22 
textphones can also do automatic switching to DTMF based text telephony.
Therefore mentioning "V.18 or its annexes" could be as far as we go 
here. ( if at all...)


Gunnar

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

2012-07-09 Thread Peter Saint-Andre

On 7/9/12 12:24 AM, Barry Dingle wrote:
> Hi Edward,
> 
> I understand about the need to educate people about the 'traditional'
> Textphone/TTY text protocols. However, I think that XEP-0301 should
> specify real-time text over XMPP only.

Yes, please.

Peter

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

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


Op 09/07/2012 13:12, Gunnar Hellström schreef:



One sentence will be added to satisfy this.
http://xmpp.org/extensions/xep-0301.html#interoperability_considerations 

To just simply mention that "...a gateway can be built as a part of 
a complete solution (i.e. with optional audio, such as to support 
Voice Carry Over) to support any legacy protocols used by TTY and 
textphones using various protocols including Baudot, 300 baud ASCII, 
DTMF, ITU-T V.18, ITU-T V.22, and other text transmission 
protocols". (wording will be refined upon consultation within R3TF 
including Gregg Vanderheiden who helps out in this area)


There was a lot of debate within our group (i.e. Gregg Vanderheiden) 
about the careful choice of wording, because we need to be sensitive 
about the "complete solution" (such as worldwide interoperability, 
the ability to use voice, accessibility to people who don't have 
Internet, etc).


it's now a clear history :-)

I agree with Mark. XEP-0301 is a protocol specification for XMPP, 
mainly on the transport level, and should not be loaded with too much 
info on other possibly related areas.
No. it's not clear enough. That are six a seven standaard different 
protocols. The developers must know what they uses all of protocols to 
build a whole gateway PSTN-SIP-XMPP




But, since we already have that interoperability chapter, it can be 
extended with a sentence.


I suggest this addition:

8.3 Textphones and TTYs in the PSTN (Informational)
Real-time text is also implemented in the PSTN, through various text 
telephone modulation protocols specified in ITU-T V.18 *or V.22 or 300 
baud ASCII or DTMF.*  It is possible to implement gateways between 
audio and XEP-0301 based real-time text in IP networks and textphones 
(called TTY in North America)  based on V.18*or V.22 or *any of its 
Annexes in the PSTN. When designing such gateways, the limitations in 
speed, transmission direction, character sets and media simultaneity 
valid for these textphone protocols must be taken into consideration 
as well as the user need to be able to at least alternate between 
audio and real-time text during the call.


Gunnar

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




One sentence will be added to satisfy this.
http://xmpp.org/extensions/xep-0301.html#interoperability_considerations
To just simply mention that "...a gateway can be built as a part of a 
complete solution (i.e. with optional audio, such as to support Voice 
Carry Over) to support any legacy protocols used by TTY and 
textphones using various protocols including Baudot, 300 baud ASCII, 
DTMF, ITU-T V.18, ITU-T V.22, and other text transmission protocols". 
(wording will be refined upon consultation within R3TF including 
Gregg Vanderheiden who helps out in this area)


There was a lot of debate within our group (i.e. Gregg Vanderheiden) 
about the careful choice of wording, because we need to be sensitive 
about the "complete solution" (such as worldwide interoperability, 
the ability to use voice, accessibility to people who don't have 
Internet, etc).


it's now a clear history :-)

I agree with Mark. XEP-0301 is a protocol specification for XMPP, mainly 
on the transport level, and should not be loaded with too much info on 
other possibly related areas.


But, since we already have that interoperability chapter, it can be 
extended with a sentence.


I suggest this addition:

8.3 Textphones and TTYs in the PSTN (Informational)
Real-time text is also implemented in the PSTN, through various text 
telephone modulation protocols specified in ITU-T V.18.  It is possible 
to implement gateways between audio and XEP-0301 based real-time text in 
IP networks and textphones (called TTY in North America)  based on V.18 
or any of its Annexes in the PSTN. When designing such gateways, the 
limitations in speed, transmission direction, character sets and media 
simultaneity valid for these textphone protocols must be taken into 
consideration as well as the user need to be able to at least alternate 
between audio and real-time text during the call.


Gunnar






Protocols

There are many different textphone standards.


  Baudot code

The original standard used by TTYs is the Baudot code
 implemented
asynchronously at either 45.5 or 50 baud, 1 start bit, 5 data
bits, and 1.5 stop bits. Baudot is a common protocol in the US.


  Turbo Code

In addition to regular Baudot, the UltraTec

company implements another protocol known as Enhanced TTY, which
it calls "Turbo Code," in its products. Turbo Code has some
advantages over Baudot protocols, such as a higher data rate,
full ASCII  compliance, and
full-duplex capability. However, Turbo Code is proprietary, and
UltraTec only gives its specifications to parties who are willing
to license it.


  Other legacy protocols

Other protocols used for text telephony are European Deaf
Telephone (EDT) and Dual-tone multi-frequency signaling
 (DTMF).

The ITU V series recommendations are a collection of early modem
standards approved by the ITU 
in 1988.

  * ITU V.21  [1]


specifies 300 bits per second duplex mode.
  * ITU V.23  [2]


specifies audio frequency-shift keying

modulation to encode and transfer data at 600/1200 bits per
second.


  V.18

In 1994 the ITU

approved the V.18

standard [3] . V.18 is a
dual standard. It is both an umbrella protocol that allows
recognition and interoperability of some of the most commonly
used textphone protocols, as well as offering a native V.18 mode,
which is an ASCII  full- or
half-duplex modulation method.

Computers can, with appropriate software and modem, emulate a
V.18 TTY. Some voice modems, coupled with appropriate software,
can now be converted to TTY modems by using a software-based
decoder for TTY tones. Same can be done with such software using
a computer's sound card, when coupled to the telephone line.

In the UK, a virtual V.18 network, called TextDirect, exists as
part of the Public Switched Telephone Network
,
thereby offering interoperability between textphones using
different protocols. The platform also offers additional
functi

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

2012-07-09 Thread Gregg Vanderheiden

Just reread that and it sounded a bit Jingo -y 

maybe  

Accessible features of use to Mainstream as well. 

And further discussion will be off list on this. 

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 9, 2012, at 1:02 PM, Gregg Vanderheiden wrote:

> I think it is better to capture both audiences -- and not make this about 
> just one group
> but I see how you want accessible to stand out
> 
> how about
> 
> 
> Accessible - and mainstream too. 
> 
> 
> 
> 
> 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 9, 2012, at 11:26 AM, Mark Rejhon wrote:
> 
>> 5. Section 2.4, Title. Change to "Usable for mainstream and accessibility 
>> purposes."
>> 
>> The current heading is a single word: "Accessible" -- I prefer to keep it 
>> because it's correct, clear, and short.  It catches attention of the 
>> accessibility people better, including the Access Board that has already 
>> contacted us, about the specification too.  The word 'mainstream" is also 
>> mentioned at end of section 1, also even in section 2.4, in section 6.2.  I 
>> therefore believe that I've carefully balanced accessibility and mainstream, 
>> and satisfied both targets, while aiming to achieve the goal of eventually 
>> becoming an important part of future Accessibility standards.
>> (That said, I'll fix the first bullet)
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

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

2012-07-09 Thread Gregg Vanderheiden

I think it is better to capture both audiences -- and not make this about just 
one group
but I see how you want accessible to stand out

how about


Accessible - and mainstream too. 




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 9, 2012, at 11:26 AM, Mark Rejhon wrote:

> 5. Section 2.4, Title. Change to "Usable for mainstream and accessibility 
> purposes."
> 
> The current heading is a single word: "Accessible" -- I prefer to keep it 
> because it's correct, clear, and short.  It catches attention of the 
> accessibility people better, including the Access Board that has already 
> contacted us, about the specification too.  The word 'mainstream" is also 
> mentioned at end of section 1, also even in section 2.4, in section 6.2.  I 
> therefore believe that I've carefully balanced accessibility and mainstream, 
> and satisfied both targets, while aiming to achieve the goal of eventually 
> becoming an important part of future Accessibility standards.
> (That said, I'll fix the first bullet)
> 



smime.p7s
Description: S/MIME cryptographic signature

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


Op 09/07/2012 11:40, Mark Rejhon schreef:
On Mon, Jul 9, 2012 at 2:09 AM, Edward Tie > wrote:


Hi Mark,
 I want to add on history of textphone and XMPP to old
telephones that uses older protocols:


Hello Edward,
Good history -- however, this is already beyond scope of XEP-0301.
Anybody can create an XEP-0301 gateway that converts to almost 
anything (including any of the protocols you mention).


One sentence will be added to satisfy this.
http://xmpp.org/extensions/xep-0301.html#interoperability_considerations
To just simply mention that "...a gateway can be built as a part of a 
complete solution (i.e. with optional audio, such as to support Voice 
Carry Over) to support any legacy protocols used by TTY and textphones 
using various protocols including Baudot, 300 baud ASCII, DTMF, ITU-T 
V.18, ITU-T V.22, and other text transmission protocols". (wording 
will be refined upon consultation within R3TF including Gregg 
Vanderheiden who helps out in this area)


There was a lot of debate within our group (i.e. Gregg Vanderheiden) 
about the careful choice of wording, because we need to be sensitive 
about the "complete solution" (such as worldwide interoperability, the 
ability to use voice, accessibility to people who don't have Internet, 
etc).


it's now a clear history :-)





Protocols

There are many different textphone standards.


  Baudot code

The original standard used by TTYs is the Baudot code
 implemented
asynchronously at either 45.5 or 50 baud, 1 start bit, 5 data
bits, and 1.5 stop bits. Baudot is a common protocol in the US.


  Turbo Code

In addition to regular Baudot, the UltraTec

company implements another protocol known as Enhanced TTY, which
it calls "Turbo Code," in its products. Turbo Code has some
advantages over Baudot protocols, such as a higher data rate, full
ASCII  compliance, and
full-duplex capability. However, Turbo Code is proprietary, and
UltraTec only gives its specifications to parties who are willing
to license it.


  Other legacy protocols

Other protocols used for text telephony are European Deaf
Telephone (EDT) and Dual-tone multi-frequency signaling

(DTMF).

The ITU V series recommendations are a collection of early modem
standards approved by the ITU 
in 1988.

  * ITU V.21  [1]


specifies 300 bits per second duplex mode.
  * ITU V.23  [2]


specifies audio frequency-shift keying

modulation to encode and transfer data at 600/1200 bits per
second.


  V.18

In 1994 the ITU

approved the V.18

standard [3] . V.18 is a
dual standard. It is both an umbrella protocol that allows
recognition and interoperability of some of the most commonly used
textphone protocols, as well as offering a native V.18 mode, which
is an ASCII  full- or
half-duplex modulation method.

Computers can, with appropriate software and modem, emulate a V.18
TTY. Some voice modems, coupled with appropriate software, can now
be converted to TTY modems by using a software-based decoder for
TTY tones. Same can be done with such software using a computer's
sound card, when coupled to the telephone line.

In the UK, a virtual V.18 network, called TextDirect, exists as
part of the Public Switched Telephone Network
,
thereby offering interoperability between textphones using
different protocols. The platform also offers additional
functionality like call progress and status information in text
and automatic invocation of a relay service for speech-to-text calls.

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

2012-07-09 Thread Mark Rejhon

On Mon, Jul 9, 2012 at 2:09 AM, Edward Tie  wrote:

>  Hi Mark,
>  I want to add on history of textphone and XMPP to old telephones that
> uses older protocols:
>

Hello Edward,
Good history -- however, this is already beyond scope of XEP-0301.
Anybody can create an XEP-0301 gateway that converts to almost anything
(including any of the protocols you mention).

One sentence will be added to satisfy this.
http://xmpp.org/extensions/xep-0301.html#interoperability_considerations
To just simply mention that "...a gateway can be built as a part of a
complete solution (i.e. with optional audio, such as to support Voice Carry
Over) to support any legacy protocols used by TTY and textphones using
various protocols including Baudot, 300 baud ASCII, DTMF, ITU-T V.18, ITU-T
V.22, and other text transmission protocols". (wording will be refined upon
consultation within R3TF including Gregg Vanderheiden who helps out in this
area)

There was a lot of debate within our group (i.e. Gregg Vanderheiden) about
the careful choice of wording, because we need to be sensitive about the
"complete solution" (such as worldwide interoperability, the ability to use
voice, accessibility to people who don't have Internet, etc).

> Protocols
>
> There are many different textphone standards.
>  Baudot code
>
> The original standard used by TTYs is the Baudot 
> codeimplemented asynchronously at 
> either 45.5 or 50 baud, 1 start bit, 5 data
> bits, and 1.5 stop bits. Baudot is a common protocol in the US.
>  Turbo Code
>
> In addition to regular Baudot, the 
> UltraTeccompany
>  implements another protocol known as Enhanced TTY, which it calls
> "Turbo Code," in its products. Turbo Code has some advantages over Baudot
> protocols, such as a higher data rate, full 
> ASCIIcompliance, and full-duplex 
> capability. However, Turbo Code is proprietary,
> and UltraTec only gives its specifications to parties who are willing to
> license it.
>  Other legacy protocols
>
> Other protocols used for text telephony are European Deaf Telephone (EDT)
> and Dual-tone multi-frequency 
> signaling(DTMF).
>
> The ITU V series recommendations are a collection of early modem standards
> approved by the ITU  in 1988.
>
>- ITU V.21  
> [1]specifies
>  300 bits per second duplex mode.
>- ITU V.23  
> [2]specifies
>  audio
>frequency-shift 
> keyingmodulation 
> to encode and transfer data at 600/1200 bits per second.
>
>  V.18
>
> In 1994 the 
> ITUapproved
>  the
> V.18standard
> [3] . V.18 is a dual standard. It
> is both an umbrella protocol that allows recognition and interoperability
> of some of the most commonly used textphone protocols, as well as offering
> a native V.18 mode, which is an ASCII 
> full- or half-duplex modulation method.
>
> Computers can, with appropriate software and modem, emulate a V.18 TTY.
> Some voice modems, coupled with appropriate software, can now be converted
> to TTY modems by using a software-based decoder for TTY tones. Same can be
> done with such software using a computer's sound card, when coupled to the
> telephone line.
>
> In the UK, a virtual V.18 network, called TextDirect, exists as part of
> the Public Switched Telephone 
> Network,
> thereby offering interoperability between textphones using different
> protocols. The platform also offers additional functionality like call
> progress and status information in text and automatic invocation of a relay
> service for speech-to-text calls.
>
>
>
>

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

2012-07-09 Thread Mark Rejhon

On Mon, Jul 9, 2012 at 3:51 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

>  This looks good. I have some comments, but very few influence the
> protocol.
> So even if there are minor adjustments to do, the spec looks mature.
>

Excellent comments, and the vast majority of your comments is useful --
most of your change will be implemented.
I will address comments to the ones that needs further discussion:

5. Section 2.4, Title. Change to "Usable for mainstream and accessibility
> purposes."
>

The current heading is a single word: "Accessible" -- I prefer to keep it
because it's correct, clear, and short.  It catches attention of the
accessibility people better, including the Access Board that has already
contacted us, about the specification too.  The word 'mainstream" is also
mentioned at end of section 1, also even in section 2.4, in section 6.2.  I
therefore believe that I've carefully balanced accessibility and
mainstream, and satisfied both targets, while aiming to achieve the goal of
eventually becoming an important part of future Accessibility standards.
(That said, I'll fix the first bullet)

14. Section 4.2.2 event='cancel'.  How does this behave through multi-user
> chat and multiple login situations? Is the event='cancel' sent through to
> all? I see a risk that one user sending event='cancel' would turn off rtt
> for all recipients. If this is true, I see three solutions:
> a) Delete event='cancel'. b) Add a sentence saying "event='cancel' SHALL
> not be used in a MUC or multi-login session.  c) Add a sentence saying
> "event='cancel' SHOULD be ignored in MUC and multi-login sessions.
>

1. It is appropriate for a multi-login session; there is no issue with
using the cancel during a multi-login -- it is completely appropriate for
multi-login.  (Regardless of whether or not you cancel before/after
switching, and regardless of whether or not you reactivate before/after
switching logins.  All scenarios result in acceptable behavior.)
2. I already mention that it should not be used for MUC, in the MUC
section: http://xmpp.org/extensions/xep-0301.html#multiuser_chat

> I have a slight preference for solution a), to delete cancel from the
> specification.
> If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with
> "cancel" shall be deleted.
>

It is already optional.  But some implementations need it.
For example, one party clicks a button to turn off real-time text.
This specific implementation requires ability to synchronize the disabiling
of real-time text.
How do we notify the other end of the intent to end a real-time text
session?

Example use case:
- A party activates real-time text by pressing a button.
- Both ends synchronize the enabling of real-time text via .
- A party deactivates real-time text.
 - Both ends synchronize the disabling of real-time text via .

Various methods of synchronizing activation/deactivation of real-time text
is listed at:
http://www.xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text
Certainly, not all implementations necessarily need to follow the above
behaviour (maybe your implementation doesn't need it).
However, there are other vendors that definitely need to be able to do this
behaviour (after displaying a confirmation prompt)
As a result, I cannot remove event='cancel' and deny the other vendors the
ability to synchronize the disabling of real-time text.
That said, unidirectional real-time text is allowed by XEP-0301, so
synchronizing the enabling/disabling of real-time text is not a
requirement, but some vendors require this ability (much like synchronizing
enabling/disabling of audio/video after a confirmation prompt).  I intend
to respect both behaviours.

16. Section 4.4, line 3, after "conversation", add "in most network
> conditions".   On GPRS, having 1.5 s network latency, the usability
> requirement will not be met, and that must be accepted. ( F.700 requires 2
> seconds end-to-end for usable real-time text and 1 second for good
> real-time text. )
>

Technically you're right.  I'll make this wording adjustment, since it is
what F.700 says for technical compliance purposes.
That said, real-world usability comment: I would like to comment that
the innovation of encoding key press intervals (
http://www.realjabber.org/anim/real_time_text_demo.html ) gives an
approximately 1.5x-2x multiplier to the maximum usable latency.  i.e. a
NRTT (Near-Real-Time-Text) "bursty" conversation with a 2 second latency,
is more uncomfortable than an NRTT "smooth" conversation with a 3 second
latency with key press intervals being encoded.   That said, I'm speaking
via real-world usability comments by actual users, as the RealJabber open
source software has a tester's latency interval adjustment for usability
trials that I have tried with several people.  But I agree -- we need to be
consistent with the F.700 definition of "rea

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