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