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

[Edward Tie]

XMPP Extensions Editor schreef op 28/05/2013 22:30:

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

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

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

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

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

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

yes

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

yes

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

yes

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

No.

5. Is the specification accurate and clearly written?

yes

It's ready for production and many deaf poeple will be very happy. It 
will improved for all people that will using rtt on xmpp (for example 
whatsapp and facebook chat)

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

[Edward Tie]

Mark,

It's done and ready for LAST CALL .



Mark Rejhon schreef op 18/05/2013 19:45:
On Sat, May 18, 2013 at 1:04 PM, XMPP Extensions Editor 
mailto:edi...@xmpp.org>> wrote:


Version 0.9 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


There is now multiple open-source implementations of XEP-0301 to try:

1. Easy: Web based version. Just logon using Google credentials and 
chat XEP-0301 right away.

http://tap.gallaudet.edu/rtt/
(This is a strophe.js JavaScript XEP-0301 plugin; Chris Vogler will 
release it on GIT shortly).


2. Downloadable C# client for XEP-0301 for Windows.
http://www.realjabber.org/

They also interop with each other.  There are also other prototype 
implementations (e.g. Gunnar's Omnitor, Indigital Inc., Gregg 
Vanderheiden's Trace Center), which are not listed here.  Gallaudet 
Univerity's TAP (Technology Access Program) released the Javascript 
version of XEP-0301, showing real-time text streaming between web 
browsers.  We all have unamious agreement that XEP-0301 is mature for 
LAST CALL.  The out-in-open independently developed implementations is 
proof.


I am hereby submitting a request to XSF to proceed with LAST CALL.

Sincerely,
Mark Rejhon
Primary Author of XEP-0301

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

[Edward Tie]

Op 27/02/2013 17:30, XMPP Extensions Editor schreef:

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

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

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

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

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


I showed now at xep 0308.

In Appendix G: Notes: it's two same XEP-0045: Multi-User Chat
3. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.
6. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

Please now correction at 0.3 XEP-0308

Thanks you

Edward Tie.

Re: [Standards] Removal of company names from XEP-0301

[Edward Tie]

Op 24/08/2012 19:40, Mark Rejhon schreef:

Hello,

Discussions are being made about the removal of as many companies as 
possible from XEP-0301.


All references to Google and Cisco have already been 100% removed in 
the current 0.7.

Here are my proposed changes for remaining de-tuning of the mentions.

*** Section 1 Introduction
Change:
"The [Real-Time IM] [3] feature found in AOL Instant Message"
Into
"[Gallaudet University] [3] developed a "Real-Time IM" feature for a 
proprietary instant messenger."
(Replacement link is http://tap.gallaudet.edu/text/aol/ ... 
Alternatively, I can avoid including a link, so there is no AOL mention)


*** Section 1 Introduction
Change:
"A component within Total Conversation, used by Reach112 [4] in 
Europe, an accessible emergency service with real-time text."

Into:
"A component within Total Conversation, an European Union government 
funded consortium (Reach112) for an accessible emergency service with 
real-time text."

(Reach 112, although a consortium, is in a major part, government funded)

--

From this, I believe that all commercial names will have been removed 
from XEP-0301 to the best of my knowledge.

Any comments?

No comments. I agree it
Thanks,

Edward tie

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

[Edward Tie]

Op 23/08/2012 08:51, Gunnar Hellström schreef:

On 2012-08-23 00:34, Matthew Miller wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 16:32, Gunnar Hellström wrote:



/The US Access Board has the following definition in its latest proposal for 
Accessible procurement, Section 508. E.103.4
/http://www.access-board.gov/sec508/refresh/draft-rule.htm
/
TTY./  Equipment that enables interactive text based communications through the 
transmission of frequency-shift-keying audio tones across the public switched 
telephone network.  TTY includes devices for real time text communications and 
voice and text intermixed communications.  Examples of intermixed 
communications are voice carry over and hearing carry over.  One example of a 
TTY is a computer with TTY emulating software and modem.


It is a bit special that we have a North American and an international term.


The citation does not need to be inline with the rest of the text.  The vast 
majority of the time, this is done using end notes in XEPs.


It looks strange to devote so much space and effort to get the US term properly 
explained. Shall we just delete TTY, and only say Text telephone ?


That works, I believe you still need the reference.  See above.
Here is a simple one from FCC that should at least meet the 
requirement to be authoritative:


TTY
A type of machine that allows people with hearing or speech 
disabilities to communicate over the phone using a keyboard and a 
viewing screen. It is sometimes called a TDD.


http://transition.fcc.gov/glossary.html

It however contains the TDD that should be depreciated. And has not 
the indication that it is a North American subset term for more 
generally is called text telephone.

Sufficient?
Yes. It mus called be to a word 'realtime text telephones'. In Europe we 
use always 'realtime text telephones'. American TTY don't works with 
european realtime text phones. Because European real-time textphones 
uses another standaard then TTY-standaard.   It must use common words in 
stead of some words from trademarks.






/Gunnar






- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -http://gpgtools.org

iQEcBAEBAgAGBQJQNV6KAAoJEJq6Ou0cgrSPA44H/io3UGGwY1bqHObs6qDPnMCI
zPRCAlkNsejQ7Kwohn6+EXQu5EjiwnWWfVRBhJyQRlZSl6BoY379mc9prwxqKUkG
Jr8PC9R8pPOkU8JQKquKIxg68BgCAXNf77KRIAwRas8+OpiOvi47twg3zo+HBpzm
c3G/g84D3xBJZCwuulgpYVwL2Rg9XS04g9bfmF5Q5q4OT5lJGCj62qOkC2xumrYo
fDpu3JRmKOd8No+YKGwdfzrBAq8RSC7OTvL0cs6JfweykdlvPwbIjO4si5Ak7vXv
p34MDTTBSyVX91Q52ALA5u98GAs35JYARTu8D4u0XLC0xzr8D9I0s674w/oGxoI=
=xlkv
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

[Edward Tie]

Op 23/08/2012 00:32, Gunnar Hellström schreef:

On 2012-08-23 00:05, Matthew Miller wrote:

I do not see TTY as an acronym anymore.

It is like BT that was read out British Telecom before, but is now just BT.

Or AT&T was read out American Telephone and Telegraph, but is now just AT&T

Wiktionary has solved it by putting (originally) after 
Teletypewriter.http://en.wiktionary.org/wiki/TTY

Following that pattern it can be:

TTY (Teletypewriter (originally)) and other text telephones


Gunnar
What would help most to alleviate this discussion further is to include an 
authoritative citation.


- - m&m

Matthew A. Miller

/The US Access Board has the following definition in its latest 
proposal for Accessible procurement, Section 508. E.103.4

/http://www.access-board.gov/sec508/refresh/draft-rule.htm
/
TTY./  Equipment that enables interactive text based communications 
through the transmission of frequency-shift-keying audio tones across 
the public switched telephone network.  TTY includes devices for real 
time text communications and voice and text intermixed 
communications.  Examples of intermixed communications are voice carry 
over and hearing carry over.  One example of a TTY is a computer with 
TTY emulating software and modem.



It is a bit special that we have a North American and an international 
term.


It looks strange to devote so much space and effort to get the US term 
properly explained. Shall we just delete TTY, and only say Text 
telephone ?


Gunnar.



TTY will be replaced to realtime-text phones or RTT-machines

Re: [Standards] Comments on XEP-0301 -- Section 1

[Edward Tie]

Op 22/08/2012 23:42, Mark Rejhon schreef:

Is this politics-proof:

"TTY (derived from teletypewriter) and text telephones"

I don't like it, but I am going to leave it unmodified (against M&M
wishes) unless there's a consensus.
I agree with gregg. it's history. At this time many deaf poeple haven't 
own computer and internet. In USA a litte group of deaf poeple are using 
teletypewriter first. some inventer have developed first TTY from 
teletypewriter.  But many different textphones have own standaards of 
campany. In 1988 was V.18 introduced as new standard for all text 
phones. This machine was not available at Netherlands. We wait for first 
text telephone at 1988.


Edward Tie



On Wed, Aug 22, 2012 at 5:35 PM, Gregg Vanderheiden  wrote:

agree

You can say

TTY was derived from Teletypewriter - a device originally used by people who
are deaf to communicate.  But today Teletypewriters no longer exist and TTY
is used to refer to a type of telecommunications device used by people who
are deaf that supports Baudot (and sometimes other coding schemes) over
analog phone lines.

that however is probably too much history. but if you are using
Teletypewriter - that would be the \correct way to use it.


Gregg

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

On Aug 22, 2012, at 4:28 PM, Gunnar Hellström 
wrote:

On 2012-08-22 22:58, Mark Rejhon wrote:

On Wed, Aug 22, 2012 at 4:46 PM, Matthew Miller
 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 14:42, Mark Rejhon wrote:

On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller
 wrote:

* Teletypewriter (TTY) and Text Device for the Deaf (TDD) telephones
[citations recommended]

Consulted with some peers.

TTY expansion to Teletypewriter -- OK, good idea.
TDD is actually correctly "Telecommunications Device for the Deaf",
but it is deprecated usage right now by most U.S. accessibility
organizations, in favour of TTY.  Europeans ofte use "textphones", and
variants thereof.

Also, the phrase "text telephones" is more compatible and
self-explanatory with the European equivalent of TTY, "textphones".

It's somewhat political behind the scenes in the various communities,
so changes to this bullet will need to be done very carefully.  I
spent many hours rewording just the Introduction as a result.

Mark Rejhon

That's fine.  I accept I operate under obsolete assumptions sometimes (-:

But it's important that all acronyms are expanded the first time they are
used, and even better to include an authoritative citation.

Oh, you might also be remembering I had

... "TTY and text telephones for the deaf".

But I removed "for the deaf", when Peter/Kevin (one or both)
complained about three mentions of the word "deaf" due to the
overemphasis on the word, despite its clear application there.  So I
toned it down somewhat, reducing three mentions of "deaf" in
Introduction to just one mention.

I do not think expansion of TTY to Teletypewriter is a good idea. That tends
to mean the other use of the term TTY, the device that was often used as a
computer operator console terminal a long time ago and still lives in
language around such usage.

So TTY in this usage is more " A term used in North America for text
telephones, i.e. devices used for text and audio communication in the PSTN
mainly with deaf and hard-of-hearing persons."

Text telephones or textphones is the international term used by ITU-T ( E.g.
V.18 and F.703 )  3GPP ( e.g. TS 22.226 )
IETF ( e.g. RFC 4734 ).
Various countries in Europe have different names for the concept in their
national languages, so text telephone is not specifically European.

I hope it is clear by combining TTY with text telephone what it referred to,
so that we do not need to drag in a long descriptions of a peripheral item
into the spec.

Gunnar

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

[Edward Tie]

BUT..

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



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

I agree

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


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



/Gregg/

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

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








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


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


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


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


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

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

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

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


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


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


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


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


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


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


Please accept the proposals f

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

[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 
 

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

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

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

[Edward Tie]

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)

[Edward Tie]

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)

[Edward Tie]

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)

[Edward Tie]

Op 09/07/2012 11:40, Mark Rejhon schreef:
On Mon, Jul 9, 2012 at 2:09 AM, Edward Tie <mailto:fam...@xs4all.nl>> 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
<http://en.wikipedia.org/wiki/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
<http://en.wikipedia.org/w/index.php?title=UltraTec&action=edit&redlink=1>
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 <http://en.wikipedia.org/wiki/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
<http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling>
(DTMF).

The ITU V series recommendations are a collection of early modem
standards approved by the ITU <http://en.wikipedia.org/wiki/ITU>
in 1988.

  * ITU V.21 <http://en.wikipedia.org/wiki/ITU_V.21> [1]

<http://www.itu.int/rec/T-REC-V.21/recommendation.asp?lang=en&parent=T-REC-V.21-198811-I>
specifies 300 bits per second duplex mode.
  * ITU V.23 <http://en.wikipedia.org/wiki/ITU_V.23> [2]

<http://www.itu.int/rec/T-REC-V/recommendation.asp?lang=en&parent=T-REC-V.23>
specifies audio frequency-shift keying
<http://en.wikipedia.org/wiki/Audio_frequency-shift_keying>
modulation to encode and transfer data at 600/1200 bits per
second.


  V.18

In 1994 the ITU
<http://en.wikipedia.org/wiki/International_Telecommunication_Union>
approved the V.18
<http://en.wikipedia.org/w/index.php?title=ITU_V.18&action=edit&redlink=1>
standard [3] <http://www.itu.int/rec/T-REC-V.18/en>. 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 <http://en.wikipedia.org/wiki/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
<http://en.wikipedia.org/wiki/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)

[Edward Tie]

Hi Mark,

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



   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)

[Edward Tie]

Op 09/07/2012 06:10, Mark Rejhon schreef:
On Sat, Jul 7, 2012 at 7:53 PM, Peter Saint-Andre > wrote:


Hi Mark,

Thanks for working so diligently to incorporate the mass of
feedback you received recently. Given the scope of the changes,
you might want to give folks more than just a few days to provide
feedback before pushing
out 0.4 (perhaps a week from now?). I know I plan to review it
again this week.


That would be fine -- I'll suggest that there's time until Friday, 
with a goal of submitting a Version 0.4 next week (July 16th) which 
will be the version that goes through LAST CALL.


Cheers,
Mark Rejhon

I want to tell to you:

older textphones uses DTMF-tonen. (not same as T.140) We have tested 
with old generation textphones that uses dtmf-tonen with VOIP. It works 
fine. but I think about converting from DTMF to XMPP..

Re: [Standards] XEP-0301 -- starting and stopping real-time text in a chat session.

[Edward Tie]

Op 01/07/2012 01:07, Mark Rejhon schreef:
On Sat, Jun 30, 2012 at 6:51 PM, Mark Rejhon > wrote:


On Sat, Jun 30, 2012 at 6:28 PM, Gregg Vanderheiden
mailto:g...@trace.wisc.edu>> wrote:

but please also don't call messaging 'real time' because it
isn't.   It is "instant delivery of a message"  but it is
messaging - not real time conversation.


Pre-emptive reply, since "real-time" can be subject to interpretation.
We are going by the International Telecommunications Union
definition of "real-time" of being less than 1 second latency.
See ITU-T Rec. F.700, "Multimedia Conversational Services",
section 2.1.2.1
So, according to ITU-T, instant messaging is NOT real-time --
required for true "CONVERSATIONAL" interactivity.


I have updated the Glossary (Section 3) of XEP-0301:

*real-time *– A conversational latency of less than 1 second, as 
defined by ITU-T Rec. F.700, section 2.1.2.1.


Clear?  :-)

I agree :-)

Re: [Standards] Accessibility (including XEP-0301)

[Edward Tie]

Op 29/06/2012 16:36, Winfried Tilanus schreef:

On 06/29/2012 04:00 PM, Edward Tie wrote:

Hi,


If you talk but you think what you have talk wrong..and you hear what
you say..   It will be same for deaf peoples.

First: I don't think we should regard RTT as an accessibility thing or a
'deaf spec'. In the context of online counselling for example there has
been quite a bit of discussion about the use of RTT.

Secondly, the way we process a spoken conversation is fundamentally
different from the way we process a written conversation. When we are
talking, only very few people are able to recall word for word what the
other has said. While listening we interpret what we hear and we
memorize our interpretation, not the words. While speaking we use that
mechanism to correct what we have said. People often start saying
something totally different then where they end with.

With written text, once send, the text is literally black on white in
front of the receiver. With RTT there is no way to mask a change of mind
while writing and less opportunity to undo what was written. If I have
to compare RTT to some analogy of spoken text, then it is like recording
a spoken conversation and replaying and analysing every mistake before
answering.

I don't say RTT is good or bad, useful or useless. But I oppose to the
assumption that RTT is a minor privacy intrusion compared to an audio or
video chat. It is a different kind of privacy intrusion and should be
treated like that.


Yes, but Mark say that users can switch off or on to  option RTT. He 
have build a button (Fast Text) when he want to protect own privacy. 
it's simple solution for him.

Re: [Standards] Accessibility (including XEP-0301)

[Edward Tie]

Op 29/06/2012 15:58, Winfried Tilanus schreef:

On 06/29/2012 03:41 PM, Edward Tie wrote:

Hi,


When he will think before he will talk to you... Is privacy issue when
you must think before you will talk ?

The privacy issue occurs because we are used to 'think aloud' while
typing, relying on the fact that we can always correct it afterwards.
Certainly when things become hard to say, we tend to correct our written
words before we share them. RTT is one of the few exceptions where we
can't rely on our ability to correct written text.

Winfried
If you talk but you think what you have talk wrong..and you hear what 
you say..   It will be same for deaf peoples.

Re: [Standards] Accessibility (including XEP-0301)

[Edward Tie]

Op 29/06/2012 15:20, Winfried Tilanus schreef:

On 06/28/2012 01:45 PM, Mark Rejhon wrote:

Hi,


But, you know, aren't audio and video potential privacy issues too?
Especially if used during the wrong times?   It's no different.   (In
fact, often real-time text is more discreet at various times -- it's
quieter and shields from indiscreet sounds or images, while maintaining
real-time conversational interactivity -- and it is useful at various
moments)

I have done psychological counselling face to face, by phone, by
'line-by-line" chat and by RTT-chat. When somebody with RTT is
correcting a sentence, then you see what somebody first intents to say,
but doesn't want to send on second thought. That not only contains an
awful lot of information on the mindset of the person you are talking
to, it also is information the other didn't want to share. (And the mere
fact that that person didn't want to share it, is important information
too.)

So I can't rank RTT, audio and video from a privacy point of view, imho
RTT introduces a different kinds of privacy issues. But I do see a *big*
privacy issue with RTT and I don't think that when you enable Audio or
Video, RTT should be enabled automatically too.

Winfried
When he will think before he will talk to you... Is privacy issue when 
you must think before you will talk ?

Re: [Standards] Concept animation of XEP-0301 -- for improved specification understanding

[Edward Tie]

Op 29/06/2012 08:03, Mark Rejhon schreef:

Re: XEP-0301 Real-Time Text

I have created an easy-to-understand concept animation of XEP-0301 
real-time text, from the perspective of a web-based chat system:

http://www.realjabber.org/anim/facebook_chat_concept.gif

Can you made full resolution incl. facebook website and facebookchat 
concept ?

Re: [Standards] Accessibility (including XEP-0301)

[Edward Tie]

Op 28/06/2012 16:19, Simon McVittie schreef:

On 28/06/12 13:44, Edward Tie wrote:

Op 28/06/2012 14:18, Simon McVittie schreef:

RTT and audio/video do have a significant technical difference: RTT is
in-band, and audio/video (at least as implemented in Jingle) are
out-of-band.

I has disagree. RTT works already with SIP. See more info: Supported
real-time text codec is t.140.
RTT  must be convert to codec t.140 in SIP.

OK, let me rephrase that: XEP-0301 and XEP-0167 have the significant
technical difference that XEP-0301 is in-band, and XEP-0167 is out-of-band.

It's certainly possible to implement the general concept of RTT
out-of-band (as in T.140), and possible (although not very useful due to
performance problems) to implement audio/video in-band, but those aren't
the proposed standards we have for RTT and audio/video in XMPP.


Please Read : http://www.itu.int/rec/T-REC-F.703/en
Its new standaard F.703.



I do agree with the author of XEP-0301 that sending RTT in-band has some
important advantages over out-of-band.

 S

Re: [Standards] Accessibility (including XEP-0301)

[Edward Tie]

Op 28/06/2012 14:18, Simon McVittie schreef:

On 28/06/12 05:22, Kurt Zeilenga wrote:

I guess bandwidth-challedged XMPP networks should be fair and, if they
want to block one real-tine conversation method, block them all.

RTT and audio/video do have a significant technical difference: RTT is
in-band, and audio/video (at least as implemented in Jingle) are
out-of-band.

For in-band protocols the extra traffic (stream of partial messages)
goes through the server, whereas in out-of-band protocols, the vast
majority of the extra traffic is out-of-band, and the XMPP server only
sees some relatively lightweight signalling, which is O(number of calls)
rather than O(total length of calls). If Alice and Bob communicate via
(say) jabber.org, the Jingle traffic is a cost for Alice, Bob and their
respective ISPs, whereas the in-band XMPP traffic is a cost for Alice,
Bob and their ISPs, but also for jabber.org.

RTT over Jingle + ICE-TCP would be a closer equivalent, if there was a
finished XEP for Jingle + ICE-TCP; or in principle, RTT could even go
over ICE-UDP like audio and video do, if it can survive packet
loss/re-ordering.


I has disagree. RTT works already with SIP. See more info: Supported 
real-time text codec is t.140.

RTT  must be convert to codec t.140 in SIP.


Now, RTT is considerably "lighter" than audio/video, so it's not
necessarily a *significant* bandwidth cost for jabber.org (or whatever
server Alice and Bob are using) - but it is extra bandwidth that
jabber.org would not otherwise be using.

 S

Re: [Standards] XEP-0301 -- RFC about automatic mid-message resumption algorithms for RTT

[Edward Tie]

Op 27/06/2012 10:59, Kevin Smith schreef:

On Wed, Jun 27, 2012 at 9:44 AM, Mark Rejhon  wrote:

I used to have a number there a year ago.  I was told it's not a good idea
to define an arbitrary limit, so I don't think I should mention a specific
value, except general wording that it should be sufficiently small enough to
avoid becoming a congestion consideration.
The question is what wording to choose...

We shouldn't have numbers as arbitrary limits in normative language.
It's reasonable to have text like
"""
Real-world testing has shown that 1000 characters is a reasonable
limit for the length of RTT messages, and it is suggested that clients
use this default.
"""
but not
"""
RTT messages SHOULD be limited to 1000 characters
"""

/K

And Chinese , Thais and japanse  language ?

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

[Edward Tie]

Op 23/06/2012 01:15, Edward Tie schreef:

section 6.4.5


Any combination of audio, video, and real-time text MAY be used 
together simultaneously.  It will be called to Total Conversation.


Edward Tie


Can you added : Total Conversation may use XEP-0266 audio^[12] 
<http://en.wikipedia.org/wiki/Total_Conversation#cite_note-11> , 
XEP-0299 video and XEP-0301

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

[Edward Tie]

section 6.4.5


Any combination of audio, video, and real-time text MAY be used together 
simultaneously.  It will be called to Total Conversation.


Edward Tie

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

[Edward Tie]

Op 22/06/2012 21:56, Mark Rejhon schreef:

Short Version:
*We want to upgrade XEP-0301 (Real Time Text) from "Experimental" 
Status to "Draft" Status. *
*I'd like to hear your comments, edits for 
http://www.xmpp.org/extensions/xep-0301.html *
*I've already notified Peter.  I'd like everybody's comments -- feel 
free to reply*



Detailed Version:
(for those unfamiliar) Real-time text is text transmitted instantly 
while it is being typed or created. The recipient can immediately read 
the sender's text as it is written, without waiting. In addition, it 
is a very useful mode of communications for the deaf too, especially 
those who cannot use the phone, so this is a standard that enhances 
accessibility of XMPP chats.  It is a fun enhancement for main stream 
instant messaging, for whenever recipients are in a more chatty mood, 
too -- plus, the accessibility nature makes it interesting to 
accesibility purposes, such as text-to-9-1-1 emergency service for 
people who cannot use the phone, etc.


Our group (www.realtimetext.org ) is now 
working to solidify XEP-0301 so it can be upgraded to Draft status, 
given the recent use of evaluations of XEP-0301 for Next Generation 
9-1-1 (including at the FCC text-to-911 demo) as well as inquiries 
coming in from various Accessibility organizations.  The upgrade from 
"Experimental" status to the next step ("Draft") would be a huge step. 
 It is my (author's) opinion that the standard is almost ready, with 
just a bunch of minor corrections and fixes.  At least three different 
implementations are now available publicly, more to come, and at least 
a few private (internal) implementations being demoed.


If you just need a quick basic understanding without reading the whole 
standard yet,
A good introduction is written in the section 1 & 2 of 
http://www.xmpp.org/extensions/xep-0301.html


If you want to a webpage about what Real-Time Text looks like:
Animation at http://www.realjabber.org/real_time_text_demo.html

If you want to try it out:
There is a RealJabber installer from www.realjabber.org 
 -- it is a simple Google Talk client (for 
Windows) I wrote that implements XEP-0301


If you need to view open source code:
Full RealJabber: http://code.google.com/p/realjabber/ 

C# XEP-0301 module: 
http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText.cs
Java XEP-0301 module: 
http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java 

Note that the Java version implements Version 0.1 of the standard and 
the C# implements Version 0.2.  Both still interoperate with each 
other, thanks to the backwards compatibility.  All code is Apache 2.0 
open source code license, commercial use allowed.


I'd like your comments on changes, edits, revisions, corrections, 
improvements, those that you think would be widely agreed changes.

Currently queued corrections/revisions below:

Section 7.9: Last action element has missing tag closer:  
should be 

Section 7.7: "Cursor Pos" should be "Cursor Position"
Section 7.7: Reword the sentence about cursor position, for clarification.
Section 7.8: Clarify the phrase "The seq attribute always 
increments.", because seq can change whenever there's a different 
'event' attribute.
Section 7.9: Reword sentence "In order to maximize precision..." for 
clarity

Section 1 - Replace first two sentence with agreed consensus:
   Real-time text is text transmitted instantly while it is being 
typed or created. The recipient can immediately read the sender's text 
as it is written, without waiting.
Section 4.5.2 - Rename "Rules for Attribute Values" into "Summary of 
Attribute Values" for better consistency with "Summary of Action Elements"

Section 4.5.5 - Error: U+1 should be U+10
Section 4.6.3 - Add "or" to end of first bullet.
Section 4.6.3 - Turn number bullets into dot bullets because it isn't 
a sequence of events.
Section 4.6.4 - Change "in the following situations" to "in any of the 
following situations"

Section 6.1.2 - Add a link to [[[Monitoring Message Edits]]]
Section 6.1.3 - Change "to monitor or transmit" into "to transmit"
Section 6.1.3 - Change "for transcription." into "for real-time 
transcription."
Section 6.3.1 - Change "after an action element" to "after processing 
an action element"

Section 6.4.1 - Mention "(such as rapid copy and pastes)"
Section 6.4.1 - Missing auto-transmit text? (this appears to be a 
regression error)

Section 6.2 - In general, could be better & more concise eventually
Section 8 - This could be more clear and compact, with more efficient 
wording. There is too much fluff words.  Phrases are repeated (i.e. 
second paragraph in 8.2 repeats phrases already written in the first 
paragraph of sectoin 8).  Reword into more effici

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

[Edward Tie]

Op 22/06/2012 22:52, Peter Saint-Andre schreef:

On 6/22/12 2:50 PM, Mark Rejhon wrote:


The goal is:
*Deadline June 28-29: Last corrections submitted (before the Last Call
request)*
Early July: Publishing of XEP-0301 version 0.3
Immediately After: Request a Last Call and begin the process

OK, thanks for making that clear. I'll work to send feedback by then. We
can think of it as a "pre-last-call". ;-)

Peter


I agree that