Re: [Standards] XEP-0301 Session handling

2012-03-07 Thread Peter Saint-Andre 
On 2/29/12 1:11 PM, Gunnar Hellström wrote:
> Peter Saint-Andre skrev 2012-02-29 19:40:
>> I really think that if you want to gateway between SIP and XMPP, you
>> want to use Jingle. Such gatewaying was one of the core considerations
>> for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we
>> can certainly write a spec that defines how to translate between
>> XEP-0301 and RFC 4103 (e.g., how to translate the SDP).
> Yes, that is likely a good thing to do, but not for the simple example I
> provided.
> 
>> Personally I
>> don't think we absolutely need a way to complete a formal negotiation
>> over XMPP itself, because I tend to think that just sending a chat
>> message is a much more natural interaction,
> Yes, but the example was a session on the SIP side, and a series of chat
> messages on the XMPP side. And the tricky thing with the example was
> that it was not a human operating the SIP side. A human will decide -
> "ah, now the call is over, so I hang up". Then the gateway can detect
> that and release resources. But if it is a server as in the example,
> with no real logical end of the session, then we must rely on some
> session signaling from the XMPP user to tear down the session.
> Can the directed presence "unavailable" signaling described in RFC 6121
> section 5.1 be relied upon for the purpose of ending the session?

Gatewaying is tricky. :)

It seems that you want things to seem natural from the XMPP side (no
Jingle or session negotiation required), but then have something more
formal on the SIP side (INVITEs and all that). This means the gateway
needs to be smarter than something which just translates between Jingle
and SIP. Your gateway could use a  chat state on the XMPP side to
trigger the end of the RTT session on the SIP side. I have concerns
about using unavailable presence -- that works OK for what's described
in RFC 6121, which is an ad-hoc session between two people who don't
normally share presence, but it breaks down if two people do share
presence (not sure how often that would occur through the gateway).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0301 Session handling

2012-02-29 Thread Gunnar Hellström 

Peter Saint-Andre skrev 2012-02-29 19:40:

I really think that if you want to gateway between SIP and XMPP, you
want to use Jingle. Such gatewaying was one of the core considerations
for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we
can certainly write a spec that defines how to translate between
XEP-0301 and RFC 4103 (e.g., how to translate the SDP).
Yes, that is likely a good thing to do, but not for the simple example I 
provided.



Personally I
don't think we absolutely need a way to complete a formal negotiation
over XMPP itself, because I tend to think that just sending a chat
message is a much more natural interaction,
Yes, but the example was a session on the SIP side, and a series of chat 
messages on the XMPP side. And the tricky thing with the example was 
that it was not a human operating the SIP side. A human will decide - 
"ah, now the call is over, so I hang up". Then the gateway can detect 
that and release resources. But if it is a server as in the example, 
with no real logical end of the session, then we must rely on some 
session signaling from the XMPP user to tear down the session.
Can the directed presence "unavailable" signaling described in RFC 6121 
section 5.1 be relied upon for the purpose of ending the session?



/Gunnar

Re: [Standards] XEP-0301 Session handling

2012-02-29 Thread Peter Saint-Andre 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/28/12 11:28 PM, Gunnar Hellström wrote:
> Returning to the initial question of this thread: Is there a common
> way to indicate session start and session end.
> 
> Peter Saint-Andre skrev 2012-02-29 04:20:
>> Yes, but that doesn't necessarily mean you need an explicit
>> negotiation protocol.
> Right. The first need I thought about can in fact be reduced to a
> text session indicator, not even linked to RTT support.
> 
> I will take a scenario to make the need clear.
> 
> Assume that there is a SIP based stock exchange service, sending
> stock exchange information in text in sessions. It continues as
> long as a terminal is connected. A terminal indicates by a BYE that
> it leaves the session, so that the server can release the
> resources. During the session, the text information may be provided
> through RFC 4103 or RFC 3428 or RFC 4975. (RFC 4103 makes most
> sense of course for the RTT example, but let us look at it in
> general).
> 
> Also assume that you want to make this service available to XMPP
> users through a gateway. Setting up a chat session to the gateway
> causes it to set up a SIP session with the stock exchange server. 
> Messages or real-time text is flowing from the stock exchange
> server to the XMPP client. Then, the XMPP user want to leave the
> session. What does the user do and what does the gateway use as an
> indication that the session is over and it can take down the
> session towards the server?

I really think that if you want to gateway between SIP and XMPP, you
want to use Jingle. Such gatewaying was one of the core considerations
for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we
can certainly write a spec that defines how to translate between
XEP-0301 and RFC 4103 (e.g., how to translate the SDP). Personally I
don't think we absolutely need a way to complete a formal negotiation
over XMPP itself, because I tend to think that just sending a chat
message is a much more natural interaction, but *if* we think we need
such a negotiation method, we should just use Jingle.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9OcRQACgkQNL8k5A2w/vzgqwCgiBcvV337uC0aDPVQ0zJ2zY+x
dGsAoKhCEcelqsbgJFE5fF1trjKBFkPU
=NhyO
-END PGP SIGNATURE-

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Gunnar Hellström 
Returning to the initial question of this thread: Is there a common way 
to indicate session start and session end.


Peter Saint-Andre skrev 2012-02-29 04:20:

Yes, but that doesn't necessarily mean you need an explicit negotiation
protocol.
Right. The first need I thought about can in fact be reduced to a text 
session indicator, not even linked to RTT support.


I will take a scenario to make the need clear.

Assume that there is a SIP based stock exchange service, sending stock 
exchange information in text in sessions. It continues as long as a 
terminal is connected. A terminal indicates by a BYE that it leaves the 
session, so that the server can release the resources. During the 
session, the text information may be provided through RFC 4103 or RFC 
3428 or RFC 4975. (RFC 4103 makes most sense of course for the RTT 
example, but let us look at it in general).


Also assume that you want to make this service available to XMPP users 
through a gateway.
Setting up a chat session to the gateway causes it to set up a SIP 
session with the stock exchange server.
Messages or real-time text is flowing from the stock exchange server to 
the XMPP client.
Then, the XMPP user want to leave the session. What does the user do and 
what does the gateway use as an indication that the session is over and 
it can take down the session towards the server?


The indication for setting up seems to be either the basic mechanism for 
session control defined in RFC 6121 section 5.1 where it is stated that

initiation of a session should begin with a message with type=chat.
Or XEP-0085 chat state going "active"

But what is most appropriate as indication to the gateway that it is 
time to take down the session on the SIP side?


The XEP-0085 chat states do not seem to be the primary means to use. The 
user may sit there very actively watching the information coming, but 
not touching the user interface for half an hour. According to XEP-0085, 
the chat state would then be "gone" since long, so taking down the 
session on "gone" indication does not seem appropriate.


How about relying on RFC 6121 section 5.1 requiring that
end of session should be signaled by indicating directed presence 
"unavailable".
Will that be normally signalled by most XMPP text clients when the user 
closes the window where the session was shown?


The stock exchange server example is of course artificial. There may be 
many other cases when a simple session indication is important.
And this regardless of the support for and activation of the RTT 
feature. So my conclusion now is that this is not at all a XEP-0301 
issue, but if we get a conclusion, we could document it as a 
recommendation in XEP-0301.


There are other valid cases, when full capability declaration, exchange 
and negotiation or RTT capability is important, but let us take one case 
at a time.


Thanks

Gunnar

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre 
On 2/28/12 8:15 PM, Mark Rejhon wrote:
> 
> Hello,
>  
> 
> That's a client configuration and UI issue, not a protocol issue.
> 
> 
> Actually, we've found it is a very important long-term interoperability
> issue -- please see my big email, we have plans to add RTT to multiple
> open source clients.   We've explained several scenarios
> 
> (i.e. a Year 2014 build of Pidgin talking to a Year 2014 build of Adium
> )
> 
> Even if the interoperability is accomplished by a software practice, the
> software practice still needs to be 'standardized' between different
> brands, and therefore must be mentioned in XEP-0301, and therefore
> relevant discussion

Yes, but that doesn't necessarily mean you need an explicit negotiation
protocol.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon 
Hello,


> That's a client configuration and UI issue, not a protocol issue.
>

Actually, we've found it is a very important long-term interoperability
issue -- please see my big email, we have plans to add RTT to multiple open
source clients.   We've explained several scenarios

(i.e. a Year 2014 build of Pidgin talking to a Year 2014 build of Adium
)

Even if the interoperability is accomplished by a software practice, the
software practice still needs to be 'standardized' between different
brands, and therefore must be mentioned in XEP-0301, and therefore relevant
discussion

Mark Rejhon

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre 
Hi Florian!

On 2/28/12 7:42 PM, Florian Zeitz wrote:
> Am 29.02.2012 03:02, schrieb Peter Saint-Andre:
>> On 2/28/12 6:13 PM, Mark Rejhon wrote:
>>> *[To Discuss] Matter of negotiation of activation of RTT feature*
>>> /However/, XEP-0085 doesn't answer the question of an appropriate
>>> negotiation model for deciding whether or not to enable RTT for a chat
>>> session.  (RTT is most ideal when both ends enable it)  Peter, do you
>>> think that my use case examples seem appropriate behaviour?
>>>
>>> Comments would be appreciated about this.
>>
>> I'm suggesting that you use a model similar to XEP-0085 -- if the other
>> side advertises it (disco/caps), send the first message with some kind
>> of RTT element. If the response comes back without an RTT element, don't
>> include any RTT elements in subsequent messages within that conversation.
>>
>> Peter
>>
> 
> I tend to disagree with this. It would inherently require that both
> sides do RTT. 

That was the assumption behind chat state notifications. I think it's a
reasonable assumption, but I also think that reasonable people can
disagree about it.

> I don't see any reason to enforce this artificial
> requirement. It is perfectly fine for just one side to send RTT
> messages, while the other one uses normal chat messages.
> If someone doesn't want to receive RTT messages, he should just not
> include the feature in the disco response.

Sure.

> Also I see absolutely no reason for any session negotiation for this XEP
> whatsoever, especially without an option for the receiving party to
> decline the session. A simple on/off switch on the sending end (only
> availabe when the disco feature is present) seems sufficient to me.

I too agree that we don't need session negotiation.

> As a side note. What you described is actually quite different from what
> XEP-0085 says. You're mixing the usual disco case with the backwards
> compatibility case where no feature is present, but chat states might
> still be supported.

Quite possibly. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre 
On 2/28/12 7:33 PM, Mark Rejhon wrote:
> On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre  > wrote:
> 
> I'm suggesting that you use a model similar to XEP-0085 -- if the other
> side advertises it (disco/caps), send the first message with some kind
> of RTT element. If the response comes back without an RTT element, don't
> include any RTT elements in subsequent messages within that
> conversation.
> 
> 
> Hello!
> This works in niche clients.
> 
> However, when bringing real-time text to the mass market, it is presumed
> that vendors (i.e. Microsoft, Google) will want it to be disabled by
> default. 

That's a client configuration and UI issue, not a protocol issue.

1. If the interlocutor doesn't advertise support for RTT, consider RTT
unavailable for this conversation and don't proceed to #2.

2. If the interlocutor advertises support for RTT, prompt your user
about whether to try RTT (or have some setting about "try RTT with known
contacts" or somesuch).

3. If you try RTT but the interlocutor doesn't include RTT extensions,
don't include RTT in subsequent messages.

I still don't see the need for protocol-level *negotiation* here.
However, if you are convinced that we need it, then we already have a
protocol for that: Jingle.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Florian Zeitz 
Am 29.02.2012 03:02, schrieb Peter Saint-Andre:
> On 2/28/12 6:13 PM, Mark Rejhon wrote:
>> *[To Discuss] Matter of negotiation of activation of RTT feature*
>> /However/, XEP-0085 doesn't answer the question of an appropriate
>> negotiation model for deciding whether or not to enable RTT for a chat
>> session.  (RTT is most ideal when both ends enable it)  Peter, do you
>> think that my use case examples seem appropriate behaviour?
>>
>> Comments would be appreciated about this.
> 
> I'm suggesting that you use a model similar to XEP-0085 -- if the other
> side advertises it (disco/caps), send the first message with some kind
> of RTT element. If the response comes back without an RTT element, don't
> include any RTT elements in subsequent messages within that conversation.
> 
> Peter
> 

I tend to disagree with this. It would inherently require that both
sides do RTT. I don't see any reason to enforce this artificial
requirement. It is perfectly fine for just one side to send RTT
messages, while the other one uses normal chat messages.
If someone doesn't want to receive RTT messages, he should just not
include the feature in the disco response.
Also I see absolutely no reason for any session negotiation for this XEP
whatsoever, especially without an option for the receiving party to
decline the session. A simple on/off switch on the sending end (only
availabe when the disco feature is present) seems sufficient to me.

As a side note. What you described is actually quite different from what
XEP-0085 says. You're mixing the usual disco case with the backwards
compatibility case where no feature is present, but chat states might
still be supported.

Regards,
Florian

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon 
On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre wrote:

> I'm suggesting that you use a model similar to XEP-0085 -- if the other
> side advertises it (disco/caps), send the first message with some kind
> of RTT element. If the response comes back without an RTT element, don't
> include any RTT elements in subsequent messages within that conversation.
>

Hello!
This works in niche clients.

However, when bringing real-time text to the mass market, it is presumed
that vendors (i.e. Microsoft, Google) will want it to be disabled by
default.  People don't expect their typing to be transmitted live right
away.   Imagine the fuss if audio and video was enabled by default, too --
that would be a /privacy invasion/ for many users not expecting audio/video
to begin transmitting immediately.

We've got the goal of having it in mainstream instant messaging programs.
 (We're planning to add an optional XEP-0301 mode to open source clients
such as Pidgin, Adium, Miranda -- over the next 12-24 months and beyond).
As a result, eventually mainstream vendors may adopt it, i.e. Google,
Microsoft, etc, as a replacement for obsolete deaf TDD/TTY teletypewriters.

So, there's a pressure to make sure the XEP-0301 standard has everything it
requires to make a standardization of RTT negotiation possible, even if
it's as simplistic as the examples I made, or if something more elaborate
is needed.

[Interesting note: In limited testing with non-deaf audiences when it was
'available to them', RTT proved more popular than using an audio and video
feature!   Most people don't turn on Audio and Video all the time, anyway.
  Audio and video is often enabled less than 5% of the time during the
instant messaging application's lifetime, anyway.  RTT actually proved more
popular once the Average Joe Users understood what real time text is.  So
we'll be standardizing on the new logo at www.fasttext.org when a group of
us, myself included, adds it to Adium, Miranda, Pidgin, etc]

Opinions from all would be appreciated, on the best approach to introduce
RTT 'politely' to the mainstream, since it'll be introduced to major open
source instant messengers.  That's why I have to be cautious about removing
*event='start'* if it ends up suddenly becoming necessary.

Apparently XEP-0085 doesn't cover the specific (potentially popular)
situation of an RTT-aware mass market client that has RTT disabled by
default -- that's the use case that clarification is now needed on before
we begin adding it to Adium, Miranda, Pidgin, etc...

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre 
On 2/28/12 6:13 PM, Mark Rejhon wrote:
> 
> 
> On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre  > wrote:
> 
> On 2/28/12 4:47 PM, Mark Rejhon wrote: 
> 
> [snip]
> 
> > *Use Case Example #1:*
> > Alice messages Bob.  Alice enables real-time text by clicking a
> button.
> > On Bob machine, when his software receives an  element for the
> > first time, the software can prompt Bob to enable the real-time text
> > feature, as follows:
> > / Alice is now sending real-time text.  Click [Accept] to transmit
> > your typing live too./
> >
> > *Use Case Example #2:*
> > Alice messages Bob.   Alice enables real-time text by clicking a
> button.
> > Bob's IM client is preconfigured to automatically accept real-time
> text.
> > Upon receiving Alice's real-time text in , Bob automatically
> > enables sending of .  A notification message simply gets
> displayed
> > in the message history:
> > *** /Alice has activated real-time text. / /Your typing is now being
> > transmitted live./
> >
> > If this method is done, then it is not necessary to worry about using
> > the event='start' / event='cancel' for the purposes of RTT-specific
> > session signalling, and I can just remove it from XEP-0301 to
> simplify.
> >  Also, it is noted that XEP-0301 section 5 already provides a
> mechanism
> > for a client to detect whether the remote client has RTT support,
> before
> > transmitting outgoing unsolicited . 
> 
> [snip]
> 
>  Mark, the model you're searching for is what we use in XEP-0085. Please
> take a look at the text there and see if you can re-use it for RTT.
> 
> 
> Hello,
> Yes, but it does not answer the question of how to negotiate the
> enabling of RTT.   There are three angles that are covered, two of them
> answered, and one of them not.
> 
> *[Answered] **Matter of Compatibility between XEP-0301 and XEP-0085:*
> XEP-0085, if used, is very easily complementary with RTT.  You just
> simply send  with the first  element transmitted from
> any other state (i.e.  or )  I should add a
> sentence about this general practice.
> 
> *[Answered] Matter of Simplifying XEP-0305 by removing its session
> signalling*
> XEP-0085 can easily justify the removal of the *event='start'* and
> *event='cancel'*
> *
> *
> *[To Discuss] Matter of negotiation of activation of RTT feature*
> /However/, XEP-0085 doesn't answer the question of an appropriate
> negotiation model for deciding whether or not to enable RTT for a chat
> session.  (RTT is most ideal when both ends enable it)  Peter, do you
> think that my use case examples seem appropriate behaviour?
> 
> Comments would be appreciated about this.

I'm suggesting that you use a model similar to XEP-0085 -- if the other
side advertises it (disco/caps), send the first message with some kind
of RTT element. If the response comes back without an RTT element, don't
include any RTT elements in subsequent messages within that conversation.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon 
>
> *[Answered] Matter of Simplifying XEP-0305 by removing its session
> signalling*
>


When I wrote that, I meant XEP-0301, of course.

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon 
On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre wrote:

> On 2/28/12 4:47 PM, Mark Rejhon wrote:

[snip]

> *Use Case Example #1:*
> > Alice messages Bob.  Alice enables real-time text by clicking a button.
> > On Bob machine, when his software receives an  element for the
> > first time, the software can prompt Bob to enable the real-time text
> > feature, as follows:
> > / Alice is now sending real-time text.  Click [Accept] to transmit
> > your typing live too./
> >
> > *Use Case Example #2:*
> > Alice messages Bob.   Alice enables real-time text by clicking a button.
> > Bob's IM client is preconfigured to automatically accept real-time text.
> > Upon receiving Alice's real-time text in , Bob automatically
> > enables sending of .  A notification message simply gets displayed
> > in the message history:
> > *** /Alice has activated real-time text. / /Your typing is now being
> > transmitted live./
> >
> > If this method is done, then it is not necessary to worry about using
> > the event='start' / event='cancel' for the purposes of RTT-specific
> > session signalling, and I can just remove it from XEP-0301 to simplify.
> >  Also, it is noted that XEP-0301 section 5 already provides a mechanism
> > for a client to detect whether the remote client has RTT support, before
> > transmitting outgoing unsolicited .

[snip]
>
>  Mark, the model you're searching for is what we use in XEP-0085. Please
> take a look at the text there and see if you can re-use it for RTT.


Hello,
Yes, but it does not answer the question of how to negotiate the enabling
of RTT.   There are three angles that are covered, two of them answered,
and one of them not.

*[Answered] **Matter of Compatibility between XEP-0301 and XEP-0085:*
XEP-0085, if used, is very easily complementary with RTT.  You just simply
send  with the first  element transmitted from any other
state (i.e.  or )  I should add a sentence about this
general practice.

*[Answered] Matter of Simplifying XEP-0305 by removing its session
signalling*
XEP-0085 can easily justify the removal of the *event='start'* and *
event='cancel'*
*
*
*[To Discuss] Matter of negotiation of activation of RTT feature*
/However/, XEP-0085 doesn't answer the question of an appropriate
negotiation model for deciding whether or not to enable RTT for a chat
session.  (RTT is most ideal when both ends enable it)  Peter, do you think
that my use case examples seem appropriate behaviour?

Comments would be appreciated about this.

Thanks,
Mark Rejhon

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre 
On 2/28/12 4:47 PM, Mark Rejhon wrote:

> I'm interested in feedback about session negotiation techniques, and
> about simplifying XEP-0301 by removing the start/cancel attributes
> (which are OPTIONAL) which are actually not currently used in any of the
> several XEP-0301 implementations I have seen, including the latest
> version of RealJabber (software installer package now available at
> www.realjabber.org  ...)
> 
> I also need to define a mechanism where both sides of a XEP-0301
> compliant client can negotiate the simultaneous enabling of real-time
> text on both sides, on an example mainstream client that might have RTT
> disabled by default.   For example, it should be possible for software
> vendors to add an activation button for real-time text -- like there's
> already a button for audio or video in many popular IM clients.  One
> technical method behind the scenes is to use the
> event=start/event=cancel , but a different method is to also
> automatically prompt to send return RTT if it detects incoming RTT.   
> 
> *Use Case Example #1:*
> Alice messages Bob.  Alice enables real-time text by clicking a button.  
> On Bob machine, when his software receives an  element for the
> first time, the software can prompt Bob to enable the real-time text
> feature, as follows:
> / Alice is now sending real-time text.  Click [Accept] to transmit
> your typing live too./
> 
> *Use Case Example #2:*
> Alice messages Bob.   Alice enables real-time text by clicking a button.  
> Bob's IM client is preconfigured to automatically accept real-time text.
> Upon receiving Alice's real-time text in , Bob automatically
> enables sending of .  A notification message simply gets displayed
> in the message history:
> *** /Alice has activated real-time text. / /Your typing is now being
> transmitted live./
> 
> If this method is done, then it is not necessary to worry about using
> the event='start' / event='cancel' for the purposes of RTT-specific
> session signalling, and I can just remove it from XEP-0301 to simplify.
>  Also, it is noted that XEP-0301 section 5 already provides a mechanism
> for a client to detect whether the remote client has RTT support, before
> transmitting outgoing unsolicited .

Mark, the model you're searching for is what we use in XEP-0085. Please
take a look at the text there and see if you can re-use it for RTT.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon 
2012/2/28 Gunnar Hellström 

> Sometimes it is very helpful with a clear beginning and a clear end of an
> XMPP text session.
> For example if you are gatewaying to a SIP call, and want to cause a
> hangup on the SIP side, or get an indication to the XMPP side when the SIP
> side has closed the session.
> *Question*:
> I wonder if there is a session start - session end indication that has
> dominating support among XMPP text messaging implementations that can be
> used as the default mechanism for XEP-0301 real-time text session control.
>

Gunnar brings up an excellent question, of which I am considering as well.
This refers to Section 4.2.3 --
http://xmpp.org/extensions/xep-0301.html#event
Right now, session negotiation is also a question that I have about
XEP-0301.

I'm interested in feedback about session negotiation techniques, and about
simplifying XEP-0301 by removing the start/cancel attributes (which are
OPTIONAL) which are actually not currently used in any of the several
XEP-0301 implementations I have seen, including the latest version of
RealJabber (software installer package now available at www.realjabber.org...)

I also need to define a mechanism where both sides of a XEP-0301 compliant
client can negotiate the simultaneous enabling of real-time text on both
sides, on an example mainstream client that might have RTT disabled by
default.   For example, it should be possible for software vendors to add
an activation button for real-time text -- like there's already a button
for audio or video in many popular IM clients.  One technical method behind
the scenes is to use the event=start/event=cancel , but a different method
is to also automatically prompt to send return RTT if it detects incoming
RTT.

*Use Case Example #1:*
Alice messages Bob.  Alice enables real-time text by clicking a button.
On Bob machine, when his software receives an  element for the first
time, the software can prompt Bob to enable the real-time text feature, as
follows:
* Alice is now sending real-time text.  Click [Accept] to transmit your
typing live too.*

*Use Case Example #2:*
Alice messages Bob.   Alice enables real-time text by clicking a button.
Bob's IM client is preconfigured to automatically accept real-time text.
Upon receiving Alice's real-time text in , Bob automatically enables
sending of .  A notification message simply gets displayed in the
message history:
*** *Alice has activated real-time text. * *Your typing is now being
transmitted live.*

If this method is done, then it is not necessary to worry about using the
event='start' / event='cancel' for the purposes of RTT-specific session
signalling, and I can just remove it from XEP-0301 to simplify.  Also, it
is noted that XEP-0301 section 5 already provides a mechanism for a client
to detect whether the remote client has RTT support, before transmitting
outgoing unsolicited .

I could go elaborate and use feature negotiation (XEP-0020) or disco
(XEP-0030) to negotiate an RTT session in a more synchronous manner, but I
think that's overkill at this stage, and I think that the two above use
cases are sufficient?

If everyone agrees, then I will be removing *event='start'* and *
event='cancel'* from section 4.2.3 of my XMPP specification,
http://xmpp.org/extensions/xep-0301.html#event in order to simplify the
specification.

Thoughts?

Thanks,
Mark Rejhon



Right now in XEP-0301, there is an "start" event and a "cancel" event
> defined in section 4.2.3 with indications that they MAY be used to indicate
> session start and end.
> See http://xmpp.org/extensions/xep-0301.html
>
> I have found some other mechanisms, and I wonder if the "start" and
> "cancel" events should be deleted from XEP-0301, and instead some already
> existing mechanism used, in order to not increase the number of optional
> ways to handle session start and end.
>
> It seems to me that there is a basic mechanism for session control defined
> in RFC 6121 section 5.1
> Initiation of a session should begin with a message with type=chat,
> Both parties shall set their presence  to "chat"
> End of session should be signaled by indicating directed presence
> "unavailable".
> A change of  to anything else than chat should also be taken as
> indication of end of session.
> An example is presented in section 7 of RFC 6121.
>
> I assume that there are a multitude of exceptions when this sequence does
> not occur, but it seems to me to be a good basic sequence to support.
>
> On top of that, there seems to be a range of more comprehensive session
> control options:
> -XEP-0166 Jingle session establishment.
> -XEP-0155 Session establishment
> -XEP-0045 Multi-User Chat  ( that also uses directed "unavailable"
> presence for closing the session as the main method above.)
>
> *
> Proposal:*
> So, for XEP-0301, I want to check if it would be wise to delete the
> "start" and "cancel" events from chapter  4.2.3 and instead insert a new
> subsection in chapter 6 saying:
>
> "6.4 Session control
> S

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre 
Hi Gunnar!

On 2/28/12 4:07 PM, Gunnar Hellström wrote:
> Sometimes it is very helpful with a clear beginning and a clear end of
> an XMPP text session.

Some people have thought so in the past:

http://xmpp.org/extensions/xep-0155.html

That was mainly developed for the purpose of end-to-end encryption
(XEP-0116). Personally I think it would be good to deprecate it.

> For example if you are gatewaying to a SIP call, and want to cause a
> hangup on the SIP side, or get an indication to the XMPP side when the
> SIP side has closed the session.

We have Jingle for multimedia session management. We could use it for
managing a text session, although personally I think that's overkill.

> *
> Question*:
> I wonder if there is a session start - session end indication that has
> dominating support among XMPP text messaging implementations that can be
> used as the default mechanism for XEP-0301 real-time text session control.

http://xmpp.org/extensions/xep-0085.html might be most appropriate.

> 
> Right now in XEP-0301, there is an "start" event and a "cancel" event
> defined in section 4.2.3 with indications that they MAY be used to
> indicate session start and end.
> See http://xmpp.org/extensions/xep-0301.html
> 
> I have found some other mechanisms, and I wonder if the "start" and
> "cancel" events should be deleted from XEP-0301, and instead some
> already existing mechanism used, in order to not increase the number of
> optional ways to handle session start and end.

Probably a good idea.

> It seems to me that there is a basic mechanism for session control
> defined in RFC 6121 section 5.1
> Initiation of a session should begin with a message with type=chat,
> Both parties shall set their presence  to "chat"
> End of session should be signaled by indicating directed presence
> "unavailable".
> A change of  to anything else than chat should also be taken as
> indication of end of session.
> An example is presented in section 7 of RFC 6121.

I think XEP-0085 (Chat State Notifications) is more relevant. I don't
think it would be good to overload  states because those are
related to presence in general, not a particular chat session.

> I assume that there are a multitude of exceptions when this sequence
> does not occur, but it seems to me to be a good basic sequence to support.
> 
> On top of that, there seems to be a range of more comprehensive session
> control options:
> -XEP-0166 Jingle session establishment.

If we want formal session management for RTT sessions then I think
Jingle is the way to go, but I am not convinced that we need formal
session management.

> -XEP-0155 Session establishment

I think we should deprecate that.

> -XEP-0045 Multi-User Chat  ( that also uses directed "unavailable"
> presence for closing the session as the main method above.)

MUC is multi-user, not one-to-one, so I think it's not general enough
for use in RTT.

> *
> Proposal:*
> So, for XEP-0301, I want to check if it would be wise to delete the
> "start" and "cancel" events from chapter  4.2.3 and instead insert a new
> subsection in chapter 6 saying:
> 
> "6.4 Session control
> Session control is essentially out of scope for this media related
> extension.
> A recommendation is though to follow the basic principles described in
> RFC 6121 section 5.1.
> Any further session handling such as Jingle, MUC or the Session
> establishment extension may be added as found suitable for each specific
> application of this extension."

My primary question is: do we need formal management of RTT sessions? I
don't think we do, and I think we can handle them informally using a
combination of RFC 6121 and XEP-0085. However, if we really really need
formal management then I would suggest using Jingle.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

[Standards] XEP-0301 Session handling

2012-02-28 Thread Gunnar Hellström 
Sometimes it is very helpful with a clear beginning and a clear end of 
an XMPP text session.


For example if you are gatewaying to a SIP call, and want to cause a 
hangup on the SIP side, or get an indication to the XMPP side when the 
SIP side has closed the session.

*
Question*:
I wonder if there is a session start - session end indication that has 
dominating support among XMPP text messaging implementations that can be 
used as the default mechanism for XEP-0301 real-time text session control.


Right now in XEP-0301, there is an "start" event and a "cancel" event 
defined in section 4.2.3 with indications that they MAY be used to 
indicate session start and end.

See http://xmpp.org/extensions/xep-0301.html

I have found some other mechanisms, and I wonder if the "start" and 
"cancel" events should be deleted from XEP-0301, and instead some 
already existing mechanism used, in order to not increase the number of 
optional ways to handle session start and end.


It seems to me that there is a basic mechanism for session control 
defined in RFC 6121 section 5.1

Initiation of a session should begin with a message with type=chat,
Both parties shall set their presence  to "chat"
End of session should be signaled by indicating directed presence 
"unavailable".
A change of  to anything else than chat should also be taken as 
indication of end of session.

An example is presented in section 7 of RFC 6121.

I assume that there are a multitude of exceptions when this sequence 
does not occur, but it seems to me to be a good basic sequence to support.


On top of that, there seems to be a range of more comprehensive session 
control options:

-XEP-0166 Jingle session establishment.
-XEP-0155 Session establishment
-XEP-0045 Multi-User Chat  ( that also uses directed "unavailable" 
presence for closing the session as the main method above.)


*
Proposal:*
So, for XEP-0301, I want to check if it would be wise to delete the 
"start" and "cancel" events from chapter  4.2.3 and instead insert a new 
subsection in chapter 6 saying:


"6.4 Session control
Session control is essentially out of scope for this media related 
extension.
A recommendation is though to follow the basic principles described in 
RFC 6121 section 5.1.
Any further session handling such as Jingle, MUC or the Session 
establishment extension may be added as found suitable for each specific 
application of this extension."



--
___
Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se
+46708204288