Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

On 2012-08-23 00:34, Matthew Miller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 16:32, Gunnar Hellström wrote: /The US Access Board has the following definition in its latest proposal for Accessible procurement, Section 508. E.103.4 /http://www.access-board.gov/

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

On 2012-08-23 03:27, Peter Saint-Andre wrote: On 8/22/12 12:30 PM, Matthew Miller wrote: First, this section is written more as a marketing pitch and less as a technical description. This bothers me enough that I strongly urge it be changed. Strangely, this section didn't bother me much. I'm

Re: [Standards] review of XEP-0301, sections 6-14 - #41 IM research

On 2012-08-23 04:40, Peter Saint-Andre wrote: 41. I think Section 10.3 could be improved with some more focused review. ... Can you cite any of the university studies on message length? I found one: http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf It says that average m

Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)

I think is specification is needed. It serves a purpose and it might be used by other xeps to propagate message (or request) through a network of friends. I don't think the use case with message is enough. It would be more clear if it had an use case with an IQ. It is not clear how one should resp

[Standards] review of XEP-0301, sections 6-14

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In this message I continue my review of XEP-0301, starting with Section 6 (my previous message contained 32 comments, so I begin this list with #33). 33. "with heavy packet-bursting tendencies" -- perhaps "susceptible to significant packet loss". 34.

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/22/12 12:30 PM, Matthew Miller wrote: > First, this section is written more as a marketing pitch and less > as a technical description. This bothers me enough that I strongly > urge it be changed. Strangely, this section didn't bother me much.

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 16:33, Gregg Vanderheiden wrote: > On Aug 22, 2012, at 5:05 PM, Matthew Miller > wrote: > >> What would help most to alleviate this discussion further is to include an >> authoritative citation. > > > here is one. TTY takes

[Standards] LAST CALL: XEP-0297 (Stanza Forwarding)

This message constitutes notice of a Last Call for comments on XEP-0297 (Stanza Forwarding). Abstract: This document defines a protocol to forward a stanza from one entity to another. URL: http://xmpp.org/extensions/xep-0297.html This Last Call begins today and shall end at the close of busine

[Standards] Fwd: [Council] Minutes -- 2012-08-22T15:00:00Z

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Begin forwarded message: > From: Matthew Miller > Date: August 22, 2012 16:38:53 MDT > To: XMPP Council > Subject: Minutes -- 2012-08-22T15:00:00Z > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > COUNCIL MEETING MINUTES - 2012-08-22T15:00:0

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

Op 23/08/2012 00:32, Gunnar Hellström schreef: On 2012-08-23 00:05, Matthew Miller wrote: I do not see TTY as an acronym anymore. It is like BT that was read out British Telecom before, but is now just BT. Or AT&T was read out American Telephone and Telegraph, but is now just AT&T Wiktionary

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 16:32, Gunnar Hellström wrote: > /The US Access Board has the following definition in its latest proposal for > Accessible procurement, Section 508. E.103.4 > /http://www.access-board.gov/sec508/refresh/draft-rule.htm > / > TTY.

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

On Aug 22, 2012, at 5:05 PM, Matthew Miller wrote: > What would help most to alleviate this discussion further is to include an > authoritative citation. here is one. TTY takes you here - and it is all discussed. http://en.wikipedia.org/wiki/Telecommunications_device_for_the_deaf Gregg --

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

On 2012-08-23 00:05, Matthew Miller wrote: I do not see TTY as an acronym anymore. It is like BT that was read out British Telecom before, but is now just BT. Or AT&T was read out American Telephone and Telegraph, but is now just AT&T Wiktionary has solved it by putting (originally) after Tele

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

Op 22/08/2012 23:42, Mark Rejhon schreef: Is this politics-proof: "TTY (derived from teletypewriter) and text telephones" I don't like it, but I am going to leave it unmodified (against M&M wishes) unless there's a consensus. I agree with gregg. it's history. At this time many deaf poeple haven

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 15:51, Gunnar Hellström wrote: > > On 2012-08-22 23:35, Gregg Vanderheiden wrote: >> agree >> >> You can say >> >> TTY was derived from Teletypewriter - a device originally used by people who >> are deaf to communicate. But t

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 15:42, Mark Rejhon wrote: > Is this politics-proof: > > "TTY (derived from teletypewriter) and text telephones" > > I don't like it, but I am going to leave it unmodified (against M&M > wishes) unless there's a consensus. > Si

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

On 2012-08-22 23:35, Gregg Vanderheiden wrote: agree You can say TTY was derived from Teletypewriter - a device originally used by people who are deaf to communicate. But today Teletypewriters no longer exist and TTY is used to refer to a type of telecommunications device used by people wh

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

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

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

Is this politics-proof: "TTY (derived from teletypewriter) and text telephones" I don't like it, but I am going to leave it unmodified (against M&M wishes) unless there's a consensus. On Wed, Aug 22, 2012 at 5:35 PM, Gregg Vanderheiden wrote: > agree > > You can say > > TTY was derived from Te

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

agree You can say TTY was derived from Teletypewriter - a device originally used by people who are deaf to communicate. But today Teletypewriters no longer exist and TTY is used to refer to a type of telecommunications device used by people who are deaf that supports Baudot (and sometimes ot

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 15:28, Gunnar Hellström wrote: > I do not think expansion of TTY to Teletypewriter is a good idea. That tends > to mean the other use of the term TTY, the device that was often used as a > computer operator console terminal a l

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

On 2012-08-22 22:58, Mark Rejhon wrote: On Wed, Aug 22, 2012 at 4:46 PM, Matthew Miller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 14:42, Mark Rejhon wrote: On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller wrote: * Teletypewriter (TTY) and Text Device for the

Re: [Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

Ah good points so how about 1) changing from real-time text to messaging - would just result in the characters being stored up until the person sent send. At that point the accumulated text would be sent as a burst of real-time text and a send. The device would then continue in message mode

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

On Wed, Aug 22, 2012 at 4:46 PM, Matthew Miller wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Aug 22, 2012, at 14:42, Mark Rejhon wrote: > >> On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller >> wrote: >>> * Teletypewriter (TTY) and Text Device for the Deaf (TDD) telephones >>>

Re: [Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

On Wed, Aug 22, 2012 at 4:40 PM, Gregg Vanderheiden wrote: > I suggest we keep it simple. > anytime the mode is switched the equivalent of "an ellipsis and SEND" is sent. > - for real time text switched to message: the text will have already been > sent up to the switch, so terminating that strin

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 14:42, Mark Rejhon wrote: > On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller > wrote: >> * Teletypewriter (TTY) and Text Device for the Deaf (TDD) telephones >> [citations recommended] > > Consulted with some peers. > > TTY exp

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

On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller wrote: > * Teletypewriter (TTY) and Text Device for the Deaf (TDD) telephones > [citations recommended] Consulted with some peers. TTY expansion to Teletypewriter -- OK, good idea. TDD is actually correctly "Telecommunications Device for the Deaf"

Re: [Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

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

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

-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 > wrote: >> * Reword the paragraph 3

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

On Wed, Aug 22, 2012 at 8:35 PM, Mark Rejhon wrote: > 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). It's worth noting that XEPs are necessarily written for the target audience of implementers,

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

On Wed, Aug 22, 2012 at 9:02 PM, Mark Rejhon wrote: > On Wed, Aug 22, 2012 at 3:58 PM, Matthew Miller > wrote: >>> What about URLs that are not in elements? >> >> Frankly, "too bad so sad". The sender really ought to have put them in >> anchors in the first place. > > It seems some XHTML-IM cl

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

On Wed, Aug 22, 2012 at 8:56 PM, Joe Hildebrand (jhildebr) wrote: > On 8/22/12 10:33 AM, "Matthew Miller" wrote: > >>I agree with Sergey. If you received XHTML-IM, then any other rich text >>transform ought to be disabled/bypassed. > > What about URLs that are not in elements? I remember us ch

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

On Wed, Aug 22, 2012 at 3:58 PM, Matthew Miller wrote: >> What about URLs that are not in elements? > > Frankly, "too bad so sad". The sender really ought to have put them in > anchors in the first place. It seems some XHTML-IM clients seem to URL-ize links that are not already URL-ized. This

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 13:56, Joe Hildebrand (jhildebr) wrote: > On 8/22/12 10:33 AM, "Matthew Miller" wrote: > >> I agree with Sergey. If you received XHTML-IM, then any other rich text >> transform ought to be disabled/bypassed. > > What about URL

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

On 8/22/12 10:33 AM, "Matthew Miller" wrote: >I agree with Sergey. If you received XHTML-IM, then any other rich text >transform ought to be disabled/bypassed. What about URLs that are not in elements? -- Joe Hildebrand

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

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 wrote: > * Reword the paragraph 3 in terms of the problems it is solving. One possible > suggestion: I like the inclusion of the following: It

Re: [Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

Hello, I've managed to address most of Peter's section 1-5 concerns. However, for the remainder -- I need advice from anyone on unaddressed parts of Peter's comments about XEP-0301 ( http://xmpp.org/extensions/xep-0301.html ) There are only five major areas of clarifications I need relating to Pet

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'll slowly be commenting mostly on a section-by-section basis. These are my comments regarding section 1 of XEP-0301: Real-Time Text. There might be some mention of these earlier, but I've lost track. If already addressed previously, then please

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. - - m&m Matthew A. Miller On Aug 22, 2012, at 02:35, Sergey Dobrov wrote: > On 08/22/2012 02:31 AM, Joe Hilde

[Standards] Fwd: Minutes 20120815

report on the IETF meeting (see the logs) 3) Date of next meeting 20120822 1500GMT 4) Any other business. None

[Standards] Fwd: Minutes 20120808

-- Forwarded message -- From: Kevin Smith Date: Wed, Aug 22, 2012 at 2:09 PM Subject: Minutes 20120808 To: XMPP Council Sorry for the delay in these. Logs: http://logs.xmpp.org/council/120808/ 1) Roll call Matt, Matt, Tobias, Kev present, Ralph absent 2) RTT A discussion about r

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

On 08/22/2012 02:31 AM, Joe Hildebrand (jhildebr) wrote: > Or suggest to change *this* to this or > *this*. No, the thing is that a client changes this: *this*that in the *incoming* message to this: thisthat which is obviously wrong since a sender can make things strong without such plain text