Subject: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN

From: Alan Johnston <[email-masked]>
Date: Fri, 1 Aug 2014 09:50:47 -0500

Hi,

In the TRAM WG, we are working on an extension to STUN/TURN for a client to
convey origin information to a server.

     http://tools.ietf.org/html/draft-ietf-tram-stun-origin

The driver for this effort is WebRTC, where the origin is the HTTP origin
of the web site that is establishing the Peer Connection.  Other users of
STUN and TURN can also provide origin information.  The draft currently has
this text about SIP and XMPP:

   For a SIP User Agent [RFC3261] using STUN and TURN, the ORIGIN
   attribute is set to be the URI of the registrar server used by the
   User Agent (i.e. the Request-URI of a REGISTER method).

   For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN
   attribute is the Jabber ID (JID) [RFC6122] of the Jabber Server that
   the client is using.

We would greatly appreciate feedback from you on what this text should say
about XMPP/Jabber in terms of a useful origin.

- Alan -

---

From: Ralph Meijer <[email-masked]>
Date: Fri, 01 Aug 2014 17:12:26 +0200

On August 1, 2014 4:50:47 PM CEST, Alan Johnston <[email-masked]> wrote:
> [..]

Hi Alan,

Thanks for the heads-up.

Why the server address? In XMPP clients establishing media sessions, the communicating entity is fully addressable and its server might not be involves at all. Or, the server is itself providing for the STUN/TURN service, in which case the server address might not be so useful. In short, why not the (full) JID of the client for these cases?
-- 
ralphm

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 1 Aug 2014 09:45:20 -0600

Hi Alan, did you receive the email message I sent you on this topic some weeks ago? ;-)

Sent from mobile, might be terse 

> On Aug 1, 2014, at 8:50 AM, Alan Johnston <[email-masked]> wrote:
> 
> Hi,
> 
> In the TRAM WG, we are working on an extension to STUN/TURN for a client to convey origin information to a server.  
> 
> The driver for this effort is WebRTC, where the origin is the HTTP origin of the web site that is establishing the Peer Connection.  Other users of STUN and TURN can also provide origin information.  The draft currently has this text about SIP and XMPP:
> 
> We would greatly appreciate feedback from you on what this text should say about XMPP/Jabber in terms of a useful origin.
> 
> - Alan -
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Dave Cridland <[email-masked]>
Date: Fri, 1 Aug 2014 17:23:00 +0100

You might want to flag this with the [email-masked] list, and/or the
[email-masked] list.

My main comment is that since SIP and HTTP both use URIs here, you don't
want to use a jid, you want an XMPP URI. Whether this should be a URI to
the server, the account, or the client, really depends on what a STUN
server is meant to do with it.

My gut feeling is that you want just the server for most use-cases, but a
full jid might be more useful in others.

Also, my gut - which my wife says is growing, hence its ability to have
multiple opinions - says that you quite possibly want a bare domain in all
cases rather than a URI, since the realm-like use-cases are otherwise going
to imply that a STUN server know how to parse SIP, XMPP, and HTTP URIs, and
anything else that comes along later.

I've the vaguest notion that given the spread of use-cases, you possibly
want two attributes - an origin domain and an initiator URI.

On 1 August 2014 15:50, Alan Johnston <[email-masked]> wrote:

> Hi,
>
> In the TRAM WG, we are working on an extension to STUN/TURN for a client
> to convey origin information to a server.
>

---

From: Alan Johnston <[email-masked]>
Date: Fri, 1 Aug 2014 11:43:04 -0500

Dave,

Thanks for the feedback.  There are two main use cases for the extension in
multi-domain STUN/TURN servers.  One is for logging, and the other is for
realm selection.  For the former, the server doesn't need to parse it, just
log in.  For the other case, the server just needs to extract a domain name
that can hopefully be mapped to a realm.

The goal here is to make things simple on the client and have the client
just include something that it already knows in a known format.  This why
an HTTP origin and SIP registrar URI have been chosen.  We just need an
equivalent in XMPP that a domain can be identified/extracted.  STUN already
has a USERNAME attribute that can be used for individual client
identification - the goal isn't to replicate that here.

- Alan -

On Fri, Aug 1, 2014 at 11:23 AM, Dave Cridland <[email-masked]> wrote:

>> We would greatly appreciate feedback from you on what this text should
>> say about XMPP/Jabber in terms of a useful origin.
>>
>> - Alan -
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Aug 2014 10:49:15 -0600

Hi Alan,

Here's what I had sent to you and your co-authors in July 1st...

###

First, I think it's better to say "XMPP", not "Jabber".

This might be ambiguous:

If user's JID is [email-masked] but the "Jabber server" (resolved via 
SRV) is xmpp.hosting.example.net, we'd use "example.com".

The next paragraph indicates that the ORIGIN is supposed to be a URL:

    Other contexts can define a usage of the ORIGIN attribute to use an
    appropriate URI or URL.

In that case, we'd specify an XMPP URI (RFC 5122).

Thus I might suggest:

    For an XMPP client [RFC6120] using STUN and TURN, the ORIGIN
    attribute is an XMPP URI [RFC5122] representing the domainpart
    of the client's Jabber ID (JID) [RFC6122]; for example, if the
    client's JID is "[email-masked]/balcony" then the ORIGIN
    attribute would be "xmpp:im.example.com".

Peter

###

On 8/1/14, 9:45 AM, Peter Saint-Andre wrote:
> On Aug 1, 2014, at 8:50 AM, Alan Johnston <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi,
>>
>> In the TRAM WG, we are working on an extension to STUN/TURN for a
>> client to convey origin information to a server.
>>
>> The driver for this effort is WebRTC, where the origin is the HTTP
>> origin of the web site that is establishing the Peer Connection.
>>  Other users of STUN and TURN can also provide origin information.
>>  The draft currently has this text about SIP and XMPP:
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 01 Aug 2014 19:00:15 +0200

> just include something that it already knows in a known format.  This
> why an HTTP origin and SIP registrar URI have been chosen.  We just need

What about XMPP (and SIP) clients in browser?

Possibly XEP-0215 (http://xmpp.org/extensions/xep-0215.html) could be 
extended to let the XMPP server specify (or override) that as well. 
WebRTC clients don't have the chance to specify this however.

---

From: Alan Johnston <[email-masked]>
Date: Fri, 1 Aug 2014 12:23:51 -0500

Hi Philipp,

When XMPP or SIP is used for the signaling in WebRTC, the client is running
in JavaScript.  SIP or XMPP in the browser cannot configure or use
STUN/TURN except through the WebRTC APIs.  In this case, the browser origin
would be used, since the browser is running the STUN/TURN client.  Allowing
JavaScript to set the Origin would not be a good idea, and not really
useful either in this context.

- Alan -

On Fri, Aug 1, 2014 at 12:00 PM, Philipp Hancke <[email-masked]>
wrote:

> extended to let the XMPP server specify (or override) that as well. WebRTC
> clients don't have the chance to specify this however.
>

---

From: Alan Johnston <[email-masked]>
Date: Fri, 1 Aug 2014 12:25:06 -0500

Peter,

Thanks for resending this. I like the suggested text and think it would
work well.

- Alan -