date:20120709


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] Fwd: XEP-0301 Accessibility (resurrected)

On 7/9/12 12:52 PM, Matthew Wild wrote:
> On 9 July 2012 17:45, Mark Rejhon  wrote:
>> Gunnar, do you have any suggestions of alternatives that still meets the
>> 1-2-3 accessibility requirements?
>> 1. It should be possible for senders to signal intent.  (even if some
>> recipients may ignore)
>> 2. It should be possible for recipients that want to be informed, to
>> continue to be informed -- even if they turn off RTT, and they don't want to
>> advertise RTT capability.
>> 3. It should be possible for recipients to completely ignore or reject (as
>> if not supported), and not even advertise at all. (A few people have been
>> adamant about being able to do this)
>>
>> I also want to eliminate any accessibility blame from accessible
>> implementations.
>> Unfortunately, disco does not meet the 1-2-3 criteria above, all of which
>> have been asked by implementors.
>> So if the blank  is not suitable, I am open to other ideas.  Please
>> feel free to suggest...
>>
> 
> I'm afraid all this is mixing up protocol with implementation and UI,
> which is rarely a good thing. I understand your concerns, but your
> proposals do not address them and additionally make for a rather poor
> protocol.
> 
> The reality is that at the end of the day client implementations are
> beyond the control of you and I as protocol developers. If a client
> wants to have a global "Disable RTT" option then they will implement
> it, regardless of what you try to do to prevent it in this document. A
> client can just as easily ignore empty  as it can remove a
> feature from disco.
> 
> So that understood, we have to continue designing the protocol, not
> trying to anticipate clients. If a client says it does not support a
> feature then it is bad practice for another client to send that
> feature anyway.
> 
> As long as there is a mechanism provided in the protocol for making
> more granular (e.g. per-conversation) decisions about RTT then there
> should be no question of needing to use service discovery for anything
> but "I don't support this feature" and "I REALLY don't want to use
> this feature AT ALL" - both cases where trying to use RTT anyway will
> get you nowhere.

What Matthew says makes a lot of sense.

Mark, your "1-2-3 accessibility requirements" are not clear to me.

1. What does it mean to "signal intent"? XEP-0030 provides a way to
signal support. By "signal intent" do you mean interest in exchanging
RTT data with a particular conversation partner, or for a particular
chat session or MUC room, or something else?

2. What does it mean to "want to be informed"? Do you mean "want to
receive RTT data"? If so, again do you mean with a conversation partner
or for a session/room or something else?

3. It's always possible for a client to ignore anything it wants, so I
don't see what #3 is all about.

Thanks!

Peter

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

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] Fwd: XEP-0301 Accessibility (resurrected)

Regarding section 5 of XEP-0301:
http://xmpp.org/extensions/xep-0301.html#determining_support

On Mon, Jul 9, 2012 at 2:52 PM, Matthew Wild  wrote:

> The reality is that at the end of the day client implementations are
> beyond the control of you and I as protocol developers. If a client
> wants to have a global "Disable RTT" option then they will implement
> it, regardless of what you try to do to prevent it in this document. A
> client can just as easily ignore empty  as it can remove a
> feature from disco.
>
> So that understood, we have to continue designing the protocol, not
> trying to anticipate clients. If a client says it does not support a
> feature then it is bad practice for another client to send that
> feature anyway.
>

Matt brings up some good concerns to some passionate arguments, so there
should be some good agreement at least.
Prudent caution is warranted, for sure.  Many good standards in history are
filled with fueled debates, and the strongest standards often have some of
the strongest nay-sayers -- witness the browser wars, for example! :-)

Now, accessibility standards does influence implementers to an extent.
It bears worth noting that most of the information (such as
Activation/Deactivation) is in Implementation Notes.
_

Yes, having XEP-0301 move to draft status would be a good move now to be
able to reference it.

We have a *European standard* on the way for accessible public procurement,
similar to the american. We are just forming the version of it that will go
for member voting in August. We have made a structure for real-time text
requirements where XEP-0301 would fit in and be referenced, but we cannot
do it now when XEP-0301 is just experimental. We will see if there will be
a chance to get it in.

For the *American*, the web [U.S. Access Board -
www.access-board.gov] about the Section 255 - 508 refresh says about the
procedure, with a comment period that ended in March this year: "The Board
will follow-up with a proposed rule based on the input received that will
provide an additional round of comment before the rule is finalized."  That
has not happened yet, so there is likely time to make an effort to  be
mentioned in that regulation.

The cycle seems to be about 10- 15 years.

_

Matt, would you like to suggest some alternative mechanism to replace
Section 5?
I would welcome your comments.   At least a few (myself included) no longer
desire disco as the only method.
Re-surrecting XEP-0020 feature negotiation might be an option, and would be
a possible suitable alternative, but it is not presently appealing due to
increased complexity.   Certain other parts of the standard is getting
pretty well-designed -- there's been many compliments -- but we will
concede that Section 5 is controversial!

There are many usage scenarios that needs to be accomodated, such as
interop between an accessible client and a mainstream client, between
accessible clients, and between mainstream clients.  Some mainstream
clients may not advertise XEP-0301 capability until activated.The model
of sender initiatability / recipient notifyability needs to be a permitted
methodology, and I am pretty sure that someone else has a better method of
meeting that model.   It might even be that Section 5 might be in flux for
longer than expected, or it might eventually be agreed to remove Section 5
altogether (eliminate disco), falling back into  itself.

Ideas are welcome, for the Section 5 solution.

Thanks,
Mark Rejhon

Re: [Standards] Fwd: XEP-0301 Accessibility (resurrected)

2012-07-09 Thread Matthew Wild

On 9 July 2012 17:45, Mark Rejhon  wrote:
> Gunnar, do you have any suggestions of alternatives that still meets the
> 1-2-3 accessibility requirements?
> 1. It should be possible for senders to signal intent.  (even if some
> recipients may ignore)
> 2. It should be possible for recipients that want to be informed, to
> continue to be informed -- even if they turn off RTT, and they don't want to
> advertise RTT capability.
> 3. It should be possible for recipients to completely ignore or reject (as
> if not supported), and not even advertise at all. (A few people have been
> adamant about being able to do this)
>
> I also want to eliminate any accessibility blame from accessible
> implementations.
> Unfortunately, disco does not meet the 1-2-3 criteria above, all of which
> have been asked by implementors.
> So if the blank  is not suitable, I am open to other ideas.  Please
> feel free to suggest...
>

I'm afraid all this is mixing up protocol with implementation and UI,
which is rarely a good thing. I understand your concerns, but your
proposals do not address them and additionally make for a rather poor
protocol.

The reality is that at the end of the day client implementations are
beyond the control of you and I as protocol developers. If a client
wants to have a global "Disable RTT" option then they will implement
it, regardless of what you try to do to prevent it in this document. A
client can just as easily ignore empty  as it can remove a
feature from disco.

So that understood, we have to continue designing the protocol, not
trying to anticipate clients. If a client says it does not support a
feature then it is bad practice for another client to send that
feature anyway.

As long as there is a mechanism provided in the protocol for making
more granular (e.g. per-conversation) decisions about RTT then there
should be no question of needing to use service discovery for anything
but "I don't support this feature" and "I REALLY don't want to use
this feature AT ALL" - both cases where trying to use RTT anyway will
get you nowhere.

Regards,
Matthew

[Standards] Fwd: XEP-0301 Accessibility (resurrected)

Gunnar,

...I believe that we are talking about two different kinds of
"accessibility".
*I'm talking about mass-market accessibility factors*, like accessible
real-time text activation/deactivation workflows that are as permissive and
as easy to activate as possible, while simultaneously accommodating maximum
privacy and bandwidth concerns.

...I'm focussed on accessibility concerns from a mass market perspective.
 Suppose that XEP-0301 gets introduced into a mass-market messaging
client *used
by* *hundreds of millions* ... this is far more important than
rare interop between incompatible real-time text protocols which can is
done by gateways anyway, see below.   Even if only 1% activate the
real-time text, that's still a few million people!  It combines the privacy
advantages of texting with the immediacy/urgency of conversation --
activated the "chatty moments" via a button, and good for moments where
you're not allowed to make noises (phone calls not allowed).

...I recall you said you dislike deactivation?  Have you considered
accessibility issues when Activation/Deactivation workflows are introduced
to real-time text?  We all concede we must allow some implementors to have
the choice to have an Activation/Deactivation mechanisms for real-time text
(rather than blithely sending ).

...And you can see that using disco is flawed because it suggests senders
should not even try to initiate at all.  (Metaphorically speaking, Imagine
a telephone with a dialpad that completely disappears: The recipient
doesn't even want you to even attempt to dial the phone number.)   There
are implementations that WANT to be able to signal the recipient of an
attempt.  There are implementations that WANT to be able to notify the
recipient if the sender signals RTT, even if the recipient has RTT turned
off.
(Example: "*** Incoming Fast Text attempted.  However, you have Fast Text
turned off.  Click for Help Info")

...I need to remind that XEP-0301 is under evaluation by multiple vendors,
whose clients, grand total, are collectively used by more than one billion
people in the world.  Even if might not be used for a few months, years, or
year 2022 

On Mon, Jul 9, 2012 at 11:07 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:
>
>   28. Chapter 5. last paragraph. I hesitate a lot about this simple
> way of detecting support. We need a proper way to detect RTT capability
> before we start to use it.
>

This is already solved --
It is simply a gateway server implementation issue -- and the gateway
simply needs to follow section 6.2:
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text
Problem solved, without compromising human-accessibility concerns.

> There may be systems that have to select between different protocols for
> RTT, and they should not need to start sending in one protocol to try to
> discover if RTT is supported.
>

-- This is moot for all existing RTT protocols such as RFC4103, because
a gateway is needed anyway (see above)
-- For future real-time text protocols that goes under the same umbrella of
 (i.e. to support HTML) that can be extended with the xmlns Namespace
Versioning.  Or backwards compatible method, such as adding a new attribute.
-- For the theoretical scenario (probably not used by hundreds of millions)
RTP transmitting RFC4103/T.140 over Jingle, that's going to be a
specialized client anyway created by a few vendors such as you (Omnitor).
 You would still be able to follow your preferred scenario at
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text
by
attempting to activate at all times.  For fast-response, there are vendors
that want to implement XEP-0301 but do not want to reveal (for privacy
reasons) of XEP-0301 support until confirmed manually by the recipient.
Unfortunately I can't degrade the XEP-0301 standard for a mass-market
Activation/Deactivation scenario -- which you already concede is acceptable
if it permits a mass-market vendor to make XEP-0301 available (in a
"deactive by default") to hundreds of million of people.

Still, I realize the convenience of this simple method, and would let a
> discussion decide if it shall be kept.
> If it is kept, the paranthesis characters on the second line should be
> deleted so that the rapid response on this initiation is made part of the
> protocol.
>

This is reasonable to make it recommendable, although we have to also
support implementors that want to prompt the recipient for confirmation
first.  (see Activation/Deactivation methods).  So response on this
initiation may not be so quick.
There are some implementors that said they need to be allowed to ask the
recipient for permission first.

Many of us are far more focussed about accessible interoperability concerns
*between XMPP clients* that are used by *hundreds of millions*  "Hundreds
of millions users" is the key phrase here.

That is far, far, more important than minor interoperability concerns
betwee

Re: [Standards] Regarding XEP-0166

On 7/9/12 9:24 AM, Todd Herman wrote:
> Currently, specifically XEP-0176.  We have already implemented
> support for XEP-0166.  I may look into what is required to move that
> extension forward as well but for now I have to focus on XEP-0176
> (ICE).  I am actually doing all of this for Relayed Nodes (XEP-0278)
> which was just deferred I think. 

You might contact the author of XEP-0278 to see if he would like a
collaborator. He might not have time to move it forward.

> It is a lot of work so I have to
> approach it one piece at a time, which is currently ICE (XEP-0176).
> 
> I have no rush in moving anything from Draft (or deferred).  My main
> reason for brining that up is that while working on implementing the
> extensions and having questions asked and answered, the information
> could be very beneficial for updating the specifications and making
> them that much closer to being solidified.  I wasn't sure the
> approach for having an existing XEP updated in this manner or
> suggesting updates.

Post to the list, engage in discussion, and poke the authors about
updating the spec.

> I will jump on the jingle list you suggested.  I didn't realize that
> there was a different one.  Where do you typically draw the line
> between the two lists (standards and jingle)?

We use the jingle@ list for most Jingle-related discussions because not
everyone who is interested in Jingle is on the main standards@ list.

Peter

Re: [Standards] Regarding XEP-0166

2012-07-09 Thread Todd Herman

Currently, specifically XEP-0176.  We have already implemented support for 
XEP-0166.  I may look into what is required to move that extension forward as 
well but for now I have to focus on XEP-0176 (ICE).  I am actually doing all of 
this for Relayed Nodes (XEP-0278) which was just deferred I think.  It is a lot 
of work so I have to approach it one piece at a time, which is currently ICE 
(XEP-0176).

I have no rush in moving anything from Draft (or deferred).  My main reason for 
brining that up is that while working on implementing the extensions and having 
questions asked and answered, the information could be very beneficial for 
updating the specifications and making them that much closer to being 
solidified.  I wasn't sure the approach for having an existing XEP updated in 
this manner or suggesting updates.

I will jump on the jingle list you suggested.  I didn't realize that there was 
a different one.  Where do you typically draw the line between the two lists 
(standards and jingle)?

Todd

-Original Message-
From: Peter Saint-Andre [mailto:stpe...@stpeter.im] 
Sent: Monday, July 09, 2012 11:17 AM
To: XMPP Standards
Cc: Todd Herman
Subject: Re: [Standards] Regarding XEP-0166

On 7/9/12 9:03 AM, Todd Herman wrote:
> I am working on updating my C# XMPP library to support  XEP-0176.  
> Since I don’t know too much about the main subject I first read 
> through the STUN and TURN specifications.  I am currently finishing up 
> reading through the ICE specifications now and will be starting on 
> XEP-0176 very soon.

Thanks for your interest. Are you talking only about XEP-0166 (the core Jingle 
spec), XEP-0176, or also other specs in the Jingle suite?

> The main point of this message is that I will most likely have many 
> questions related to the XEP in the very near future.

I think it is best to ask such questions on the jin...@xmpp.org list:

http://mail.jabber.org/mailman/listinfo/jingle

> I also noticed
> that it is draft and wanted to know what I could do to perhaps push 
> the extension to the next step and take it out of draft.

We're not always in a hurry about pushing specs from Draft to Final. The best 
example is XEP-0045, which is widely implemented but has been Draft since 2002. 
Another is XEP-0047 (In-Band Bytestreams), which we just recently pushed to 
Final but which had been Draft since 2003.

So you can see that we like specifications to be stable and widely implemented 
before we go from Draft to Final. That said, if a technology meets those 
conditions then by all means let's consider it.

Is there a particular hurry in the case of XEP-0176?

I'll also note that the fact that you have many questions about XEP-0176 might 
indicate that it's not quite ready to go to Final. :)

> Also, I do have one specific related question.  Both the ICE 
> specification and XEP-0176 mention that candidates are validated by 
> sending STUN binding requests and responses.  The specifications 
> indicate that these responses and requests are sent between the 
> clients (assuming that is what the candidates refer to) rather than to 
> a STUN server.  I wanted to confirm that this is accurate and that 
> this means the clients, which are XMPP clients, would also need to be 
> able to function as STUN servers in order to interpret and respond to the 
> requests.

I'll forward that question to the jingle@ list for discussion there.

Peter

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

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] Regarding XEP-0166

On 7/9/12 9:03 AM, Todd Herman wrote:
> I am working on updating my C# XMPP library to support  XEP-0176.  Since
> I don’t know too much about the main subject I first read through the
> STUN and TURN specifications.  I am currently finishing up reading
> through the ICE specifications now and will be starting on XEP-0176 very
> soon.

Thanks for your interest. Are you talking only about XEP-0166 (the core
Jingle spec), XEP-0176, or also other specs in the Jingle suite?

> The main point of this message is that I will most likely have many
> questions related to the XEP in the very near future. 

I think it is best to ask such questions on the jin...@xmpp.org list:

http://mail.jabber.org/mailman/listinfo/jingle

> I also noticed
> that it is draft and wanted to know what I could do to perhaps push the
> extension to the next step and take it out of draft.

We're not always in a hurry about pushing specs from Draft to Final. The
best example is XEP-0045, which is widely implemented but has been Draft
since 2002. Another is XEP-0047 (In-Band Bytestreams), which we just
recently pushed to Final but which had been Draft since 2003.

So you can see that we like specifications to be stable and widely
implemented before we go from Draft to Final. That said, if a technology
meets those conditions then by all means let's consider it.

Is there a particular hurry in the case of XEP-0176?

I'll also note that the fact that you have many questions about XEP-0176
might indicate that it's not quite ready to go to Final. :)

> Also, I do have one specific related question.  Both the ICE
> specification and XEP-0176 mention that candidates are validated by
> sending STUN binding requests and responses.  The specifications
> indicate that these responses and requests are sent between the clients
> (assuming that is what the candidates refer to) rather than to a STUN
> server.  I wanted to confirm that this is accurate and that this means
> the clients, which are XMPP clients, would also need to be able to
> function as STUN servers in order to interpret and respond to the requests.

I'll forward that question to the jingle@ list for discussion there.

Peter

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

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] XEP-0301 Accessibility (resurrected)


Mark wrote:
Peter/Kevin did express last year it was not "xmpp-ish", but a 
majority of people I correspond with, say Accessibility concerns is 
more important.  (See above)
XEP-0301 is slightly an outlier of a standard here, because it 
contains lots of elements normally reserved for other layers.  It 
essentially has its own error detection and recovery, which is already 
proven necessary in real-world testing (mentioned in past messages, 
and now encapsulated at 
http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized ). 
 It's so self-contained that it's making better and better sense (due 
to Accessibility, too), to put activation/deactivation capabilities 
inline into it, irregardless of disco.
Bandwidth concern was mentioned last year but sending a single 
 element actually uses less bandwidth than sending a disco iq. 
 So the bandwidth concern is essentially moot.
Again, I also like the simplification that putting 
activation/deactivation features inline into  does, making 
"XEP-0301 plugins" much easier for many existing clients using their 
existing XMPP libraries?



I'd like to hear comments from other people about this "Accessible" 
improvement to "Determining Support".
If there are anybody here who dislikes this, I'd like suggestions of 
alternatives that still meets the 1-2-3 accessibility requirements 
mentioned above.


Thanks,
Mark Rejhon


Mark,
Was it my comment 28 that caused your response about accessibility?

28. Chapter 5. last paragraph. I hesitate a lot about this simple way of 
detecting support. We need a proper way to detect RTT capability before 
we start to use it. There may be systems that have to select between 
different protocols for RTT, and they should not need to start sending 
in one protocol to try to discover if RTT is supported.
Still, I realize the convenience of this simple method, and would let a 
discussion decide if it shall be kept.
If it is kept, the paranthesis characters on the second line should be 
deleted so that the rapid response on this initiation is made part of 
the protocol.



I did not understand your reasoning, why the empty  method to start 
RTT would be more accessible than the Determining support with Disco. 
Please explain!


I wanted to say that I liked the Disco method, because then a multimedia 
system can interrogate what ways it has available to get a real-tine 
text media channel going with another party.
We see some efforts to declare XMPP media in SIP, and we have RTP 
possibilities in XMPP through Jingle. For these cross-technogy efforts, 
it will be crucial to be able to check detailed functionality of the 
other party to decide what media transport to use.
It is not sufficient to know that XMPP is supported for a text channel. 
We also need to be able to check if XEP-0301 is supported before we 
select to go the XMPP way with media establishment. Similarly as with 
the text/t140 sdp declaration for RFC 4103.


Sending empty rtt implies that we have already selected to use XMPP, and 
then want to try to initiate real-time text in that channel. What if the 
other party did not have that support, but had RTP based RFC 4103. Do we 
then need to continue with clunky message-wise texting just because we 
took a chance to check if RTT was available the XMPP-way. That is not 
what we wantwith accessibility.


However in my comment 28, I also say that I realize that it is simple 
and convenient for cases when you only have XMPP at hand, and need to 
select between clunky or smooth. And thatI want discussions like this 
lead to a decision if both methods shall be mentioned. Options are 
usually harmful and lead to uninteroperability.



Gunnar

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

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

[Standards] Regarding XEP-0166

2012-07-09 Thread Todd Herman

I am working on updating my C# XMPP library to support  XEP-0176.  Since I 
don't know too much about the main subject I first read through the STUN and 
TURN specifications.  I am currently finishing up reading through the ICE 
specifications now and will be starting on XEP-0176 very soon.

The main point of this message is that I will most likely have many questions 
related to the XEP in the very near future.  I also noticed that it is draft 
and wanted to know what I could do to perhaps push the extension to the next 
step and take it out of draft.

Also, I do have one specific related question.  Both the ICE specification and 
XEP-0176 mention that candidates are validated by sending STUN binding requests 
and responses.  The specifications indicate that these responses and requests 
are sent between the clients (assuming that is what the candidates refer to) 
rather than to a STUN server.  I wanted to confirm that this is accurate and 
that this means the clients, which are XMPP clients, would also need to be able 
to function as STUN servers in order to interpret and respond to the requests.

Todd Herman

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)

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] XEP-0301 Accessibility (resurrected)

Resuming the Accessibility discussions from last week, since Gunnar brought
up concern.

We recall Kevin and Kurt's concerns, including Kurt saying:

> The argument I'm making here is that if the user says "I do not want
> to ever do RTT, I do not want to receive it, I do not want to be
> prompted to receive it" then they shouldn't receive it, they shouldn't
> be prompted to receive it, and people chatting to them shouldn't be
> misled into thinking they might be able to use it.

* Unfortunately, this is frequently /indistinguishable/ from actual user
intent;*
'I want to do RTT and be notified about it, but my software only lets me
turn off RTT for everyone'
'My RTT is off because I dont know what RTT is and my software has it off
by default'
'I forgot to turn it on'
I have fixed the specification to satisfy Kurt and Kevin's concerns, and
Gregg Vanderheiden seems happy with it, as am I:
http://xmpp.org/extensions/xep-0301.html#determining_support
*"Enabling/disabling of discovery is SHOULD NOT be the default method of
activating/deactivating real-time text. See Activating and Deactivating
Real-Time 
Text.
  *
*In the absence of feature discovery, sender clients MAY send a single
blank  element at the beginning of the session (or upon sender
attempting to initiate real-time text), as a method of indicating to the
recipient that real-time text is permitted until the end of the chat
session. Senders SHOULD NOT send any further  until incoming 
is received during the same chat session, or when support is confirmed via
discovery."*

Since I now claim the use of disco as the sole tool for this method, is
flawed from an Accessibility perspective, and nobody objected to my intent
to allow senders to signal a desire to begin real-time text According to
Activating/Deactivating Real-Time Text, sending a single  upon sender initation of real time text is suggested)
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text

Given, XEP-0301 may be used in situations where is certain deaf people's
(like me) real-time conversational (sub-1-second latency), where text is
used conversationally, like telephone users use audio conversationally
and we have accessibility legislators in both USA and Europe that are
interested in citing XEP-0301 (I even posted quotes from those emails two
weeks ago, and Peter Saint Andre has expedited his reviews as a result of
this, too.), and because I am deaf (cannot use the phone), I am defending
Accessibility aspects of this specification.

It has very important "Accessibility" advantages, for the modification that
I made:

*1. It satisfies Accessibility requirements by giving senders a chance to
signal.*
(Rather than recipient blocking real-time text)

*2. It allows "Accessible" implementations from both a sender and/or
recipient perspective:*
-- Sender can attempt to initiate an RTT call, by signalling.
-- Recipient can be informed of incoming RTT call attempts even if ignored
(because sender did send a signal)

*3. It satisfies Kurt and Kevin's concerns last week; implementations can
still choose to ignore (Section 6.2.1 Activation Methods)*
(That means any potential Accessibility blame is shifted to such
implementation that turns off disco to deactivate RTT; and the "accessible
implementations" have immunity from blame.  There might be excellent
reasons (i.e. transcription bot services, DoS/security concerns, etc.).
However, it makes Accessibility responsibilities pretty plainly clear for
both senders/recipients, and it's easier to tell who's complying with
accessibility norms, and who's not complying with accessibility norms.

All satisfied now by the sender allowed ability to send a single  upon initation. (which uses less bandwidth than disco
anyway between the sender and the recipient)
 And because sending a single  is now allowed, the
disco (flawed for meeting accessibility needs) is downgraded from REQUIRED
to RECOMMENDED.
http://xmpp.org/extensions/xep-0301.html#determining_support

Even if the  signal is used, the disco is still useful
-- as a persistent "I'm accepting real-time text calls" announcement if the
software clients wish to support such a feature. (To easily list which
buddies support real-time text and freely stream multiple  elements
right away to, without further confirmation.)


Ease of Real-Time Text:
Also, a secondary reason of permitting  be used as the alternate
method of determining support, is that it greatly simplifies
implementations in many situations.   It allows implementations where
 is completely inline.  In one situation earlier this year, I have
wasted at least 8 hours trying to figure out how to properly add disco to a
fairly poorly documented XMPP library, that was otherwise able to function
well with  extension.  Although the blame is on the poor
documentation, it does lead to simpler implementations when trying to
rapidly create ma

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)

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)

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)