Re: [Standards] XEP-0301 Session handling

[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

[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

[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

[Standards] Advice on XEP-0301 Mass-Market Use Cases (if XEP-0301 added to Adium/Miranda within 12 months)

[Mark Rejhon]

To the Stadards group,

I bring up a question separate from the Session Handling.
(many questions have already been answered -- thank you very much)

*Scenario: *XEP-0301 real-time text gets added to a mainstream client such
as Pidgin or Miranda within 12 months.

*Question: *What is the simplest possible and easiest method of safely
introduce real-time text politely to a mainstream client, in a
non-intrusive manner? (i.e. privacy)
Especially if one end has RTT enabled by default (i.e. intentionally
enabled by user), and the other end has RTT disabled by default (i.e.
default installation)

*Details of Scenarios:*
- People don't normally expect their typing to be transmitted in real time.
 Therefore, feature shold be off by default in such mainstream clients.
- However, it should be easy as possible to enable.  Therefore, such
mainstream clients will always advertise XEP-0301 compatibility via disco
(section 5) but not necessarly enable the transmission of outgoing
XEP-0301, including for privacy reasons.
- Some people, such as deaf users, will want to change the software
preference to permanently allow XEP-0301.
(i.e. in software preferences)
- However, even when disabled by default, we want users to make it easy for
XEP-0301-aware recipients to enable the feature for responding to other
XEP-0301 clients.
(i.e. per-chat-session activation feature, such as a button)

*Potential popularity in 10 years*
Just like all television sets have a closed caption decoder, and is usually
turned off by default, but easily turned on -- eventually, we hope XEP-0301
becomes mainstream within 10 years, as a replacement for obsolete deaf
TDD/TTY teletypewriters.   In even my limited testing (non-deaf family,
friends, coworkers, etc), I found that once they understood what RTT was,
it was a more popular feature than audio and video.   So RTT has a lot of
potential to improve the IM experience, even if it's an option feature
enabled only a few percent of the time.   Although more scientific surveys
need to be done once it's already a part of Adium/Miranda/etc, it shows
that sometimes people like to switch to the conversational mode via RTT
rather than via audio, since they can talk very conversationally without
making noise.   Other times, people are in an asynchronous mood, like text
messaging, regular instant messages, or email.   But it apparently shows
that there's more frequently a mood to be conversational via RTT than via
audio or video, from this limited testing.   Thus, we need to be prepared
for the potential possibility that it may show up in mainstream clients.
NOTE: We've also got a new logo for real-time text at
www.fasttext.orgwhich we'll be starting to use in the next 12 months
for future programming.

Advertising XEP-0301 capability is done by a caps detection.  Presumably,
this will always be the case in all clients that supports XEP-0301.

We see three situations where chat is activated between two XEP-0301 aware
clients:
1. Both clients advertise XEP-0301 capability, but does not send XEP-0301
by default.
2. Both clients advertise XEP-0301 capability, but only recipient sends
XEP-0301 by default.
3. Both clients advertise XEP-0301 capability, but only sender sends
XEP-0301 by default.
We want to make it easy for both ends to start sending RTT in scenario 2
and 3, even if disabled by default.

*Example "Accessible" future use case **(which will happen!):*
-- Alice is a deaf user, using a year 2014 build of Adium.  She has
XEP-0301 enabled.
-- Bob is a hearing user, not aware of real-time text, but is using a year
2014 build of Pidgin that has XEP-0301 support but does not transmit RTT by
default.
-- Alice sends a message to Bob.  She immediately sends RTT.  Her typing is
transmitted in real time.
-- Bob's client software detects this but does not automatically send Bob's
typing in real time.
*The big question: What should happen afterwards?*

*Possible Ideas/Methods of negotiating RTT activation*
- XEP-0020?  Bob instant messaging client, should be able to activate a
session negotiation feature.  As you remember, we added an XEP-0020 session
negotiation feature in Version 0.0.1 of XMPP-RTT, but it got removed from
Version 0.0.2 of XMPP-RTT.   It is overkill/complesx.
- Jingle?  I think it's still overkill, since we want to operate 100%
in-band
- XEP-0030?  We should always advertise XEP-0301 even if the client doesn't
send outgoing RTT by default.  This allows clients that DO WANT to send
RTT, to go ahead and send RTT anyway
- XEP-0085?  Nope, it is not suitable.
- The existing XEP-0301 featuer of *event='start' *and *event='cancel'?  *Yes,
this is a possibility, but if I can simplify things by removing these...
(as long as I have an alternative to cover the above use case.)

*The simplest method I have though of, to cover such use case:*
1. Alice's software verifies Bob's softtware does support RTT via caps
detection. (Section 5 of XEP-0301)
2. Alcie Send RTT.
3. Bob's client, upon detecting incoming  auto

Re: [Standards] XEP-0301 Session handling

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

Re: [Standards] long specs

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/27/12 4:02 PM, Peter Saint-Andre wrote:
> On 2/15/12 1:07 PM, Peter Saint-Andre wrote:
>> On 2/15/12 12:48 PM, Kurt Zeilenga wrote:
> 
>>> On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote:
> 
 I'd be willing to work on this, but I want to make sure that
  people think there's value in doing so.
> 
>>> Personally, I not sure what I hate more, overly long documents 
>>> or specifications unnecessarily split over multiple documents.
> 
>>> I don't consider XEP 45 or XEP 60 to be overly long.
> 
>> Half the feedback I receive is (a) it's too hard to read a long 
>> spec. The other half is (b) it's too hard to read multiple
>> specs. For XEP-0060, the feedback is heavily weighted toward (a).
>> For XEP-0045, it's about evenly weighted. My conclusion is that
>> we really need to split up XEP-0060, and that splitting XEP-0045
>> into user vs. admin use cases would be helpful.
> 
> Over the weekend I took a rough cut at splitting up XEP-0045.
> Here's what I came up with (page lengths are based on print-to-PDF
> in Firefox):
> 
> XEP-0045 = 141 pages
> 
> Architecture, Requirements, Discovery, Security = 35 pages
> 
> Occupant Use Cases = 56 pages
> 
> Administration = 68 pages

Because more than one person has asked about the split files, I've
placed them here:

http://www.saint-andre.com/jabber/tmp/muc-arch.html

http://www.saint-andre.com/jabber/tmp/muc-occupant.html

http://www.saint-andre.com/jabber/tmp/muc-admin.html

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/

iEYEARECAAYFAk9NN+oACgkQNL8k5A2w/vwYKACgkVYFy00xLTlppsW/KJl0yk8u
lc0AoNe44vM9zidMpipzOho74jncGE4N
=Ia5C
-END PGP SIGNATURE-

[Standards] Proposed XMPP Extension: PubSub Since

[XMPP Extensions Editor]

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

Title: PubSub Since

Abstract: This specification defines a publish-subscribe feature that enables a 
subscriber to automatically receive pubsub and PEP notifications since its last 
logout time.

URL: http://xmpp.org/extensions/inbox/pubsub-since.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

Re: [Standards] Pubsub to atom mapping :)

[Peter Saint-Andre]

On 2/28/12 1:56 AM, Sergey Dobrov wrote:
> On 02/28/2012 06:36 AM, Peter Saint-Andre wrote:
>> On 2/27/12 12:36 AM, Sergey Dobrov wrote:
>>> The other thing here is linking: atom:link needs attributes "ref" and
>>> "href", but href usually points to the atom feed at all and ref points
>>> to the specific entry in the feed by it's atom:id. Then, should we point
>>> to the node there and not to the specific item in the node? Then we can
>>> exclude atom:id from entries as superfluous. Have we to change Atom's
>>> xmlns then?
>>
>> I don't see any harm from duplicating the atom:id in the payload.
>>
> 
> The only one: what if some software will write different values to
> there? Which one will be trusted then?

Yeah, I thought about that. It might depend on who is relying on which
attribute. E.g., the base XMPP implementation might rely on the pubsub
ItemID for tracking purposes related to the message transport, whereas
the Atom payload might be handed off to a higher-level application that
relies on the atom:id for things like de-duplication.

Peter

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

Re: [Standards] Pubsub to atom mapping :)

[Sergey Dobrov]

On 02/28/2012 06:36 AM, Peter Saint-Andre wrote:
> On 2/27/12 12:36 AM, Sergey Dobrov wrote:
>> The other thing here is linking: atom:link needs attributes "ref" and
>> "href", but href usually points to the atom feed at all and ref points
>> to the specific entry in the feed by it's atom:id. Then, should we point
>> to the node there and not to the specific item in the node? Then we can
>> exclude atom:id from entries as superfluous. Have we to change Atom's
>> xmlns then?
> 
> I don't see any harm from duplicating the atom:id in the payload.
> 

The only one: what if some software will write different values to
there? Which one will be trusted then?

> 
> 


-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.