Subject: [dispatch] Revised proposed charter for Combining SIP and XMPP

From: <[email-masked]>
Date: Wed, 9 Dec 2009 14:11:02 +0100

Hello,
Below is the proposed charter text for Combining SIP and XMPP revised according to the discussions in Hiroshima. Basically the changes are

- include video in addition to voice
- mention that existing SIP and XMPP endpoints are not affected
- update milestones.

Comments are very welcome.

Regards,
Simo

-----8<------8<------8<------

Combining SIP VoIP and XMPP IM/Presence
=======================================

Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP).  In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN).  SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services.  

Both SIP and XMPP offer extensions for integrating voice and video with IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastructure. 

The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on 
- addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically.
- session correlation; endpoints need to be able to correlate SIP voice and video sessions with XMPP IM/Presence in such a manner that they can be presented to the end user in a seamless fashion
- presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain.

Existing SIP and XMPP endpoints are not affected and can interoperate with the implementations that comply with the extensions defined by this Working Group (but obviously without the additional functionality provided by these extensions).

The goal is to rely on existing service infrastructure, and new requirements should be imposed only on the endpoints. 

Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG.

Milestones
Jun 2010 Problem statement and use cases submitted to IESG as Informational.
Jun 2011 Specification on combining SIP based voice and video and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard.

-----8<------8<------8<------

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 09:41:34 +0100

Hey Simo, all,

I haven't seen anything in the charter being said about common
authentication of a client against the SIP and the XMPP service.
Consider for example a provider that is deploying a SIP+XMPP service. Is
it supposed to:

a) deliver to its users two different sets of  credentials and
connection information and expect everyone of them to configure two
different accounts in order to use their service

or

b) distribute proprietory clients that somehow "know" they should use
the same username and password with both services.

I am thinking that we should probably have this specified and my
concern is that unless we specifically state it in the charter the
following line might prevent us from doing so:

> The goal is to rely on existing service infrastructure, and new
> requirements should be imposed only on the endpoints.

If we agree to slightly loosen the above then we could also add an
objective along these lines:

- authentication; when authenticating against a SIP and an XMPP service
that were meant to be used jointly, end users should only need to
provide a single set of credentials.

How does this sound?

Emil

На 09.12.09 14:11, [email-masked] написа:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 10 Dec 2009 07:33:35 -0500

> provide a single set of credentials.

In theory, it may already be possible to do what you want, at least from
one side... RFC 2617 (used for both SIP and HTTP) already specifies a
'domain' parameter in the WWW-Authenticate header used to challenge a
SIP UA:

   domain
     A quoted, space-separated list of URIs, as specified in RFC XURI
     [7], that define the protection space.  If a URI is an abs_path, it
     is relative to the canonical root URL (see section 1.2 above) of
     the server being accessed. An absoluteURI in this list may refer to
     a different server than the one being accessed. The client can use
     this list to determine the set of URIs for which the same
     authentication information may be sent: any URI that has a URI in
     this list as a prefix (after both have been made absolute) may be
     assumed to be in the same protection space. If this directive is
     omitted or its value is empty, the client should assume that the
     protection space consists of all URIs on the responding server.

If the SIP server were to include an xmpp: URI in that list, then the
challenged SIP UA could reasonably infer that the credentials it has for
that XMPP service are also valid at this SIP service.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Dec 2009 10:45:20 -0700

+1

On 12/9/09 6:11 AM, [email-masked] wrote:
> Hello, Below is the proposed charter text for Combining SIP and XMPP
> revised according to the discussions in Hiroshima. Basically the
> changes are
> 
> - include video in addition to voice - mention that existing SIP and
> XMPP endpoints are not affected - update milestones.
> 
> Regards, Simo
> Currently most standards-based Voice over IP (VoIP) deployments use
> the Session Initiation Protocol (SIP).  In addition to providing
> basic voice service SIP has an extensive support for more advanced
> telephony features including interworking with the traditional Public
> Switched Telephone Network (PSTN).  SIP is also gaining popularity in
> the field of video communication. At the same time, the Extensible
> Messaging and Presence Protocol (XMPP) is enjoying widespread usage
> in instant messaging and presence services.
> 
> Both SIP and XMPP offer extensions for integrating voice and video
> with IM and presence (XMPP voice via the Jingle extension, and SIP
> IM/presence via SIMPLE protocols). However, widespread deployment of
> these extensions has not so far taken place. In order to speed up
> deployment of integrated VoIP and IM systems, SIP based voice and
> XMPP based IM/Presence could be combined in endpoints to offer a
> voice, IM and presence service without any changes to existing SIP
> and XMPP service infrastructure.
> 
> The objective of this Working Group is to develop solutions for
> combining SIP based voice with XMPP based IM and Presence such that a
> unified user experience can be offered to end user. Specifically,
> solutions are needed on - addressing; end users should be able to
> initiate sessions to a user identity in either SIP or XMPP domain.
> The corresponding user identity in the other protocol domain needs to
> be learned automatically. - session correlation; endpoints need to be
> able to correlate SIP voice and video sessions with XMPP IM/Presence
> in such a manner that they can be presented to the end user in a
> seamless fashion - presence; it should be possible to change the XMPP
> presence status based on the user's activity in the SIP domain.
> 
> Existing SIP and XMPP endpoints are not affected and can interoperate
> with the implementations that comply with the extensions defined by
> this Working Group (but obviously without the additional
> functionality provided by these extensions).
> 
> Milestones Jun 2010 Problem statement and use cases submitted to IESG
> as Informational. Jun 2011 Specification on combining SIP based voice
> and video and XMPP based IM/Presence in a seamless manner submitted
> to IESG as Proposed Standard.
> 
> _______________________________________________ dispatch mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/dispatch

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Dec 2009 10:49:41 -0700

On 12/10/09 1:41 AM, Emil Ivov wrote:
> Consider for example a provider that is deploying a SIP+XMPP service.
> Is it supposed to:
> 
> - authentication; when authenticating against a SIP and an XMPP
> service that were meant to be used jointly, end users should only
> need to provide a single set of credentials.
> 
> How does this sound?

It sounds out of scope to me. This is a matter of local service policy.
Yes, it's a good idea for a given service operator to do that, but the
proposed WG will not (and IMHO should not) be defining best practices
for service operators, but instead focusing on the more narrow problem
of defining protocol elements that will enable end users to have a
seamless experience in dual-stack clients. Not that I'm opposed to a
best practices document for service operators, but I think that can be
handled via an independent submission.

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 19:39:42 +0100

На 10.12.09 18:49, Peter Saint-Andre написа:
> It sounds out of scope to me. 

Well, aren't we in the process of defining the scope?

> This is a matter of local service policy.

How should a user agent discover this policy?

> handled via an independent submission.

My concern is that unless we clearly define this it would be hard for UA
developers to come up with a solution that is both generic and user
friendly.

Again, you would either need to make users configure two separate
accounts, or make service providers distribute proprietary clients. I
thought it was part of IETF's job to avoid such things.

Cheers,
Emil

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 19:47:29 +0100

> that XMPP service are also valid at this SIP service.

This could be one solution, indeed. However, in order for the SIP server
to be able to include such a URI we need the charter to allow one of the
xmpp+sip documents to state how cross authentication will be handled.

Cheers,
Emil

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 10 Dec 2009 13:55:07 -0500

> thought it was part of IETF's job to avoid such things.

I think it's the job of the IETF to describe/define how the protocol
works on the wire; _not_ how service providers architect their
offerings.  There are any number of ways to do that, and for most of
them the clients just don't need to know.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 20:06:42 +0100

> them the clients just don't need to know.

This is not about service providers architecturing their offerings. This
is about allowing UA developers to build clients which would work with
_any_ provider. Clients that don't require users to enter two user names
and two passwords so that they would connect to one service.

Cheers,
Emil

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 10 Dec 2009 14:13:38 -0500

> and two passwords so that they would connect to one service.

... but it's not one service - it's two.  No one is suggesting that XMPP
and SIP are to be merged.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 20:22:53 +0100

> and SIP are to be merged.

Indeed not. We are suggesting that they are combinded "[so] that a
unified user experience can be offered to end user."

Cheers,
Emil

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 10 Dec 2009 13:26:49 -0600

Hi, Scott and Emil,

> and SIP are to be merged.

is this the disconnect - that Emil is thinking that either (1) one of the 
protocols changes to accept credentials from the other protocol, or (2) we 
come up with a mechanism that does single-signon for both protocols, while 
Scott is thinking that we're just connecting to two different services, with 
this detail hidden by whatever client application knows how to do both?

Thanks,

Spencer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 20:40:23 +0100

Hey Spencer,

На 10.12.09 20:26, Spencer Dawkins написа:
> come up with a mechanism that does single-signon for both protocols, 

It doesn't need to be a protocol change or a new single-sinon mechanism.
Both of these are possible options but probably a bit too disruptive
given the we-are-not-inventing-a-new-protocol prerequisite that we have
set ourselves.

From a UA perspective it would be enough to simply know (i.e. have it
written somewhere) that clients use the same credentials against both
servers.

I am guessing however that simply enforcing this would contradict use
cases that others here may have in mind. This is why I was suggesting
that we should think this through once the new WG is formed.

Cheers,
Emil

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Thu, 10 Dec 2009 14:48:28 -0500

Hi Emil,

The following is a quote from the draft's abstract:
"It is even possible that SIP and XMPP services are offered by different service providers"

In this case I do not think that you can use the same credentials for both services.

Regards,
 Rifaat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: Thursday, December 10, 2009 2:40 PM
To: Spencer Dawkins
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP

Hey Spencer,

На 10.12.09 20:26, Spencer Dawkins написа:
> is this the disconnect - that Emil is thinking that either (1) one of
> the protocols changes to accept credentials from the other protocol,
> or (2) we come up with a mechanism that does single-signon for both
> protocols,

It doesn't need to be a protocol change or a new single-sinon mechanism.
Both of these are possible options but probably a bit too disruptive given the we-are-not-inventing-a-new-protocol prerequisite that we have set ourselves.

>From a UA perspective it would be enough to simply know (i.e. have it written somewhere) that clients use the same credentials against both servers.

I am guessing however that simply enforcing this would contradict use cases that others here may have in mind. This is why I was suggesting that we should think this through once the new WG is formed.

Cheers,
Emil

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 20:51:08 +0100

> In this case I do not think that you can use the same credentials for both services.

Absolutely, which is why I said we probably wouldn't want to enforce
this and give it some further thought once the WG is formed.

Cheers,
Emil

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 10 Dec 2009 14:02:00 -0600

Hi, Emil,

I think I'm following you - you're saying that the client should be smart 
enough that I only have to enter [email-masked] once, and the 
client would be able to use that string as my SIP AOR as well as my Jabber 
ID, right?

Thanks,

Spencer

----- Original Message ----- 
From: "Emil Ivov" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Scott Lawrence" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Thursday, December 10, 2009 1:40 PM
Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP

Hey Spencer,

Cheers,
Emil

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Dec 2009 21:05:11 +0100

> client would be able to use that string as my SIP AOR as well as my Jabber 

Right!

Cheers,
Emil

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 21:06:23 +0100

Hi, 

Emil Ivov wrote:
>Absolutely, which is why I said we probably wouldn't want to 
>enforce this and give it some further thought once the WG is formed.
>

I think it is valuable that the SIP and XMPP *can* be offered by different completely independent providers. That provides most flexibility on the client side, and we don't really loose much. On the other hand it's a valid case too that SIP and XMPP come from the same provider. Whether that's one or two services is semantics, but I think it should be possible to offer that to the user as one service. (The user does not care how many different protocols are used, but they of course do care about the identities they get.) So I'm symphathetic to Emil's goal to improve client <-> service provider interoperability and user experience. 

Markus

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 10 Dec 2009 14:06:32 -0600

ah - thanks! i was reading more into "credentials" than you meant to say.

Spencer

----- Original Message ----- 
From: "Emil Ivov" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Scott Lawrence" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Thursday, December 10, 2009 2:05 PM
Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP

Right!

Cheers,
Emil

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Dec 2009 13:06:53 -0700

>> client would be able to use that string as my SIP AOR as well as my Jabber 

That's a wonderful thing, but AFAICS it is a provisioning issue.

Peter

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

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Thu, 10 Dec 2009 15:26:48 -0500

> So I'm symphathetic to Emil's goal to improve client <-> service provider interoperability and user experience.

Well, I think we all sympathetic to this goal, but this has nothing to do with this draft. I think that it is up to the client to address this issue.

Regards,
 Rifaat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 10, 2009 3:06 PM
To: [email-masked]; Shekh-Yusef, Rifaat (BVW:9T16)
Cc: [email-masked]; [email-masked]
Subject: RE: [dispatch] Revised proposed charter for Combining SIP and XMPP

Hi, 

Markus

---

From: Roni Even <[email-masked]>
Date: Thu, 10 Dec 2009 23:08:27 +0200

Hi,
I think that it must be stated very clearly that the assumption is that both
XMPP client and SIP client reside on the same endpoint.
I also think that the issue of support for multipoint (chat and audio/video)
should be specified, is it in scope or not.
Thanks
Roni Even

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, December 09, 2009 3:11 PM
> To: [email-masked]
> Subject: [dispatch] Revised proposed charter for Combining SIP and XMPP
> 
> Hello,
> Below is the proposed charter text for Combining SIP and XMPP revised
> according to the discussions in Hiroshima. Basically the changes are
> 
> Currently most standards-based Voice over IP (VoIP) deployments use the
> Session Initiation Protocol (SIP).  In addition to providing basic
> voice service SIP has an extensive support for more advanced telephony
> features including interworking with the traditional Public Switched
> Telephone Network (PSTN).  SIP is also gaining popularity in the field
> of video communication. At the same time, the Extensible Messaging and
> Presence Protocol (XMPP) is enjoying widespread usage in instant
> messaging and presence services.
> 
> Both SIP and XMPP offer extensions for integrating voice and video with
> IM and presence (XMPP voice via the Jingle extension, and SIP
> deployment of integrated VoIP and IM systems, SIP based voice and XMPP
> based IM/Presence could be combined in endpoints to offer a voice, IM
> and presence service without any changes to existing SIP and XMPP
> service infrastructure.
> 
> solutions are needed on
> - addressing; end users should be able to initiate sessions to a user
> identity in either SIP or XMPP domain. The corresponding user identity
> in the other protocol domain needs to be learned automatically.
> - session correlation; endpoints need to be able to correlate SIP voice
> and video sessions with XMPP IM/Presence in such a manner that they can
> be presented to the end user in a seamless fashion
> - presence; it should be possible to change the XMPP presence status
> based on the user's activity in the SIP domain.
> 
> this Working Group (but obviously without the additional functionality
> provided by these extensions).
> 
> Jun 2011 Specification on combining SIP based voice and video and XMPP
> based IM/Presence in a seamless manner submitted to IESG as Proposed
> Standard.
>

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 11 Dec 2009 09:34:56 +0100

> That's a wonderful thing, but AFAICS it is a provisioning issue.

That is a provisioning decision indeed, but a means in the protocol for
indicating when a set of credentials can be used across different
services seems quite desirable. And I guess, at least in the case of
digest authentication, also easily achievable with proper usage of RFC
2617, as Scott pointed out. All is needed, as far as I understand it, is
just some descriptive text put visibly in some key document the WG will
produce.

If that is out-of-scope for the WG-to-be, or if it doesn't address the
use case being discussed, please help me understand what I am missing.

-- 
Ciao,
Enrico

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Dec 2009 09:42:37 +0100

I agree with Rifaat. The client's provisioning interface can include a short cut that allows a user to use the same credentials for XMPP as are used for SIP (or vice versa). We don't need to standardize that and we certainly need to cater for the more general case of there being two service providers.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
> Sent: 10 December 2009 20:27
> To: [email-masked]; [email-masked]
>  > So I'm symphathetic to Emil's goal to improve client <-> 
> service provider interoperability and user experience.
> 
> Well, I think we all sympathetic to this goal, but this has 
> nothing to do with this draft. I think that it is up to the 
> client to address this issue.
> 
> Regards,
>  Rifaat
> 
> I think it is valuable that the SIP and XMPP *can* be offered 
> by different completely independent providers. That provides 
> most flexibility on the client side, and we don't really 
> loose much. On the other hand it's a valid case too that SIP 
> and XMPP come from the same provider. Whether that's one or 
> two services is semantics, but I think it should be possible 
> to offer that to the user as one service. (The user does not 
> care how many different protocols are used, but they of 
> course do care about the identities they get.) So I'm 
> symphathetic to Emil's goal to improve client <-> service 
> provider interoperability and user experience. 
> 
> Markus

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Dec 2009 09:44:43 +0100

> [mailto:[email-masked]] On Behalf Of Enrico Marocco
> Sent: 11 December 2009 08:35
> To: Peter Saint-Andre
[JRE] I don't object to that, but this doesn't need to be in the charter.

John

---

From: Schumann Sebastian <[email-masked]>
Date: Fri, 11 Dec 2009 10:28:48 +0100

Hi

A would second the case that Roni was raising.

It might appear that users will have SIP hardware endpoints, but the provider might want to offer all "non-voice/call related" communication (messaging, presence etc) over XMPP.

I see it feasible to have the SIP presence state of a certain endpoint influence the XMPP state of another endpoint. E.g., on-the-phone from a hardware endpoint to have the XMPP user appearing as DND etc.

Sebastian

> [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Thursday, 10. December 2009 22:08
> To: [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 09:05:40 +0100

>From: Emil Ivov [mailto:[email-masked]] On Behalf Of ext Emil
>

Hmm, I guess before doing the initial registration, the client could just ask the credentials (username and password) once and use them for both SIP and XMPP services - but that would require the client to know beforehand that the same credentials are good for both services.

So are you asking for an indication from the SIP or XMPP server saying something like "your registration to SIP service at example.org service was successful, and, by the way, you can you use the same username and password for registering to XMPP service at example.org"?

Simo

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 09:47:30 +0100

>From: ext Roni Even [mailto:[email-masked]]
>Sent: 10 December, 2009 23:08
>To: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]

Having both SIP and XMPP clients on the same endpoint is the assumption we have - otherwise there couldn't be a "combined" endpoint. Could you point to a specific place in the charter text which you feel needs clarification.

>should be specified, is it in scope or not.

This might be good to state in the charter. My opinion is that we should not develop solutions specifically for multipoint use cases. To me that seems quite large problem area which is beyond what we are trying to address here.

Simo

>the
>with

---

From: Roni Even <[email-masked]>
Date: Mon, 14 Dec 2009 10:53:32 +0200

Hi,
I think that this will also require not only some common relation between the SIP and XMPP clients but also some co-ordination between the XMPP server and SIP server and according to my understanding this is out of scope in the charter.

On the other hand I see more benefits of such co-ordination since it will allow the SIP client and XMPP client to be separate. I thought that such work is in the scope of the XMPP working group.

Roni

> Sent: Monday, December 14, 2009 10:06 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Hmm, I guess before doing the initial registration, the client could
> just ask the credentials (username and password) once and use them for
> both SIP and XMPP services - but that would require the client to know
> beforehand that the same credentials are good for both services.
> 
> So are you asking for an indication from the SIP or XMPP server saying
> something like "your registration to SIP service at example.org service
> was successful, and, by the way, you can you use the same username and
> password for registering to XMPP service at example.org"?
> 
> Simo
> 
> >Cheers,
> >Emil
>

---

From: Roni Even <[email-masked]>
Date: Mon, 14 Dec 2009 11:07:41 +0200

Simo,
The text in the proposed charter " The goal is to rely on existing service
infrastructure, and new requirements should be imposed only on the
endpoints." Is not strong enough since it is a SHOULD while as far as I
understand you mean "SHALL". 
Roni Even

> Sent: Monday, December 14, 2009 10:48 AM
> To: [email-masked]; [email-masked]
> >I think that it must be stated very clearly that the assumption is
> that
> >both
> Having both SIP and XMPP clients on the same endpoint is the assumption
> we have - otherwise there couldn't be a "combined" endpoint. Could you
> point to a specific place in the charter text which you feel needs
> clarification.
> 
> This might be good to state in the charter. My opinion is that we
> should not develop solutions specifically for multipoint use cases. To
> me that seems quite large problem area which is beyond what we are
> trying to address here.
> 
> Simo
> 
> 
> >Thanks
> >Roni Even
> >
> >
> XMPP

---

From: Roni Even <[email-masked]>
Date: Mon, 14 Dec 2009 11:13:31 +0200

Simo,
On the multipoint case, I think that the proposal should at least discuss
it, not proposing a solution but pointing out what will work and what not.
Thinking about it, I think that it relates to other services like call
transfer on the SIP side what happens to the XMPP session, is this in scope
to cause transfer of both sessions.

I am not sure where the charter ends, is it just for establishing simple
point to point calls and terminating them while any other call features are
out of scope?

Roni

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 10:35:09 +0100

Hi,

I think we should take the following step-wise approach:

1. Define the necessary standards for the basic 1-to-1 VoIP+video+IM+presence use cases with a combined SIP+XMPP client. This should be the initial charter. 
2. Get some running code and hopefully even deployments to see that we are on a useful track. (If nothing happens, we probably aren't, and should do something else.)
3. Only after that, go into more complex cases (transfer, multipoint etc.). 

The challenge of course is that in step 1. we should aim at such modularity that what is defined is forward-compatible with what we might want to achieve in step 3. I don't propose that we put any hard requirements on the charter to have such a review, but definitely that should be one dimension for instance when comparing different approaches.

Markus

>[mailto:[email-masked]] On Behalf Of ext Roni Even
>Sent: 14 December, 2009 11:14
>On the multipoint case, I think that the proposal should at 
>least discuss it, not proposing a solution but pointing out 
>what will work and what not.
>Thinking about it, I think that it relates to other services 
>like call transfer on the SIP side what happens to the XMPP 
>session, is this in scope to cause transfer of both sessions.
>
>I am not sure where the charter ends, is it just for 
>establishing simple point to point calls and terminating them 
>while any other call features are out of scope?
>
>Roni  
>
>[mailto:[email-masked]] On 
>> Subject: Re: [dispatch] Revised proposed charter for 
>Combining SIP and 
>> XMPP
>> 
>> 
>> 
>> Having both SIP and XMPP clients on the same endpoint is the 
>> assumption we have - otherwise there couldn't be a "combined" 
>> endpoint. Could you point to a specific place in the charter text 
>> which you feel needs clarification.
>> 
>> >> features including interworking with the traditional Public 
>> >> Switched Telephone Network (PSTN).  SIP is also gaining 
>popularity 
>> >> in the
>> field
>> >> IM/presence via SIMPLE protocols). However, widespread deployment 
>> >> of these extensions has not so far taken place. In order to speed 
>> >> up deployment of integrated VoIP and IM systems, SIP based voice 
>> >> and
>> XMPP
>> >> combining SIP based voice with XMPP based IM and Presence 
>such that
>> a
>> >> and video sessions with XMPP IM/Presence in such a manner 
>that they
>> >can
>> >> - presence; it should be possible to change the XMPP presence 
>> >> status based on the user's activity in the SIP domain.
>> >>
>> >> based IM/Presence in a seamless manner submitted to IESG as 
>> >> Proposed Standard.
>> >>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 14 Dec 2009 12:36:29 +0100

Hey Simo,

На 14.12.09 09:05, [email-masked] написа:
> just ask the credentials (username and password) once and use them
> for both SIP and XMPP services - but that would require the client to
> know beforehand that the same credentials are good for both
> services.

Right.

> So are you asking for an indication from the SIP or XMPP server
> saying something like "your registration to SIP service at
> example.org service was successful, and, by the way, you can you use
> the same username and password for registering to XMPP service at
> example.org"?

Yes, something along these lines would do just fine. This could also
help discovering that there is an associated XMPP service in the first
place and could also be used for discovering its address in case it is
different from the XMPP server at example.org.

Cheers,
Emil

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Dec 2009 08:06:52 -0500

I don't know how XMPP does authentication, but if it can use digest, 
then as someone else already mentioned, the "common credentials" can be 
automatic. Its a matter of the servers being integrated enough to use 
the same user, pw, and realm, and for the client to be integrated enough 
to recognize that the same realm has been requested.

At that point it becomes a "quality of implementation" issue, on a par 
with implementing digest to cache and reuse credentials rather than 
asking for them again every time challenged.

	Thanks,
	Paul

---

From: Roni Even <[email-masked]>
Date: Mon, 14 Dec 2009 15:43:34 +0200

The current proposed charter requires no dependency on the server infrastructure, if we change it than we need to discuss other functionality that may be dependent on support in the infrastructure.

>From the proposed charter:
" The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint."

BTW: The above requirement about no dependency was discussed also in Hiroshima.

Roni Even

> Behalf Of Paul Kyzivat
> Sent: Monday, December 14, 2009 3:07 PM
> To: Emil Ivov

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 15:19:11 +0100

>The current proposed charter requires no dependency on the server
>infrastructure, if we change it than we need to discuss other
>functionality that may be dependent on support in the infrastructure.
>
>" The goal is to rely on existing service infrastructre, and new
>requirements should be imposed only to the endpoint."

This is correct and at least I would like to keep it that way. However, if the same credentials are used for both SIP and XMPP, it would mean the SIP and XMPP infras share the same credentials database. How this is done (or if a provider decides to do that in the first place) should be out of scope of this charter.

Whether a protocol mechanism should be implemented for indicating to the client that the same credentials can also be used in the other domain is another issue. I see there might be value in such a mechanism, and one possible way of doing this is to simply provide the same "realm" to the client. But this doesn't necessarily have to be in the charter - we can still document it in the I-D's and RFCs we are producing if folks see this as a useful thing to do.

Simo

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Dec 2009 07:45:01 -0700

On 12/14/09 6:06 AM, Paul Kyzivat wrote:
> I don't know how XMPP does authentication, 

As described in RFC 3920, XMPP uses SASL. The most commonly used
mechanisms are DIGEST-MD5 (currently being deprecated in favor of
SCRAM), PLAIN (over TLS), EXTERNAL, and ANONYMOUS.

> but if it can use digest,

Quite possibly.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Dec 2009 08:04:19 -0700

On 12/14/09 7:19 AM, [email-masked] wrote:
>> -----Original Message----- From: ext Roni Even
>> [mailto:[email-masked]]
>> 
>> From the proposed charter: " The goal is to rely on existing
>> service infrastructre, and new requirements should be imposed only
>> to the endpoint."
> 
> This is correct and at least I would like to keep it that way.
> However, if the same credentials are used for both SIP and XMPP, it
> would mean the SIP and XMPP infras share the same credentials
> database. How this is done (or if a provider decides to do that in
> the first place) should be out of scope of this charter.

Agreed. As I understand it, this group is trying to define some simple
methods that make it easier to implement a dual-stack (SIP/XMPP) client.
IMHO it would best to complete some of the "low-hanging fruit" before
adding additional complexities. And you can bet that anything involving
authentication will be complex, or at least controversial.

> Whether a protocol mechanism should be implemented for indicating to
> the client that the same credentials can also be used in the other
> domain is another issue. I see there might be value in such a
> mechanism, and one possible way of doing this is to simply provide
> the same "realm" to the client. But this doesn't necessarily have to
> be in the charter - we can still document it in the I-D's and RFCs we
> are producing if folks see this as a useful thing to do.

Agreed.

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Mon, 14 Dec 2009 16:25:47 +0100

Hey Simo,

> are producing if folks see this as a useful thing to do.

As long as people don't see such documenting (i.e. recommendations/best
practices directed toward server side developers and maintainers) as a
contradiction with the above quote from the charter, then that would
indeed be just fine.

Emil

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Dec 2009 09:09:45 -0700

> contradiction with the above quote from the charter, then that would

The charter is a positive statement of what the group will work on. That
doesn't forbid the group (or certainly individual contributors) from
working on other tasks that are deemed helpful.

Peter

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

---

From: Roni Even <[email-masked]>
Date: Tue, 15 Dec 2009 01:00:58 +0200

Hi,
I want to clarify that during the Hiroshima session my view was that support for some infrastructure assumption will be beneficial. I had other use case where you have a video conferencing SIP appliance that does not have XMPP support in a room with a PC that does the XMPP talking to a client that does both XMPP and SIP. The infrastructure is this case will need to know the relation between the appliance and the PC similar to the case discussed here where both client share the same credentials, this need to be supported in the infrastructure and somehow conveyed to the clients.
The way I see it is that Simo's view as was presented in Hiroshima is that the clients will need to assume two separate servers with no relations and any assumption on relation between the servers is not part of the charter.

To summarize, I think this is not a question of shared credentials but a question if the sentence " The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint." is part of the charter.

Roni Even

> From: Emil Ivov [mailto:[email-masked]] On Behalf Of Emil
> Ivov
> Sent: Monday, December 14, 2009 5:26 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Wed, 16 Dec 2009 10:56:04 +0100

>I want to clarify that during the Hiroshima session my view was that
>support for some infrastructure assumption will be beneficial. I had
>other use case where you have a video conferencing SIP appliance that
>does not have XMPP support in a room with a PC that does the XMPP
>talking to a client that does both XMPP and SIP. The infrastructure is
>this case will need to know the relation between the appliance and the
>PC similar to the case discussed here where both client share the same
>credentials, this need to be supported in the infrastructure and somehow
>conveyed to the clients.
>The way I see it is that Simo's view as was presented in Hiroshima is
>that the clients will need to assume two separate servers with no
>relations and any assumption on relation between the servers is not part
>of the charter.

A "dual stack" SIP/XMPP client should be able to talk SIP to a SIP-only endpoint and XMPP to an XMPP-only endpoint. What is that you need in addition to this? 

Simo

>To summarize, I think this is not a question of shared credentials but a
>question if the sentence " The goal is to rely on existing service
>infrastructre, and new requirements should be imposed only to the
>endpoint." is part of the charter.
>
>Roni Even
>

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 14:47:34 +0200

Simo
Inline
Roni

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 16, 2009 11:56 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> A "dual stack" SIP/XMPP client should be able to talk SIP to a SIP-only
> endpoint and XMPP to an XMPP-only endpoint. What is that you need in
> addition to this?
The dual stack client need to know that these two clients are the same user. For example start a XMPP chat and add the SIP video call. This is not advertised by the remote XMPP client but by the infrastructure. 

>From the other direction (two systems) it will involve starting chat from XMPP and adding SIP video to the call by the XMPP client for example by telling the other side or the SIP server to call the his SIP client on the appliance.

> >> Subject: Re: [dispatch] Revised proposed charter for Combining SIP
> and
> >> XMPP
> >>
> >> Hey Simo,
> >>

---

From: <[email-masked]>
Date: Thu, 17 Dec 2009 13:33:59 +0100

Roni,

>The dual stack client need to know that these two clients are the same
>user. For example start a XMPP chat and add the SIP video call. This is
>not advertised by the remote XMPP client but by the infrastructure.
>
>From the other direction (two systems) it will involve starting chat
>from XMPP and adding SIP video to the call by the XMPP client for
>example by telling the other side or the SIP server to call the his SIP
>client on the appliance.
>

Let me see if I understood you correctly. It sounds you are looking for two use cases:

1) to add SIP voice/video or XMPP chat from an integrated endpoint even though the other endpoint is SIP-only or XMPP-only

2) to add SIP voice/video or XMPP chat from a XMPP-only or SIP-only endpoint, respectively.

For 2), I don't see how that is possible without changes in the client side. 

For 1), you would need to be able, from a "dual stack" endpoint, to tell the XMPP server to start an XMPP session, or the SIP server to make a SIP call to the same user you already have a SIP or XMPP session with. While probably doable, this is not what we had in mind for this work.

Simo

---

From: Roni Even <[email-masked]>
Date: Thu, 17 Dec 2009 14:57:36 +0200

Simo,
The other user has two endpoints, one is a video conferencing appliance and
the other is a PC running XMPP client. The user will register his XMPP and
SIP capability using the two endpoints in the infrastructure
Roni

> Sent: Thursday, December 17, 2009 2:34 PM
> 1) to add SIP voice/video or XMPP chat from an integrated endpoint even
> though the other endpoint is SIP-only or XMPP-only
> 
> For 1), you would need to be able, from a "dual stack" endpoint, to
> tell the XMPP server to start an XMPP session, or the SIP server to
> make a SIP call to the same user you already have a SIP or XMPP session
> with. While probably doable, this is not what we had in mind for this
> work.
> 
> Simo