Am 07.03.2012 19:28, schrieb Mark Rejhon: > Hello, > > I am on the go (on phone), so replying off the mailing list but two things > caught my attention: > I assume it was accidentally not CCed to the list then. It is CCed on this reply, I hope that is okay.
> 1. Xep-0301 never uses relative cursor positioning. I am confused. > Can you re-explain, because <e> and <d> have always used absolute positioning > and aren't being changed here; just the discussion whether to eliminate one > or the other. > Maybe that was the case in your implementation, however XEP-0301 currently states: "* For <e> element (Backspace), the cursor position is moved left as text is deleted. * For <d> element (Forward Delete) and all other action elements, the cursor position is unaffected." This sounds like relative positioning to me. Absolute would be setting the cursor position to the 'p' attributes value for forward delete and to the difference of 'p' and 'n' attributes on backwards delete > 2. Advertising of RTT must always be done, for accessibility reasons. > We can't disable section 5 or it defeats the ability of deaf people to > attempt to initiate a RTT conversation in Adium/Pidgin (and soon google, microsoft, etc). > The goal of RTT is to become a widespread protocol in ten years, much like > closed captioning. > We want to be able to let the recipient be notified of an incoming RTT and to > let the recipient decide whether to turn on/off RTT. > If we stop advertising RTT, deaf people can't make call and the hearing > person with the RTT off, won't ever be notified. > Can you suggest an alternative method of refusing RTT that does not require > disabling disco? > That is possibly quite different though. If a client is configured to always reject RTT sessions there is no point in ever offering it to that client. Therefore it's perfectly fine for such a client to not send the disco feature. I think what you're concerned about is not that people can't receive RTT messages, but rather that they can't be prompted to send them. A possible way forward might be to define one feature indicating willingness to receive RTT messages, and one indicating willingness to send them upon request. Which would of course imply introducing a way to request a session, as opposed to having a way to cancel a session you never asked for. Possibly someone else can come up with a yet better idea though.
