Mark,
Version 0.9 of XEP-0301 reads really well. It appears to cover all the
issues that were raised some time ago - and some parts are even easier to
understand. It is a very comprehensive Spec. Well done.
It appears to be ready for Last Call for Draft.
Cheers,
/Barry
Barry Dingle
Fixed - +61
able bounds.
Cheers,
/Barry
Barry Dingle
Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng.,
Australia
> Apple + Linux + Open Source software
On Sun, Aug 19, 2012 at 12:02 PM, Mark Rejhon wrote:
> The use of key press
a *one sentence/paragraph* about approximate qualitative
improvement in user perception of delay when using KPI's at BOTH ends?
The paragraph could also mention that the extra contents per stanza when
using KPI is compensated for by stanza's being sent at a lower rate. (This
information co
contents to:
*my J***
and
*uliet!*
respectively.
This retains the readability but also shows that the is sent
independently of word boundaries.
Cheers,
/Barry
Barry Dingle
Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng
-time text transcoding is
straight forward except *for* the editing feature of this specification.
Backwards positioning and insertion or deletion far back in the message can
cause a large number of erase operations in T.140 that take
*processing*time and bandwidth to convey.”
*Appendix D*
Something like the Framework document (RFC5194) for RFC4103
real-time text. Something is needed to discuss how to interwork between
Textphone/TTYs that support text and/or voice with XEP-0301 plus voice in
some form.
Cheers,
/Barry
Barry Dingle
Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578
Fel
27;Experimental'.)
I think the current reference to Jingle in 6.4.5 is sufficient. It leads
the reader to Jingle and its related XEP's.
Cheers,
/Barry
Barry Dingle
Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng.,
public specifications of protocols before
they will specify their use in their Requirements. Casual enhancements
will not 'fly' with them.
Cheers,
/Barry
Barry Dingle
Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng.,
love to use
(especially with their need for 'immediacy') which could create an extended
market for XMPP.
I like the idea of XMPP-RTT as it appears to meet both of those needs. And
the Chat mode and RTT mode seem to sit well together - which is very
important.
Cheers,
/Barry
Barry D
