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

Matthew Miller linuxwolf at outer-planes.net
Wed Aug 22 20:28:53 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Aug 22, 2012, at 13:35, Mark Rejhon wrote:

> Hello Matthew,
> 
> Thanks for your comments!
> I eager await your ongoing comments.  Just some brief reply:
> 
> 
> On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller
> <linuxwolf at outer-planes.net> wrote:
>> * Reword the paragraph 3 in terms of the problems it is solving. One possible suggestion:
> 
> I like the inclusion of the following: It can also allow immediate
> conversation in situations where speech cannot be used (e.g. quiet
> environments, privacy, deaf and hard of hearing).
> 

That's fine.

> One potentially popular application that some end-users told me (plus
> potential users, like a friend of mine, who works in the military,
> where some secure text-messaging systems are used) is the ability to
> communicate quietly, privately, and covertly, using text -- and
> real-time text would also speed up communications without the sound of
> speaking, and without waiting for complete sentences of messages.  So
> any rewordings of the paragraph, should be able to adequately cover
> the above useful scenario of being able to communicate voice-style
> using text, without making noises.
> 

Just remember the target audience is implementers.  They'll usually already have a problem that this specification can solve.  You really really don't need to go into all possible problems this can solve.

> 
>> While XMPP CORE [RFC6120] and XMPP IM [RFC6121] provides for near real-time text conversation, this is often as sentences or sentence fragments that convey complete thought on the part of the sender, in a linear progression, as the user directs.
> 
> One observation -- by the deaf audience's eyes, instant message
> threads are not considered live (real-time) conversations because it
> implies forced waiting by recipients for sender messages.
>  This can be
> important during a deaf person's potential "fastest possible method of
> communicating".  So, I would prefer not to use the phrase "near
> real-time text" verbatim, because it's only as real-time as the sender
> wants it to be -- e.g. how frequently the sender hits Enter.   It
> could even be once every minute, which can lead to annoying waits, and
> is not near-real time.  I will try to find another synonym phrase.
> Also, in some accessible communities, the word "conversation" has a
> different definition.
> But you have a good point, my old text might not be good either to
> certain audiences.
> The challenge is, what text to replace with?
> 
> So, the challenge is, the paragraph needs to be written both
> geek-friendly (people like you and me) and deaf-friendly (one part of
> the audience).  The wording that you chose, will need to be tweaked.
> Although real-time text can be viewed (by some) as an accessible
> technology, it does have military and emergency applications, as well
> as teen texting applications, etc.  It's a challenge, fine balancing
> act, since I'm catering to so many potential audiences with this spec.
> 
> Mark Rejhon


Like it or not, XMPP fits the generally-accepted definition of "near real-time" (or "near-real-time" if you prefer hyphens). It has been applied to XMPP since (at least) internet-drafts of RFC3920 (circa 2003).

Also, this is a technical specification, not a marketing document.  You have realtimetext.org for marketing; XEP-0301 is for technicals.


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

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

iQEcBAEBAgAGBQJQNUEGAAoJEJq6Ou0cgrSPEn4H/2wIvFdYPOZBnDzYc4aHNdFY
FnBNCAMXaUXZA0z2Y1r6rTYfny9/j7iFpZUyqfja5d4PuAE5nuSZqDdzuAmjFcnX
SC5tJ6T1uq33zxrDJXiQ+ne2qpqXRikhLg7maSQwsj769lVUU0y3oL1gsoqlTBRM
h9ZXBxuyLPwKW3TZCAp9XuroMIIyfW4y+ox+awgtvOLzr+No19GUHt1C85rwiPxj
xIafH1EN+p48ClUrFSxuq5AKkABwaQ3dqZLtWSuQLO61XDmf6QzkRRPb2VodRMvf
3ZhkzAMFJKES9aQ0n8Xv7Do6F7RWiD56OBusJSxM+pf1zbYfcVSp017HTEyQ7Oo=
=Uviu
-----END PGP SIGNATURE-----



More information about the Standards mailing list