Re: [Standards] Proposed XMPP Extension: In-Band Real Time Text

2011-02-24 Thread Gunnar Hellström

I think it is very good that this extension proposal is made.

There are real-time text standards for a lot of environments before: 
PSTN, H.320, T.120, H.324, H.323, SIP, IMS,
and it is time that this smooth way of text communication come to the 
benefit of XMPP users as well.


Gunnar



Mark Rejhon skrev 2011-02-24 18:55:

Hello,

Screenshot link:
http://marky.com/misc/xmpp/RealTimeText_AnimatedDemo.gif

This is provided as a reference to everyone who doesn't know what
Real-Time Text is.  This real-time text standard includes keypress
delay recording, so typing looks natural even if transmitted at only
one message every second (or few).  This software will be released as
open source during the month of March.

Sincerely,
Mark Rejhon
(Author of XMPP In-Band Real Time Text Extension)


 Original Message 
Subject: [Standards] Proposed XMPP Extension: In-Band Real Time Text
Date: Wed, 23 Feb 2011 17:54:27 +
From: XMPP Extensions Editor
Reply-To: XMPP Standards
To: standards@xmpp.org

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: In-Band Real Time Text

Abstract: This is a specification for real-time text transmitted in-band
over an XMPP session.

URL: http://www.xmpp.org/extensions/inbox/realtimetext.html

The XMPP Council will decide at its next meeting whether to accept this
proposal as an official XEP.


Re: [Standards] Proposed XMPP Extension: In-Band Real Time Text

2011-02-24 Thread Mark Rejhon
Hello,

Screenshot link:
http://marky.com/misc/xmpp/RealTimeText_AnimatedDemo.gif

This is provided as a reference to everyone who doesn't know what
Real-Time Text is.  This real-time text standard includes keypress
delay recording, so typing looks natural even if transmitted at only
one message every second (or few).  This software will be released as
open source during the month of March.

Sincerely,
Mark Rejhon
(Author of XMPP In-Band Real Time Text Extension)


 Original Message 
Subject: [Standards] Proposed XMPP Extension: In-Band Real Time Text
Date: Wed, 23 Feb 2011 17:54:27 +
From: XMPP Extensions Editor 
Reply-To: XMPP Standards 
To: standards@xmpp.org

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: In-Band Real Time Text

Abstract: This is a specification for real-time text transmitted in-band
over an XMPP session.

URL: http://www.xmpp.org/extensions/inbox/realtimetext.html

The XMPP Council will decide at its next meeting whether to accept this
proposal as an official XEP.


Re: [Standards] need clarification about adding own jid to roster

2011-02-24 Thread Sebastian Reitenbach
Hi,
On Wednesday, February 23, 2011 08:59:05 pm you wrote:
> On Wed, Feb 23, 2011 at 6:10 PM, Sebastian Reitenbach
> 
>  wrote:
> > Hi,
> > 
> > as xmpp client developer (coccinella), I want to add my own jid to my
> > roster. The last time I worked on that, was about a year ago. There I
> > took RFC3921bis-08 as reference. There in chapter 2.3.3 at the end it
> > stated:
> > 
> >   The server MUST return a  stanza error to the client if
> >   the value of the  element's 'jid' attribute matches the bare
> >   JID  portion of the  element's 'from' attribute
> >   (i.e., a JID MUST NOT be allowed to add itself to its own roster).
> > 
> > Therefore I was looking into adding some exceptions to handle the own JID
> > in the roster, or better explained as adding a fake jid to the roster
> > view in the client. I got a bit distracted with other stuff, and just
> > recently started again working on that.
> > 
> > now I just looked again to the in the latest revision,  20, of the RFC,
> > and I read this now:
> >  Interoperability Note: Some servers return a  stanza
> >  error to the client if the value of the  element's 'jid'
> >  attribute matches the bare JID  of the
> >  user's account.
> > 
> > So I should understand this statement now as:
> > Servers should generally allow the client user to add the own JID to the
> > roster, this is no error anymore. Only older server implementations may
> > not allow adding the own jid.
> > 
> > If my understanding is right, then this would make my life much more
> > easier since I don't need to implement exceptions for the own jid.
> > 
> > cheers,
> > Sebastian
> 
> Your client shouldn't disallow it. However, this is a relatively
> recent change, and your client should handle a  error
> properly.

thank you for your reply. Coccinella client actually allows adding the own jid 
to the roster since ever. I just stumped over it a year ago, since I once 
tried to do this when connected to an openfire server, which returned the not-
allowed error. Then I started wondering, why it worked with the ejabberd I 
usually use, and found the mentioned snipped above in version 08 of the RFC, 
which explicitly states it should not be allowed. I even opened a bug report 
against ejabberd at that time: https://support.process-
one.net/browse/EJAB-1166
Probably I should add a comment that this has changed over the time.

For me, life is much easier, when it is allowed by the server to add the own 
jid to the roster. That would follow the xmpp philosophy putting the 
complexity to the server, and would prevent me from implementing a lot of 
special handling of the own jid, like other clients do.
I'd even prefer an explicit statement in the RFC that it is allowed to add the 
own jid to the roster,  in contrast with what is in there right now.

cheers,
Sebastian

> 
> --
> Waqas Hussain