Subject: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.txt

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 05 Mar 2012 14:20:47 -0700

As seen on the I-D-announce list...

-------- Original Message --------
Subject: I-D Action: draft-ivov-xmpp-cusax-00.txt
Date: Mon, 05 Mar 2012 12:18:24 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Combined Use of the Session Initiation Protocol (SIP)
and the eXtensible Messaging and Presence Protocol (CUSAX)
	Author(s)       : Emil Ivov
                          Enrico Marocco
	Filename        : draft-ivov-xmpp-cusax-00.txt
	Pages           : 8
	Date            : 2012-03-05

   This document describes current practices for combined use of the
   Session Initiation Protocol (SIP) and the eXtensible Messaging and
   Presence Protocol (XMPP).  Such practices aim to provide a single
   fully featured real-time communication service by using complimenting
   subsets of features from each of the protocols.  Typically such
   subsets would include telephony oriented from SIP and instant
   messaging and presence capabilities from XMPP.  This specification
   does not define any new protocols or syntax for neither SIP nor XMPP.
   However, implementing it may require modifying or at least
   reconfiguring existing client and server-side software.  Also, it is
   not the purpose of this document to make recommendations as to
   whether or not such combined us should be preferred to the mechanisms
   provided natively by each protocol like for example SIP's SIMPLE or
   XMPP's Jingle.  It merely aims to provide guidance to those who are
   interested in such a combined use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ivov-xmpp-cusax-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ivov-xmpp-cusax-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Emil Ivov <[email-masked]>
Date: Tue, 06 Mar 2012 13:00:16 +0200

Thanks for the note, Peter!

All, the draft addresses a problem that has been raised and discussed on
multiple occasions (including the SIXPAC effort from about a year ago).
The point of this approach is to simply put forward common practices
that people are resorting to in order to combine strengths of SIP and
XMPP implementations.

This is a very preliminary version that we've submitted in order to
gauge interest, get initial feedback on open issues and the approach
itself (and the fact that it was submitted a couple of hours before 00
cutoff is of course purely coincidental).

What we'd like to hear at this time is whether people think such a
document would make sense and also:

* currently the document only vaguely mentions client provisioning. Does
anyone think we should make this more specific and possibly quote some
existing mechanisms?

* During the SIXPAC effort it was suggested that clients could log onto
a SIP service and use the domain parameter in digest authentication to
discover the XMPP domain. Does anyone think this would make sense?

* Currently the draft suggests a couple of alternatives for determining
an XMPP identity from an incoming SIP request. One consists in searching
the roster for an entry whose VCARD contains the source URI (but that
only works if the caller is already in our roster). The other one would
be to add a second contact header to outgoing INVITEs and put an xmpp
uri in there corresponding to the caller's JID. Any thoughts on this?

Cheers,
Emil

--
http://jitsi.org

On 05.03.12 23:20, Peter Saint-Andre wrote:
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 09:28:42 -0700

Hi Emil!

On 3/6/12 4:00 AM, Emil Ivov wrote:
> document would make sense 

I think so. At the same time, it would be worth looking again at the
various other solutions and mechanisms that have been suggested over the
years, such as:

http://tools.ietf.org/id/draft-saintandre-sip-xmpp-core-01.txt
http://tools.ietf.org/id/draft-saintandre-sip-xmpp-presence-02.txt
http://tools.ietf.org/id/draft-saintandre-sip-xmpp-im-01.txt
http://tools.ietf.org/id/draft-saintandre-sip-xmpp-chat-03.txt
http://tools.ietf.org/id/draft-saintandre-sip-xmpp-groupchat-01.txt
http://tools.ietf.org/id/draft-saintandre-sip-xmpp-media-01.txt
http://tools.ietf.org/id/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt
http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt
http://xmpp.org/extensions/xep-0152.html

> and also:

I see no harm in mentioning existing techniques.

> discover the XMPP domain. Does anyone think this would make sense?

That sounds confusing to me -- better, I think, to use the existing
methods for discovering your XMPP server.

> uri in there corresponding to the caller's JID. Any thoughts on this?

One objection to a SIP header for an alterative contact method was that
it might be stripped out by intermediaries such as B2BUAs. I happen to
think we might need to experiment with several approaches -- the vCard
entries you mention, a second SIP header containing a JID, an XMPP
extension containing a SIP address as in XEP-0152 -- to see what works.

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Wed, 07 Mar 2012 19:35:42 +0200

Hey Peter,

Thanks for your feedback!

(inline)

> http://tools.ietf.org/id/draft-saintandre-sip-xmpp-media-01.txt

Agreed. We should definitely mention those and maybe explain why they
address different goals than what we have with CUSAX. Something along
the lines of achieving coexistance with minimum to no implementation
changes and mostly as a temporary measure until most of the features
people are looking for are found in either XMPP only or SIP only
implementations (knowing that such features could also be provided by
sip-xmpp gateways).

> http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt

What we are trying with CUSAX is actually quite similar to the above and
what was attempted with the SIXPACK WG ... we just try to keep it a lot
simpler. We would like to avoid standardizing any new stuff (especially
SIP headers). We just wanted to describe what we find to be the best
practices that people are doing in cases when they need such
co-existance. That's why we'd like to keep the document as info or bcp.

> http://xmpp.org/extensions/xep-0152.html

Thanks for this one! It would definitely be very useful!

> methods for discovering your XMPP server.

Noted. We'd also prefer to avoid it but we thought we'd ask just the same.

> it might be stripped out by intermediaries such as B2BUAs.

Yup that could indeed happen quite often.

> I happen to
> entries you mention, a second SIP header containing a JID,

Or we could advise using both in a best effort way. That is, look for a
second contact, but if you don't find it in incoming INVITEs, then just
look through the VCARDs in your roster and declare the caller as unknown
if nothing appears.

> an XMPP

Right, this one could be useful for the opposite direction, in case
there's nothing in the VCARD we got from our XMPP server.

Cheers,
Emil

-- 
http://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 11:03:22 -0700

On 3/7/12 10:35 AM, Emil Ivov wrote:
> SIP headers).  

I asked about SIP headers specifically because your I-D says:

   An alternate mechanism would be for CUSAX clients to add to their SIP
   invite requests a contact header containing their XMPP JID, but at
   this point we are not really sure if that's ' such a good idea.
   (After all Contact headers carry URIs and JIDs are not URIs).

There is a URI scheme for XMPP:

http://tools.ietf.org/html/rfc5122

However, if you mean the SIP Contact header, then that appears to be
restricted to SIP/SIPS URIs (RFC 3361, Section 8.1.1.8):

   The Contact header field provides a SIP or SIPS URI that can be used
   to contact that specific instance of the UA for subsequent requests.
   The Contact header field MUST be present and contain exactly one SIP
   or SIPS URI in any request that can result in the establishment of a
   dialog.  For the methods defined in this specification, that includes
   only the INVITE request.

However, Section 20.10 of RFC 3261 doesn't restrict Contact headers to
SIP/SIPS URIs (and includes an example of a 'mailto' URI):

http://tools.ietf.org/html/rfc3261#section-20.10

If a SIP INVITE is allowed to contain a Contact header that includes an
XMPP URI (apparently in addition to "exactly one SIP or SIPS URI"), then
that seems to be one way to advertise a JID on the SIP side of the
equation. On the XMPP side, we could use XEP-0152. And in the vCard we
could include both an XMPP URI (in vCard4, via the <impp/> element) and
a SIP URI (via the <tel/> element). IMHO that would provide pretty good
coverage.

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Wed, 07 Mar 2012 20:45:26 +0200

Hey Peter,

> http://tools.ietf.org/html/rfc5122

Yes, that's what we had in mind.
> 
> However, if you mean the SIP Contact header,

That was the idea, yes. We wanted to reuse the Contact header and hence
avoid the need for standardizing a new one.

> then that appears to be

That was supposed to say "3261", right?

>    dialog.  For the methods defined in this specification, that includes

Well, I read that as a requirement of the presence of (at least one)
Contact header with exactly one SIP/SIPS URI, rather than a prohibition
of secondary contact headers. I agree the text is somewhat ambiguous
though so I might be missing the point.

FWIW 3261 does contain examples with non-SIP URI(L)s in Contact, like
the 200 OK in 11.2 that has:

      Contact: <sip:[email-masked]>
      Contact: <mailto:[email-masked]>

> http://tools.ietf.org/html/rfc3261#section-20.10

There's that too, yes.

> a SIP URI (via the <tel/> element). IMHO that would provide pretty good

Agreed. Do we actually even need to add an XMPP uri in the VCARD
provided that we are retrieving it for an entry in our XMPP roster? Or
am I missing something?

Emil

-- 
http://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 11:49:29 -0700

> avoid the need for standardizing a new one.

I like that approach.

> That was supposed to say "3261", right?

Yep.

> provided that we are retrieving it for an entry in our XMPP roster? Or

Well, if you share the vCard with anyone who's not on XMPP, then it's
good to have your JID in there for the sake of completeness. But you're
right that in the context you're discussing, it's not necessary.

Peter

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