the specification accurate and clearly written?
Yes
Gregg
Gregg Vanderheiden Ph.D.
Director Trace R&D Center and Professor Industrial & Systems Engineering and
Biomedical Engineering University of Wisconsin-Madison
Technical
Plus having the interop with regular XMPP (without real-time tex.
Gregg
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering University of Wisconsin-Madison
T
r you do them) If there are any
and send it to last call.
Gregg
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering University of Wisconsin-Madison
Techn
I like choice 1
Gregg
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
Technical Director - Cloud4all Project - http://Cloud4
Gregg
----
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
Technical Director - Cloud4all Project - http://Cloud4all.info
Co-Directo
On Aug 22, 2012, at 4:33 PM, Matthew Miller wrote:
> If you use an acronym, you MUST expand it. If Teletypewriter is not the
> correct expansion for TTY, then provide the correct one and include an
> authoritative citation.
Hm. TTY isn't an acronym anymore. It was at one time --
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 Ce
burst of real-time text.(same as above)
Gregg
On Aug 22, 2012, at 3:52 PM, Mark Rejhon wrote:
> On Wed, Aug 22, 2012 at 4:40 PM, Gregg Vanderheiden
> wrote:
>> I suggest we keep it simple.
>> anytime the mo
> *** CLARIFICATION #1
> Issue: Should I define an Implementation note about how sender clients
> should handle enabling/disabling of real-time text while in the middle
> of composing a message. (e.g. sender user types a message partially,
> and then clicks a button to deactivate real
ple 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
Well one thing missed is that the emergency responder (9-1-1 PSAP) is always
responding.
So I think you should have it that the first message from EITHER party should
be able to use to ping.
What about if you are in the middle of a message and it becomes clear that it
should move to rtt?
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.
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 Indust
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&a
even be using the same technology. That was
the only reason I raised the topic.
However, I think Mark has found a balance. Hope that works.
Gregg
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial &
capability but the user does not prefer to use it?
Thanks
Gregg
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
Co-Director, Raising t
On Jul 1, 2012, at 12:29 AM, Kurt Zeilenga wrote:
>
> I don't really object to the spec being called "real time text". What I
> object to is not keep clear (and separate) issues which pertain to RTT as a
> extension to XMPP IM vs. RTT as a part of 'total (real-time) conversation
> service".
ks.
Gregg
On Jul 1, 2012, at 12:19 AM, Kurt Zeilenga wrote:
>
> On Jun 30, 2012, at 3:28 PM, Gregg Vanderheiden wrote:
>
>>
>>
>> On Jun 30, 2012, at 4:21 PM, Kurt Zeilenga wrote:
>>
>> but please also don't call messaging 'real time&#x
Looks good.
On Jun 30, 2012, at 4:42 PM, Mark Rejhon wrote:
> There's two issues. I know you believe that turning off RTT completely
> is evil and I think that not allowing users to do so is also not good
> - I'm not suggesting anything about defaults, or policy. The issue I'm
> addressing i
o allow this interworking -- or
allow things that would block it -- or block the effective use of RTT in these
ways or in emergency situations.
See immediately previous note.
>
> -- Kurt
Gregg
Gregg Vanderheiden Ph.D.
Director Tr
andle RTT when it can - and it is just not the user's preference.
User choice is good.
Technical miscommunication of capabilities though is not a good idea I don't
think.
It is clear what I am getting at?
thanks
Gregg
Gregg Vanderheid
On Jun 29, 2012, at 11:05 AM, Kurt Zeilenga wrote:
> I have to wonder if vendors offer RTT without offering A/V, will there be
> claims made against them for discrimination because they didn't offer A/V.
> RTT, I would think, would have some users with disabilities. I have to
> wonder how
On Jun 29, 2012, at 9:36 AM, Winfried Tilanus wrote:
> 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.
I
s)
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://R
braille).
Gregg
---
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
On Apr 1, 2011, at 12:54 PM, Tobias Markmann wrote:
> Hi,
>
> our XEPs are currently p
7;s all
Thanks
Gregg
---
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
On Mar 25, 2011, at 9:49 PM, Kevin Smith wrote:
> At this point in the discussion, I'd like to ensu
o cause this IM to be viewed as less safe
for business than others.
Gregg
---
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
On Mar 25, 2011, at 6:25 PM, Mark
On Mar 2, 2011, at 7:04 AM, Dave Cridland wrote:
> On Wed Mar 2 12:35:58 2011, Gregg Vanderheiden wrote:
>> Those who need this feature can only use it if it is supported on the
>> technology (product) being used at both ends of the conversation.
>
> Right, so they
Interesting issues - thanks
Will reply after examining these issues a bit more - to provide more complete
and concise replies. But some are new topics/issues. Thanks for
hightlighting them.
Gregg
---
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Profe
LD be supported - and product
developers should understand the full implications of not implementing and
carefully weigh them before choosing to not include this feature.
Gregg
---
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Eng
time.
Gregg
---
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
On Mar 2, 2011, at 4:10 AM, Kevin Smith wrote:
> On Mon, Feb 28, 2011 at 8:52 PM, Mark Re
31 matches
Mail list logo
