Hi,

In the TRAM WG, we are working on a= n extension to STUN/TURN for a client to convey origin information to a ser= ver. =C2=A0

=C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html= /draft-ietf-tram-stun-origin=C2=A0

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

=C2=A0 =C2=A0For a SIP User Agent [RFC3261] using = STUN and TURN, the ORIGIN

=C2=A0 =C2=A0attribute is set to be the= URI of the registrar server used by the

=C2=A0 =C2=A0User Agent = (i.e. the Request-URI of a REGISTER method).

=C2=A0 =C2=A0For a Jabber client [RFC6120] using STUN a= nd TURN, the ORIGIN

=C2=A0 =C2=A0attribute is the Jabber ID (JID)= [RFC6122] of the Jabber Server that

=C2=A0 =C2=A0the client is u= sing.

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

- Alan -

--bcaec53f3985b85c7204ff928307-- From nobody Fri Aug 1 08:12:41 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACB01B27CD for ; Fri, 1 Aug 2014 08:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_MUswRuUBZU for ; Fri, 1 Aug 2014 08:12:37 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [83.98.201.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F6C1A04B7 for ; Fri, 1 Aug 2014 08:12:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 22BD41600E2; Fri, 1 Aug 2014 17:12:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mag.ik.nu Received: from mag.ik.nu ([127.0.0.1]) by localhost (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO795oeNjusg; Fri, 1 Aug 2014 17:12:33 +0200 (CEST) Received: from [10.54.52.79] (unknown [89.205.224.12]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ralphm) by mag.ik.nu (Postfix) with ESMTPSA id C3E621600DE; Fri, 1 Aug 2014 17:12:32 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Ralph Meijer Date: Fri, 01 Aug 2014 17:12:26 +0200 To: Alan Johnston ,xmpp@ietf.org Message-ID: <61e0e855-ed94-4e03-a1e7-018ceae47c97@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/zNBgKdCqr0RzNvVnCCtYvVuT7Oo Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:12:39 -0000 On August 1, 2014 4:50:47 PM CEST, Alan Johnston wrote: > [..] > 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. 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 nobody Fri Aug 1 08:45:26 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32051B2791 for ; Fri, 1 Aug 2014 08:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF2TWueS8h7y for ; Fri, 1 Aug 2014 08:45:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 151871A007A for ; Fri, 1 Aug 2014 08:45:23 -0700 (PDT) Received: from [10.152.18.180] (unknown [166.147.82.143]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5722A4108C; Fri, 1 Aug 2014 09:45:22 -0600 (MDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5FB8442B-4DA6-4324-8864-810E93E90191 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Peter Saint-Andre Date: Fri, 1 Aug 2014 09:45:20 -0600 To: Alan Johnston Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/psprwv9KH6yxUtHNLNLaCP1Uz9o Cc: "xmpp@ietf.org" Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:45:25 -0000 --Apple-Mail-5FB8442B-4DA6-4324-8864-810E93E90191 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Alan, did you receive the email message I sent you on this topic some wee= ks ago? ;-) Sent from mobile, might be terse=20 > On Aug 1, 2014, at 8:50 AM, Alan Johnston wrot= e: >=20 > Hi, >=20 > In the TRAM WG, we are working on an extension to STUN/TURN for a client t= o convey origin information to a server. =20 >=20 > http://tools.ietf.org/html/draft-ietf-tram-stun-origin=20 >=20 > The driver for this effort is WebRTC, where the origin is the HTTP origin o= f the web site that is establishing the Peer Connection. Other users of STU= N and TURN can also provide origin information. The draft currently has thi= s text about SIP and XMPP: >=20 > 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). >=20 > 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. >=20 > We would greatly appreciate feedback from you on what this text should say= about XMPP/Jabber in terms of a useful origin. >=20 > - Alan - > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp --Apple-Mail-5FB8442B-4DA6-4324-8864-810E93E90191 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

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 <alan.b.johnston@gmail.com> 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.

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 -

_______________________________________________
xmpp mailing list
xmpp@ietf.org
https://www.ietf.org/mailman/listinfo/xmpp

--Apple-Mail-5FB8442B-4DA6-4324-8864-810E93E90191-- From nobody Fri Aug 1 09:23:07 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE25C1B27F9 for ; Fri, 1 Aug 2014 09:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML3k88zYak_1 for ; Fri, 1 Aug 2014 09:23:01 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A8C1B27F4 for ; Fri, 1 Aug 2014 09:23:01 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id nu7so2788906obb.9 for ; Fri, 01 Aug 2014 09:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=guOyh2sdeh/F1oXFnf9r0KwFtkNxnUVJorEsonpK35o=; b=ihpn+6GFmblOdd6TpDFt+H3fhl0Z2tWVS+EIV0/vc76e7NXB5dUUFXwvxgAzWKo1K7 jiX0EmEfVd2Sa98+Ysi9oP9/u4dw/cFtIhoIojw+Jasx4dq/DC0tu3eGMTCTCAhLYeJj tQ59XGm70nwLEULWjbMzJ0yQ+L+uscYBrEk1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=guOyh2sdeh/F1oXFnf9r0KwFtkNxnUVJorEsonpK35o=; b=HFd+0I9vmkXKfl8RXfb9vwEEmQE+TSB2ZBHnY71fJsKKexASDzv7JbEwv9+QiiIPDD 7ys4H1wNhGp02DmDnlpmWw1yF0GUtRYdEwMQc4ua3VwZaJqJuyOapIhjV3JEpaVSMvBx vKO3Veq8FpmQjc/ayo8xmG1nPUwhppEnxJlbz9XR7EzvnygFulRP2WSuYO74Gm7MFNQq GxZSz+lesPXzAF3hyDISuucZknHTFN9Ehhj2mJX0pR1q7jbhKL/Pkn0RzxBCcUT9g8yU QcGRjX/V+fUowT+r7dZwJuXVzydlTwei0QtDnsINtdlk7L0BSVyOE4r/3KUyAMJttYsW X6ug== X-Gm-Message-State: ALoCoQmfng5LQJsSiX/pCApEbT41aBMGuKHHoy3BotPnAO+fkUHAPnDes2oaHJBW0oUbB9MpI4nV MIME-Version: 1.0 X-Received: by 10.60.146.198 with SMTP id te6mr9788395oeb.46.1406910180409; Fri, 01 Aug 2014 09:23:00 -0700 (PDT) Received: by 10.60.134.145 with HTTP; Fri, 1 Aug 2014 09:23:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Aug 2014 17:23:00 +0100 Message-ID: From: Dave Cridland To: Alan Johnston Content-Type: multipart/alternative; boundary=047d7b5d30b688d97604ff93cd41 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/fbjB1F9VyZCBe64Vxf-dGrdTb3c Cc: XMPP Working Group Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:23:05 -0000 --047d7b5d30b688d97604ff93cd41 Content-Type: text/plain; charset=UTF-8 You might want to flag this with the standards@xmpp.org list, and/or the jingle@xmpp.org 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 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. > > 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 - > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > > --047d7b5d30b688d97604ff93cd41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You might want to flag this with the standards@xmpp.org list, and/or the jingle@xmpp.org list.

My main comme= nt 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, t= he 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 mos= t use-cases, but a full jid might be more useful in others.

<= /div>

Also, my gut - which my wife says is growing, hence its ability t= o 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 otherwis= e going to imply that a STUN server know how to parse SIP, XMPP, and HTTP U= RIs, and anything else that comes along later.

I've the vaguest notion that given the spread of us= e-cases, you possibly want two attributes - an origin domain and an initiat= or URI.

On 1 August 2014 15:50, Alan Johnston <alan.b.johnston@gmail.com> wrote:

Hi,

In the TRAM WG, we are working on a= n extension to STUN/TURN for a client to convey origin information to a ser= ver. =C2=A0

=C2=A0 =C2=A0 =C2=A0 http://t= ools.ietf.org/html/draft-ietf-tram-stun-origin=C2=A0

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

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

=C2=A0 =C2=A0For a Jabber client [RFC6120] using STUN a= nd TURN, the ORIGIN
=C2=A0 =C2=A0attribute is the Jabber ID (JID)= [RFC6122] of the Jabber Server that
=C2=A0 =C2=A0the client is u= sing.

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
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--047d7b5d30b688d97604ff93cd41-- From nobody Fri Aug 1 09:43:12 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3CF1A0169 for ; Fri, 1 Aug 2014 09:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abeKBqlLp9NB for ; Fri, 1 Aug 2014 09:43:06 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BABC1A012D for ; Fri, 1 Aug 2014 09:43:05 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so1675263wib.5 for ; Fri, 01 Aug 2014 09:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jAv/L7JbXtRmhUoMryMxaS8IrX1dWjNX1UdF0lOrVWs=; b=EreSf+3pFlEHuNe1VfFe9OqxJMmjOeX478rVYT2fwbnd3vVqZ7EKlagFllJEw2n5uy OqIoO37A3k6czFAXSslhNPRNRUYT1krRySSC+lBvz4sPKfe881vEVIWItqFR50Ul7ad+ ESsXIUFYhtebGZhqwdpTeoBUxqPNyqJNj3hV72yEnQXd8gnLkU7OsaCqPxE/atlmbPe9 tkak7PJ/wrR85zIBeMo5WpvfjbC/wjkTz59jtPn7/eFQck88AZGQS9zrL4n7t6Wm6e8v OKAOtIfmwg1aS6cQwOgJoAtyOm6J9SAZNRkdzM5LEEoeimQzhYeP2NRwenWm2pArRg7f p2uQ== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr8286511wiv.65.1406911384226; Fri, 01 Aug 2014 09:43:04 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Fri, 1 Aug 2014 09:43:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Aug 2014 11:43:04 -0500 Message-ID: From: Alan Johnston To: Dave Cridland Content-Type: multipart/alternative; boundary=f46d043c7f0449921604ff9415e9 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/UMxtsglee8HhpPwhIZfK5mCw8fU Cc: XMPP Working Group Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:43:09 -0000 --f46d043c7f0449921604ff9415e9 Content-Type: text/plain; charset=UTF-8 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 wrote: > You might want to flag this with the standards@xmpp.org list, and/or the > jingle@xmpp.org 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 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. >> >> 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 - >> >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp >> >> > --f46d043c7f0449921604ff9415e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dave,

Thanks for the feedback. =C2=A0Th= ere are two main use cases for the extension in multi-domain STUN/TURN serv= ers. =C2=A0One is for logging, and the other is for realm selection. =C2=A0= For the former, the server doesn't need to parse it, just log in. =C2= =A0For 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 an= d have the client just include something that it already knows in a known f= ormat. =C2=A0This why an HTTP origin and SIP registrar URI have been chosen= . =C2=A0We just need an equivalent in XMPP that a domain can be identified/= extracted. =C2=A0STUN already has a USERNAME attribute that can be used for= individual client identification - the goal isn't to replicate that he= re.

- Alan -

On Fri, Aug 1, 2014 at 11:23 AM, Dave Cridland <= span dir=3D"ltr"><dave@cridland.net> wrote:

You might want to flag this= with the standards= @xmpp.org list, and/or the jingle@xmpp.org list.

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

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

<= /div>
Also, my gut - which my wife says is growing, hence its ability t= o 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 otherwis= e going to imply that a STUN server know how to parse SIP, XMPP, and HTTP U= RIs, and anything else that comes along later.

I've the vaguest notion that given the spread of us= e-cases, you possibly want two attributes - an origin domain and an initiat= or URI.

On 1 August 2014 15:50, Alan Johnston <alan.b.johnston@gmail.com> wrote:

Hi,

In the TRAM WG, we are working on a= n extension to STUN/TURN for a client to convey origin information to a ser= ver. =C2=A0

=C2=A0 =C2=A0 =C2=A0 http://t= ools.ietf.org/html/draft-ietf-tram-stun-origin=C2=A0

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

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

=C2=A0 =C2=A0For a Jabber client [RFC6120] using STUN a= nd TURN, the ORIGIN
=C2=A0 =C2=A0attribute is the Jabber ID (JID)= [RFC6122] of the Jabber Server that
=C2=A0 =C2=A0the client is u= sing.

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
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--f46d043c7f0449921604ff9415e9-- From nobody Fri Aug 1 09:49:30 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BD31B2837 for ; Fri, 1 Aug 2014 09:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzI2xs3ATkCp for ; Fri, 1 Aug 2014 09:49:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 075711B282A for ; Fri, 1 Aug 2014 09:49:17 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B5C274108C; Fri, 1 Aug 2014 10:49:15 -0600 (MDT) Message-ID: <53DBC50B.8050906@stpeter.im> Date: Fri, 01 Aug 2014 10:49:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: 'Alan Johnston' References:

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/M-wUY06fzCR85uEWGj3Ql3P7r3E Cc: xmpp@ietf.org Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:49:25 -0000 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: 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. If user's JID is foo@example.com 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 "juliet@im.example.com/balcony" then the ORIGIN attribute would be "xmpp:im.example.com". Peter ### On 8/1/14, 9:45 AM, Peter Saint-Andre wrote: > 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 > 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. >> >> 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 - >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp > > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > From nobody Fri Aug 1 09:55:21 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DB21B2839 for ; Fri, 1 Aug 2014 09:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euJ7DVjuBnzR for ; Fri, 1 Aug 2014 09:55:14 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74B41B282A for ; Fri, 1 Aug 2014 09:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=932; q=dns/txt; s=iport; t=1406912114; x=1408121714; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=FDM9QvoFh6+cAAPc5az09i+Wr9GaDSaynTqyODEfxy4=; b=kehSqDSdAyUa62r1d/9Fl3mT8BhNhgf2UsR5JA6I9e5ALYDEPQ/us7Qk qkYmReaEH71oTFF3bAPmSfrcs6w/G3nrZf6TSVwCM37x5jWBtAuQyjueN wWPGS6X72IEDtZ9/Ifc+4RQj1mLY4wCXwt1+YZQdls183HHeytt7eBlbs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAAvF21OtJA2B/2dsb2JhbABbgw1SVwSCdMkQh25yFneECiMRVwEiAiYCBDAVEgQTiEKic48rl3EXgSyRIIFSBZdAhDqUWoNJbIFF X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="65835291" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP; 01 Aug 2014 16:55:14 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s71GtCIe021530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Aug 2014 16:55:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 11:54:22 -0500 From: "Joe Hildebrand (jhildebr)" To: "xmpp@ietf.org" Thread-Topic: Does 6122bis need to update 5122? Thread-Index: AQHPralbv4SoRfqF80GhK2/Lv139gg== Date: Fri, 1 Aug 2014 16:55:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <932EBB4D2350B849AB82C6B7BE50797B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/JS4dCOJefPCrNzaSr99s4Yjn5W0 Subject: [xmpp] Does 6122bis need to update 5122? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:55:18 -0000 T24gOC8xLzE0LCAxMDo0OSBBTSwgIlBldGVyIFNhaW50LUFuZHJlIiA8c3RwZXRlckBzdHBldGVy LmltPiB3cm90ZToNCg0KPkluIHRoYXQgY2FzZSwgd2UnZCBzcGVjaWZ5IGFuIFhNUFAgVVJJIChS RkMgNTEyMikuDQo+DQo+VGh1cyBJIG1pZ2h0IHN1Z2dlc3Q6DQo+DQo+ICAgIEZvciBhbiBYTVBQ IGNsaWVudCBbUkZDNjEyMF0gdXNpbmcgU1RVTiBhbmQgVFVSTiwgdGhlIE9SSUdJTg0KPiAgICBh dHRyaWJ1dGUgaXMgYW4gWE1QUCBVUkkgW1JGQzUxMjJdIHJlcHJlc2VudGluZyB0aGUgZG9tYWlu cGFydA0KPiAgICBvZiB0aGUgY2xpZW50J3MgSmFiYmVyIElEIChKSUQpIFtSRkM2MTIyXTsgZm9y IGV4YW1wbGUsIGlmIHRoZQ0KPiAgICBjbGllbnQncyBKSUQgaXMgImp1bGlldEBpbS5leGFtcGxl LmNvbS9iYWxjb255IiB0aGVuIHRoZSBPUklHSU4NCj4gICAgYXR0cmlidXRlIHdvdWxkIGJlICJ4 bXBwOmltLmV4YW1wbGUuY29tIi4NCg0KVGhpcyBtYWRlIG1lIHdvbmRlciBpZiB3ZSBuZWVkIHRv IGVpdGhlciByZXYgNTEyMiB0byBwb2ludCB0byA2MTIyYmlzLCBvcg0KanVzdCBoYXZlIDYxMjIg dXBkYXRlIDUxMjIgKHdoaWNoIEkgdGhpbmsgSSdkIHByZWZlciwgc28gd2UgZG9uJ3Qgb3BlbiB1 cA0KYSBjYW4gb2YgSVJJIHdvcm1zKS4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K From nobody Fri Aug 1 10:00:42 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2721B27A3 for ; Fri, 1 Aug 2014 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzusrWGxEWmZ for ; Fri, 1 Aug 2014 10:00:30 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256D81A0051 for ; Fri, 1 Aug 2014 10:00:29 -0700 (PDT) Received: from [192.168.178.45] (p5DCFCBB1.dip0.t-ipconnect.de [93.207.203.177]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s71H0Z1j011189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 1 Aug 2014 19:00:37 +0200 Message-ID: <53DBC79F.3080704@goodadvice.pages.de> Date: Fri, 01 Aug 2014 19:00:15 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: xmpp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/OEYC6uLEr0H4ZFBbUlJ_ue_itPQ Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:00:39 -0000 > 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 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 nobody Fri Aug 1 10:24:10 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EC01B2839 for ; Fri, 1 Aug 2014 10:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZAmm24xzroT for ; Fri, 1 Aug 2014 10:24:03 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E161B2862 for ; Fri, 1 Aug 2014 10:23:53 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so4594877wes.38 for ; Fri, 01 Aug 2014 10:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4o3fE+8ibCtwFFrTfFZIj4yynnu5pB24rcZ6spaF96U=; b=GM2IO/RWKlYzAQiGyby7Hx5DWvJ5yU63EyQ680qRUh8Sz3IGZ8Hm9jxUaqkswa/Huf teXeTaHA5R8EdZlfbPlZAfiFMH+gY9MgCpxpuj/1+NRQedq4abtUu4RW7RoUIEo8bdr9 4o8O6rP5fUZH3XbNe3ZTzdebSQJq+6W/u3VIqg8bmJTLGCLDi4FZwLseycFOVz4wzfRC o94DGKcr94mG+x1pbx61H5VQtNy0CTqdQtexLkgFzjMHgaLU9OkMLv5ehE+33L5LBpFf 9XzHqs9Z9qaEpzfbO8BNatYDRsTy1DZn1hbjivK/+rQBBUBznS8X2e4GXTApM6K0ceKK ed2g== MIME-Version: 1.0 X-Received: by 10.180.20.15 with SMTP id j15mr4528296wie.60.1406913831779; Fri, 01 Aug 2014 10:23:51 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Fri, 1 Aug 2014 10:23:51 -0700 (PDT) In-Reply-To: <53DBC79F.3080704@goodadvice.pages.de> References: <53DBC79F.3080704@goodadvice.pages.de> Date: Fri, 1 Aug 2014 12:23:51 -0500 Message-ID: From: Alan Johnston To: Philipp Hancke Content-Type: multipart/alternative; boundary=bcaec53f39852c438404ff94a71b Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/gOrJ1auiNiJgJhS41h36rBW_wKk Cc: XMPP Working Group Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:24:08 -0000 --bcaec53f39852c438404ff94a71b Content-Type: text/plain; charset=UTF-8 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 wrote: > 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 >> > > 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. > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --bcaec53f39852c438404ff94a71b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Philipp,

When XMPP or SIP is used fo= r the signaling in WebRTC, the client is running in JavaScript. =C2=A0SIP o= r XMPP in the browser cannot configure or use STUN/TURN except through the = WebRTC APIs. =C2=A0In this case, the browser origin would be used, since th= e browser is running the STUN/TURN client. =C2=A0Allowing 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= <fippo@goodadvice.pages.de> wrote:

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. =C2=A0This<= br> why an HTTP origin and SIP registrar URI have been chosen. =C2=A0We just ne= ed

What about XMPP (and SIP) clients in browser?

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

_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--bcaec53f39852c438404ff94a71b-- From nobody Fri Aug 1 10:25:11 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969241B2841 for ; Fri, 1 Aug 2014 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kINKDf5NlWL3 for ; Fri, 1 Aug 2014 10:25:08 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344AF1B2839 for ; Fri, 1 Aug 2014 10:25:08 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so4623248wes.7 for ; Fri, 01 Aug 2014 10:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3woKbSUNqeDsIbN1RjHufWlb+fahMOS7aox5175uCAo=; b=rYeRaQRdIva6c0nNayaUHdjv0Z+BrzJPfbaNrgjJZ4a5Tw3OHP+vtxRdBQp9TL7s8E +z/ostk355IkD1+pK1ZNRU7m/Jy1cAnn35D20eOrqNMOXxnx5+/rflzXHKR7DzrGZcoS k/WQ1GbpkRAR+8LNnwXQ/lKrzANnf2hnnoF7cJLWkbaa81JFaP1tUAbQUWgOwtmeV3l8 O4vwEaoJJ3NF5/IPiZN7/s2UKabwT7yljgr+u/Vh5Jrq55atfo8Aw2h2X5/FER/j+guW cfv0Sf2LAWK8wx1R/kABhBADGHmOOSa3ps+qeqmEc2/VbBf3he7aigpZGcC2p0TJ2Atp GV3w== MIME-Version: 1.0 X-Received: by 10.194.202.231 with SMTP id kl7mr9766339wjc.134.1406913906843; Fri, 01 Aug 2014 10:25:06 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Fri, 1 Aug 2014 10:25:06 -0700 (PDT) In-Reply-To: <53DBC50B.8050906@stpeter.im> References:

<53DBC50B.8050906@stpeter.im> Date: Fri, 1 Aug 2014 12:25:06 -0500 Message-ID: From: Alan Johnston To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=047d7bae4836a5aa8e04ff94abd7 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ROMVG38_hc1M8fPIQRwLsGxn3P0 Cc: XMPP Working Group Subject: Re: [xmpp] Help on XMPP/Jabber Origin for STUN/TURN X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:25:10 -0000 --047d7bae4836a5aa8e04ff94abd7 Content-Type: text/plain; charset=UTF-8 Peter, Thanks for resending this. I like the suggested text and think it would work well. - Alan - On Fri, Aug 1, 2014 at 11:49 AM, Peter Saint-Andre wrote: > 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: > > 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. > > If user's JID is foo@example.com 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 "juliet@im.example.com/balcony" then the ORIGIN > attribute would be "xmpp:im.example.com". > > Peter > > ### > > On 8/1/14, 9:45 AM, Peter Saint-Andre wrote: > >> 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 > > 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. >>> >>> 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 - >>> _______________________________________________ >>> xmpp mailing list >>> xmpp@ietf.org >>> https://www.ietf.org/mailman/listinfo/xmpp >>> >> >> >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp >> >> > --047d7bae4836a5aa8e04ff94abd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Peter,

Thanks for resending this. I lik= e the suggested text and think it would work well.

- Alan -

On Fri, Aug 1, 2014 at 11:49 AM, Peter Saint-Andre <= stpeter@stpeter.im<= /a>> wrote:

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&qu= ot;.

This might be ambiguous:

=C2=A0 =C2=A0For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN<= br> =C2=A0 =C2=A0attribute is the Jabber ID (JID) [RFC6122] of the Jabber Serve= r that
=C2=A0 =C2=A0the client is using.

If user's JID is f= oo@example.com 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:

=C2=A0 =C2=A0Other contexts can define a usage of the ORIGIN attribute to u= se an
=C2=A0 =C2=A0appropriate URI or URL.

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

Thus I might suggest:

=C2=A0 =C2=A0For an XMPP client [RFC6120] using STUN and TURN, the ORIGIN =C2=A0 =C2=A0attribute is an XMPP URI [RFC5122] representing the domainpart=
=C2=A0 =C2=A0of the client's Jabber ID (JID) [RFC6122]; for example, if= the
=C2=A0 =C2=A0client's JID is "juliet@im.example.com/balcony&quo= t; then the ORIGIN
=C2=A0 =C2=A0attribute would be "xmpp:im.example.com".

Peter

###

On 8/1/14, 9:45 AM, Peter Saint-Andre wrote:

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 <alan.b.johnston@gmail.com
<mailto:a= lan.b.johnston@gmail.com>> 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.

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.
=C2=A0Other users of STUN and TURN can also provide origin information.
=C2=A0The draft currently has this text about SIP and XMPP:

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

=C2=A0 =C2=A0For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN<= br> =C2=A0 =C2=A0attribute is the Jabber ID (JID) [RFC6122] of the Jabber Serve= r that
=C2=A0 =C2=A0the 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 -
_______________________________________________
xmpp mailing list
xmpp@ietf.org <ma= ilto:xmpp@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/xmpp

_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--047d7bae4836a5aa8e04ff94abd7-- From nobody Fri Aug 8 13:27:23 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8319F1A033A for ; Fri, 8 Aug 2014 13:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r8uHfK1X_fO for ; Fri, 8 Aug 2014 13:27:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7D71A0109 for ; Fri, 8 Aug 2014 13:27:20 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s78KRBOc006758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 15:27:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Fri, 8 Aug 2014 15:27:10 -0500 X-Mao-Original-Outgoing-Id: 429222430.835474-b9d863c7170c9bda4bfdfff854a464c8 Content-Transfer-Encoding: quoted-printable Message-Id: <113FD63D-AD0F-4123-996F-659E75DCB494@nostrum.com> References: To: Joe Hildebrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/P6mBH62W7LVadkb4cX0cEGAyn4Y Cc: "xmpp@ietf.org" Subject: Re: [xmpp] Does 6122bis need to update 5122? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:27:21 -0000 Did Peter's comments go to the list? I did not see the original. One = comment below: On Aug 1, 2014, at 11:55 AM, Joe Hildebrand (jhildebr) = wrote: > On 8/1/14, 10:49 AM, "Peter Saint-Andre" wrote: >=20 >> In that case, we'd specify an XMPP URI (RFC 5122). >>=20 >> Thus I might suggest: >>=20 >> 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 "juliet@im.example.com/balcony" then the ORIGIN >> attribute would be "xmpp:im.example.com". >=20 > This made me wonder if we need to either rev 5122 to point to 6122bis, = or > just have 6122 update 5122 (which I think I'd prefer, so we don't open = up > a can of IRI worms). If we need to do one or the other, I would also lean towards updating = 5122 in 6122bis. Reving 5122 just for this seems like overkill. From nobody Fri Aug 8 13:34:01 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9020D1A011E for ; Fri, 8 Aug 2014 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzRClxfVwM1W for ; Fri, 8 Aug 2014 13:33:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1142E1A0109 for ; Fri, 8 Aug 2014 13:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1626; q=dns/txt; s=iport; t=1407530040; x=1408739640; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HyBJM1mQUu6DDV8MAT3g6H0OUNiCTgA0NyPBZ+VaF5c=; b=N1EN1K5csw4Uau00Eq8MY0JzC0feQeKL1ROwW/KmIIQG3Qqgilnq/OB8 yFTpwpUgLOOUW1DDMFbxyCC4arMGu4L0sAebmcL9ShM2hFXTF7V6z+JFQ fkuMk7LTu4fCykdsvuAQPskVKt46GdxUaDkhPvLt55v1dA0tvhl0MaK5D g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAJEz5VOtJA2M/2dsb2JhbABagw1SVwSCc8lxh1ABGXwWd4QEAQEEIxFFEAIBCBgCAiYCAgIwFRACBA4FiEKwD5V0F4EsjW0zB4J5NoEcAQSRFoQlgimERZR4g1dsgUc X-IronPort-AV: E=Sophos;i="5.01,827,1400025600"; d="scan'208";a="346122777" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 08 Aug 2014 20:33:59 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s78KXvbk031431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 20:33:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 15:33:57 -0500 From: "Joe Hildebrand (jhildebr)" To: Ben Campbell Thread-Topic: [xmpp] Does 6122bis need to update 5122? Thread-Index: AQHPs0co9A4QIM2xjE6SXLkj8OUMGJvHGNOA Date: Fri, 8 Aug 2014 20:33:56 +0000 Message-ID: <86DC3122-80F9-433F-85BA-B3479E8FBC0A@cisco.com> References: <113FD63D-AD0F-4123-996F-659E75DCB494@nostrum.com> In-Reply-To: <113FD63D-AD0F-4123-996F-659E75DCB494@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140730 x-originating-ip: [10.21.98.195] Content-Type: text/plain; charset="utf-8" Content-ID: <3EC63FEBFDF9C8479AE0AD3573BDC094@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/qk58F6OC395r3l07LWUF85Y6r-M Cc: "xmpp@ietf.org" Subject: Re: [xmpp] Does 6122bis need to update 5122? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:33:59 -0000 SSBkb24ndCB0aGluayBJJ3ZlIHNlZW4gaXQgb24gdGhlIGxpc3QuDQoNCkRNQVJDIHByb2JsZW0/ DQoNCk9uIDgvOC8xNCwgODoyNyBQTSwgIkJlbiBDYW1wYmVsbCIgPGJlbkBub3N0cnVtLmNvbT4g d3JvdGU6DQoNCj5EaWQgUGV0ZXIncyBjb21tZW50cyBnbyB0byB0aGUgbGlzdD8gSSBkaWQgbm90 IHNlZSB0aGUgb3JpZ2luYWwuIE9uZSANCj5jb21tZW50IGJlbG93Og0KPg0KPg0KPk9uIEF1ZyAx LCAyMDE0LCBhdCAxMTo1NSBBTSwgSm9lIEhpbGRlYnJhbmQgKGpoaWxkZWJyKSANCj48amhpbGRl YnJAY2lzY28uY29tPiB3cm90ZToNCj4NCj4+IE9uIDgvMS8xNCwgMTA6NDkgQU0sICJQZXRlciBT YWludC1BbmRyZSIgPHN0cGV0ZXJAc3RwZXRlci5pbT4gd3JvdGU6DQo+PiANCj4+PiBJbiB0aGF0 IGNhc2UsIHdlJ2Qgc3BlY2lmeSBhbiBYTVBQIFVSSSAoUkZDIDUxMjIpLg0KPj4+IA0KPj4+IFRo dXMgSSBtaWdodCBzdWdnZXN0Og0KPj4+IA0KPj4+ICAgRm9yIGFuIFhNUFAgY2xpZW50IFtSRkM2 MTIwXSB1c2luZyBTVFVOIGFuZCBUVVJOLCB0aGUgT1JJR0lODQo+Pj4gICBhdHRyaWJ1dGUgaXMg YW4gWE1QUCBVUkkgW1JGQzUxMjJdIHJlcHJlc2VudGluZyB0aGUgZG9tYWlucGFydA0KPj4+ICAg b2YgdGhlIGNsaWVudCdzIEphYmJlciBJRCAoSklEKSBbUkZDNjEyMl07IGZvciBleGFtcGxlLCBp ZiB0aGUNCj4+PiAgIGNsaWVudCdzIEpJRCBpcyAianVsaWV0QGltLmV4YW1wbGUuY29tL2JhbGNv bnkiIHRoZW4gdGhlIE9SSUdJTg0KPj4+ICAgYXR0cmlidXRlIHdvdWxkIGJlICJ4bXBwOmltLmV4 YW1wbGUuY29tIi4NCj4+IA0KPj4gVGhpcyBtYWRlIG1lIHdvbmRlciBpZiB3ZSBuZWVkIHRvIGVp dGhlciByZXYgNTEyMiB0byBwb2ludCB0byA2MTIyYmlzLCANCj4+b3INCj4+IGp1c3QgaGF2ZSA2 MTIyIHVwZGF0ZSA1MTIyICh3aGljaCBJIHRoaW5rIEknZCBwcmVmZXIsIHNvIHdlIGRvbid0IG9w ZW4gDQo+PnVwDQo+PiBhIGNhbiBvZiBJUkkgd29ybXMpLg0KPg0KPklmIHdlIG5lZWQgdG8gZG8g b25lIG9yIHRoZSBvdGhlciwgSSB3b3VsZCBhbHNvIGxlYW4gdG93YXJkcyB1cGRhdGluZyANCj41 MTIyIGluIDYxMjJiaXMuIFJldmluZyA1MTIyIGp1c3QgZm9yIHRoaXMgc2VlbXMgbGlrZSBvdmVy a2lsbC4NCj4NCj4NCj4NCg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Mon Aug 11 16:09:33 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD41A0728; Mon, 11 Aug 2014 16:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI7r95Tcc0hc; Mon, 11 Aug 2014 16:09:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E37641A01EF; Mon, 11 Aug 2014 16:09:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811230928.1644.15019.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 16:09:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/zvTQ5rZscts4jnlOKFy8Ynya-Fg Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-websocket-09.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:09:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : An XMPP Sub-protocol for WebSocket Authors : Lance Stout Jack Moffitt Eric Cestari Filename : draft-ietf-xmpp-websocket-09.txt Pages : 16 Date : 2014-08-11 Abstract: This document defines a binding for the XMPP protocol over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-websocket-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 13 13:55:24 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC25A1A0087 for ; Wed, 13 Aug 2014 13:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4b59pxTYEwP for ; Wed, 13 Aug 2014 13:55:20 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF83B1A0099 for ; Wed, 13 Aug 2014 13:55:19 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:f2de:f1ff:fe16:509b]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7DKtEnj000795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 13 Aug 2014 22:55:15 +0200 X-Hashcash: 1:22:140813:xmpp@ietf.org::nIpL5uq+P8c/gLXQ:2gPm From: Simon Josefsson To: xmpp@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Wed, 13 Aug 2014 22:55:13 +0200 Message-ID: <87egwkw1n2.fsf@latte.josefsson.org> User-Agent: Gnus/5.130011 (Ma Gnus v0.11) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/oNHxm-lf0TJlEuVadSolRoQ3js8 Subject: [xmpp] RFC 6120 CA cert keyUsage digitalSignature bit requirement? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 20:55:22 -0000 Hi, I'm generating certificates for use in a XMPP environment, and I'm seeking clarification of one aspect of RFC 6120: The following rules apply to certification authority (CA) certificates that are used by issuers of XMPP end entity certificates: ... 2. The certificate MUST contain a keyUsage extension with the digitalSignature bit set. My question: Why is the digitalSignature bit a requirement? Speculation: Was the keyCertSign bit intended here? Reading RFC 5280 it seems the keyCertSign would be more appropriate than digitalSignature. What non-certificate/CRL objects is it that XMPP environments expect to be signed by the CA? KeyUsage ::= BIT STRING { digitalSignature (0), ... keyCertSign (5), ... The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), such as those used in an entity authentication service, a data origin authentication service, and/or an integrity service. ... The keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted. ... If the keyUsage extension is present, then the subject public key MUST NOT be used to verify signatures on certificates or CRLs unless the corresponding keyCertSign or cRLSign bit is set. If the subject public key is only to be used for verifying signatures on certificates and/or CRLs, then the digitalSignature and nonRepudiation bits SHOULD NOT be set. However, the digitalSignature and/or nonRepudiation bits MAY be set in addition to the keyCertSign and/or cRLSign bits if the subject public key is to be used to verify signatures on certificates and/or CRLs as well as other objects. Thanks, /Simon From nobody Fri Aug 29 10:30:06 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33311A068F for ; Fri, 29 Aug 2014 10:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q0S0NTuqyJu for ; Fri, 29 Aug 2014 10:30:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 52E641A068B for ; Fri, 29 Aug 2014 10:30:04 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A19541237; Fri, 29 Aug 2014 11:30:49 -0600 (MDT) Message-ID: <54009ECE.1050603@stpeter.im> Date: Fri, 29 Aug 2014 09:39:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , Joe Hildebrand References: <113FD63D-AD0F-4123-996F-659E75DCB494@nostrum.com> In-Reply-To: <113FD63D-AD0F-4123-996F-659E75DCB494@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/WBxiRAtw74gju6NZZD39De_GLDo Cc: "xmpp@ietf.org" Subject: Re: [xmpp] Does 6122bis need to update 5122? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:30:05 -0000 On 8/8/14, 2:27 PM, Ben Campbell wrote: > Did Peter's comments go to the list? I did not see the original. I never replied in this thread. :-) > One comment below: > > > On Aug 1, 2014, at 11:55 AM, Joe Hildebrand (jhildebr) > wrote: > >> On 8/1/14, 10:49 AM, "Peter Saint-Andre" >> wrote: >> >>> 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 "juliet@im.example.com/balcony" then the ORIGIN >>> attribute would be "xmpp:im.example.com". >> >> This made me wonder if we need to either rev 5122 to point to >> 6122bis, or just have 6122 update 5122 (which I think I'd prefer, >> so we don't open up a can of IRI worms). I see this chain: 5122 normatively references 3920 6120 obsoletes 3920 6120 normatively references 6122 6122bis obsoletes 6122 So by following the chain, a reader of 5122 can discover that 6122bis is the most up-to-date definition of the address format. > If we need to do one or the other, I would also lean towards updating > 5122 in 6122bis. Reving 5122 just for this seems like overkill. Agreed. Peter From nobody Fri Aug 29 10:30:09 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF91A06A3; Fri, 29 Aug 2014 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ8fkq0vxtrz; Fri, 29 Aug 2014 10:30:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C95121A068D; Fri, 29 Aug 2014 10:30:04 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D20A241278; Fri, 29 Aug 2014 11:30:50 -0600 (MDT) Message-ID: <5400B894.8050007@stpeter.im> Date: Fri, 29 Aug 2014 11:29:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "xmpp@ietf.org" , "precis@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/zmYJLlFs3qakFr9gGmAAtYvb_8A Subject: Re: [xmpp] review of draft-ietf-xmpp-6122bis-12 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:30:08 -0000 Hi Joe, thanks for the review and my apologies for taking a month to reply. On 7/30/14, 3:25 PM, Joe Hildebrand (jhildebr) wrote: > The reasons the precis group got a spate of questions from me today was I > was prepping to do this review. There are a couple of issues that the > precis folk should pay more attention to. > > > 1. Introduction > ... > > > Instead, this document builds upon the > > internationalization framework defined by the IETF's PRECIS Working > > Group [I-D.ietf-precis-framework], while attempting to ensure that > > the characters allowed in Jabber IDs under stringprep are still > > allowed and handled in the same way under PRECIS. > > "the same way" means more backward-compatibility to me than I think we > intend here. Yes, that is a bit vague, even though it does say "attempting". Here is one possible approach... OLD Instead, this document builds upon the internationalization framework defined by the IETF's PRECIS Working Group [I-D.ietf-precis-framework], while attempting to ensure that the characters allowed in Jabber IDs under stringprep are still allowed and handled in the same way under PRECIS. NEW Instead, this document builds upon the internationalization framework defined by the IETF's PRECIS Working Group [I-D.ietf-precis-framework]. Although every attempt has been made to ensure that the characters allowed in Jabber IDs under stringprep are still allowed and handled in the same way under PRECIS, there is no guarantee of strict backward compatibility because of changes in Unicode and the fact that PRECIS handling is based on Unicode properties, not a hardcoded table of characters. > > 3.1. Fundamentals > > > > jid = [ localpart "@" ] domainpart [ "/" resourcepart ] > > localpart = 1*1023(localpoint) > > ; > > ; a "localpoint" is a UTF-8 encoded > > ; Unicode code point that conforms to > > ; the "JIDlocalIdentifierClass" profile > > ; of the PRECIS IdentifierClass > > ; > > This implies 1023 codepoints, not 1023 bytes to me. Same issue for ifqdn > and resourcepart. 6122 just had 1*; I think going back to that would be > fine since we have a rule below that captures the max size. Your proposal seems fine to me, too. It's hard to capture these nuances in ABNF, at times. Although, from later in the thread, "localbyte" would work for me. > > 3.2. Domainpart > > > > The domainpart of a JID is that portion after the '@' character (if > > any) and before the '/' character (if any); it is the primary > > I think it's often surprising to people that foo/@bar is a valid JID with > "foo" as the domainpart and "@bar" as the resourcepart. The text above, > although pulled from 6122, might be better as: > > The domainpart of a JID is that portion after the first '@' character (if > any) and before the first '/' character (if any); That's acceptable to me. > and possibly adding the example. Examples are good. I'll add a few to Table 1. > > In general, the content of a domainpart is an Internationalized > > Domain Name ("IDN") as described in the specifications for > > Internationalized Domain Names in Applications (commonly called > > "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as > > defined in [RFC5890]. The following rules apply to a domainpart that > > consists of a fully-qualified domain name and MUST be applied in the > > following order: > > When do these rules need to be applied? Only before comparison or routing? That is a very good question. This might be a difference between the "preparation" and "comparison" of the PRECIS acronym. You'll notice that the PRECIS nickname spec draws a sharper distinction between preparation and comparison than the others: http://www.ietf.org/archive/id/draft-ietf-precis-nickname-09.txt Section 2 there says in part: For preparation purposes (most commonly, when a chatroom client generates a nickname from user input for inclusion as a protocol element that represents a "nickname slot"), an application MUST at a minimum ensure that the string conforms to the "FreeformClass" string class defined in [I-D.ietf-precis-framework]; however, it MAY in addition perform the normalization and mapping operations specified below for comparison purposes. For comparison purposes (e.g., when a chatroom server determines if two nicknames are in conflict during the authorization process), an application MUST treat a nickname as specified below (these rules constitute the "NicknameFreeformClass" profile). The operations specified MUST be completed in the order shown (in particular, normalization MUST be performed after the other mapping steps and before validity-checking against the definition of the PRECIS "FreeformClass", consistent with [I-D.ietf-precis-framework]). [various rules elided] I wonder if we want to say, in general, that there is something of a lower bar for preparation than for comparison. For example, for an XMPP localpart we might say that an entity doing preparation just needs to ensure that it doesn't include any characters outside of the PRECIS IdentifierClass, whereas an entity doing comparison needs to apply the normalization and mapping rules. The primary reason we might do this is that it could ease the burden on XMPP clients or servers during certain operations, whereas at those times when comparison is truly needed (e.g., when user authentication or authorization are being made) the full set of rules would be applied. Although I'm not entirely comfortable with this approach, pragmatically it might be more acceptable than saying that all entities must apply all of the rules all of the time. This is related to text in Section 4: Enforcement of the XMPP address format rules is the responsibility of XMPP servers. Although XMPP clients SHOULD prepare complete JIDs and parts of JIDs in accordance with this document before including them in protocol slots within XML streams (such that JIDs and parts of JIDs are in conformance), XMPP servers MUST enforce the rules wherever possible and reject stanzas and other XML elements that violate the rules (for stanzas, by returning a error to the sender as described in Section 8.3.3.8 of [RFC6120]). That text seems to imply the same principle: clients prepare and servers enforce (by mean of comparison?). But I think we could be clearer about the whole matter by explicitly saying that enforcement includes application of all the rules (just as comparison does - it's just that comparison involves applying all of the rules to two strings in order to determine if they are "equivalent", whereas enforcement involves apply the rules to a single string). > > 1. The domainpart MUST contain only NR-LDH labels and U-labels as > > defined in [RFC5890] and MUST consist only of Unicode code points > > that conform to the rules specified in [RFC5892] (which includes > > Unicode normalization). This implies that the domainpart MUST > > NOT include A-labels as defined in [RFC5890]; each A-label MUST > > be converted to a U-label during preparation of a domainpart, and > > comparison MUST be performed using U-labels, not A-labels. > > This seems like an always rule, including for dumb clients. Things are a bit more clear-cut with regard to rules that are based on PRECIS, not IDNA, because the models are slightly different. In PRECIS we have base string classes (IdentifierClass and FreeformClass), so it might make sense to say that preparation involves ensuring that the preparing entity doesn't allow in any code points that are disallowed for that base string class. We don't have base string classes in IDNA. Although the foregoing rule is similar to the base string class idea, it goes beyond by including normalization. I'd almost prefer that we figure this out very clearly first for PRECIS-based identifiers (in XMPP, the localpart and resourcepart) and then see how the resulting text can be ported over to our use of IDNA-based identifiers (in XMPP, the domainpart). > > 2. All uppercase and titlecase code points within the domainpart > > MUST be mapped to their lowercase equivalents, preferably using > > Unicode Default Case Folding as defined in Chapter 3 of the > > Unicode Standard [UNICODE]. > > Dumb clients might get away with this and the system would still work. > > > 3. Fullwidth and halfwidth characters within the domainpart MUST be > > mapped to their decomposition mappings. > > Dumb clients have no shot at this one. Right - in the emerging approach we're exploring here, the latter two rules would be a matter of enforcement and comparison only, not of preparation. > > Implementation Note: The foregoing order is different from the > > order for localparts and resourceparts as described below, to > > maintain consistency with the IDNA methods in both [RFC5892] and > > [RFC5895]. > > > > After any and all normalization, conversion, and mapping of code > > points, > > as well as conversion to UTF-8. True, although we kind of assume that in the XMPP world because all data sent over an XMPP stream is required to be UTF-8. Mentioning it seems useful, though. > > a domainpart MUST NOT be zero octets in length and MUST NOT > > be more than 1023 octets in length. (Naturally, the length limits of > > [RFC1034] apply, and nothing in this document is to be interpreted as > > overriding those more fundamental limits.) > > > > 3.3. Localpart > > > > The localpart of a JID is an optional identifier placed before the > > domainpart and separated from the latter by the '@' character. > > Typically a localpart uniquely identifies the entity requesting and > > using network access provided by a server (i.e., a local account), > > although it can also represent other kinds of entities (e.g., a chat > > room associated with a multi-user chat service [XEP-0045]). The > > entity represented by an XMPP localpart is addressed within the > > context of a specific domain (i.e., ). > > > > A localpart MUST NOT be zero octets in length and MUST NOT be more > > than 1023 octets in length. This rule is to be enforced after any > > normalization and mapping of code points. > > and conversion to UTF-8. As above. > > A localpart MUST consist only of Unicode code points that conform to > > the "JIDlocalIdentifierClass" profile of the "IdentifierClass" base > > string class defined in [I-D.ietf-precis-framework]. The > > JIDlocalIdentifierClass profile includes all code points allowed by > > the IdentifierClass base class, with the exception of the following > > characters that are explicitly disallowed in XMPP localparts: > > (special precis focus) > I would have expected this to be phrased more similarly to step 2 of > http://tools.ietf.org/html/draft-ietf-precis-framework-17#section-5, or > for section 5 to just have a step about codepoints forbidden in a given > usage of the selected precis class. Good point - I agree that more internal harmony would be helpful here between the framework and the various profiles. > > The normalization and mapping rules for the JIDlocalIdentifierClass > > are as follows, where the operations specified MUST be completed in > > the order shown: > > Again, I think we need language about when these rules are applied. The > rest of the section is about what is allowed, not about how to compare. As discussed above, I think we need to more clearly delineate what's required for preparation, what's required for enforcement, and what's required for comparison. And as mentioned seems to me right now that the same rules are involved in enforcement and comparison, except that applying those rules during enforcement is a way to determine if a single string conforms, whereas applying those rules during comparison is a way to determine if two strings are "equivalent". That said, your use of the phrase "about what is allowed, not about how to compare" might suggest that more is involved in comparison than in enforcement. To choose a simple example, is the JID "allowed" if the jabber.org server enforces all the rules for a localpart? It seems to me not. We're saying that a client could send that (since both "S" and "P" are allowed by the category "Lu - Uppercase_Letter" and thus would pass the preparation test), but that a server which is enforcing the rules would map "S" to "s" and "P" to "p". However, the rules for comparison are the same as for enforcement: "StPeter" and "stpeter" would compare as equivalent. > > 1. Fullwidth and halfwidth characters MUST be mapped to their > > decomposition mappings. > > > > 2. Uppercase and titlecase characters MUST be mapped to their > > lowercase equivalents, preferably using Unicode Default Case > > Folding as defined in Chapter 3 of the Unicode Standard > > [UNICODE]. > > Nothing about SpecialCasing? That's a question for the WG. :-) The PRECIS framework states: If case mapping is desired (instead of case preservation), it is RECOMMENDED to use Unicode Default Case Folding as defined in Chapter 3 of the Unicode Standard [Unicode6.3]. Note: Unicode Default Case Folding is not designed to handle various localization issues (such as so-called "dotless i" in several Turkic languages). The PRECIS mappings document [I-D.ietf-precis-mappings] describes these issues in greater detail and defines a "local case mapping" method that handles some locale-dependent and context-dependent mappings. Given the discussions in recent PRECIS WG meetings, I would shy away from applying locale-dependent and context-dependent mappings in XMPP localparts. However, I'm open to argument. > > A resourcepart MUST NOT be zero octets in length and MUST NOT be more > > than 1023 octets in length. This rule is to be enforced after any > > normalization and mapping of code points. > > > > A resourcepart MUST consist only of Unicode code points that conform > > to the "JIDresourceFreeformClass" profile of the "FreeformClass" base > > string class defined in [I-D.ietf-precis-framework]. > > > > The normalization and mapping rules for the resourcepart of a JID are > > as follows, where the operations specified MUST be completed in the > > order shown: > > Again, when are the rules applied? See above. > > 1. Fullwidth and halfwidth characters MAY be mapped to their > > decomposition mappings. > > (precis) > I need a hint as to when do this. "MAY" isn't nearly enough. Do you mean "when" as "in what contexts is it smart to do width mapping on resourceparts" or as something else (e.g., "when" could mean "by which entities" such as clients, servers, and XMPP "components"). Later in this thread, you and Florian Zeitz seem to think that MUST NOT perform width mapping is the right approach. However, resourceparts are used in multiple contexts (we could say that there are multiple "resourcepart slots"). For the JIDs of connected resources (user@domain/foo), I tend to agree. For the JIDs of chatroom participants, the precis-nickname spec says to use NFKC, which handles width mapping as part of normalization (and thus might be taken to violate the proposed MUST NOT approach). I haven't yet taken the time to find and think about other resourcepart slots in various XMPP extensions, but I hesitate to make a categorical statement in 6122bis since the applicability of width mapping might depend on the context in which a resourcepart is used. > > 2. Map any instances of non-ASCII space to ASCII space (U+0020). > > (precis) > I was hoping either the framework doc or the mappings doc would tell me > more about which characters to map here. RFC 3454 had table C.1.2, but I > don't see any hints about what I'm supposed to do now. Good catch. > Is the rule "has a > compatibility mapping to U+0020"? BTW I count at least three kinds of compatibility mapping to 0020: (as in U+0384 GREEK TONOS), (as in U+2007 FIGURE SPACE)), and (as in U+3000 IDEOGRAPHIC SPACE). > That doesn't hit U+200B which is in > C.1.2, Right. I am not sure whether ZERO WIDTH SPACE really ought to be mapped to U+0020. See Florian's comment later in this thread. > nor does "has category Zs". IMHO that is insufficient. My intuition is that by "non-ASCII space" we mean anything that has a compatibility mapping of any kind of U-0020, since that seems safest (it casts a wider net) and is something we can apply in a programmatic way. However, my intuitions are not always correct and applying this rule this would result in a larger table than what we find in Appendix C.1.2 of RFC 3454. > draft-ietf-precis-mappings says > "Therefore, the special mapping table should be based on a well- > defined mapping table for each protocol", which although I don't > particularly like, I can live with - but we need the table here. Do you feel that we need the table in 6122bis or in the framework? As you say, the mappings document implies that each specification that defines a rule like "map non-ASCII space to ASCII space" needs to define their own table, but that seems like a recipe for trouble. If, say, SASL and XMPP and LDAP each defines a different table, authentication might become confusing (especially since XMPP uses SASL and authentication might be based on an LDAP lookup). > > 3. So-called additional mappings MAY be applied, such as mapping of > > characters that are similar to common delimiters (such as '@', > > ':', '/', '+', '-', and '.', e.g., mapping of IDEOGRAPHIC FULL > > STOP (U+3002) to FULL STOP (U+002E)) and special handling of > > certain characters or classes of characters (e.g., mapping of > > non-ASCII spaces to ASCII space); the PRECIS mappings document > > [I-D.ietf-precis-mappings] describes such mappings in more > > detail. > > > > 4. Uppercase and titlecase characters MAY be mapped to their > > lowercase equivalents, preferably using Unicode Default Case > > Folding as defined in Chapter 3 of the Unicode Standard > > [UNICODE]. > > Again, I need more about the MAY here. > > > 6. IANA Considerations > > > > The following completed templates provide the information necessary > > for the IANA to add 'JIDlocalIdentifierClass' and > > 'JIDresourceFreeformClass' to the PRECIS Profiles Registry. > > Should we also ask them to mark the status of nodeprep and resourceprep to > deprecated in the stringprep profiles registry? Yes. > > Appendix A. Differences from RFC 6122 > > > > Based on consensus derived from working group discussion, > > implementation and deployment experience, and formal interoperability > > testing, the following substantive modifications were made from RFC > > 6122. > > I think it might be nice to point out that this may have made > previously-valid JIDs no longer valid (or vice-versa), and that we suggest > careful testing before migrating user data. +1 to at least that text. Ideally we'd perform the kind of analysis that Takahiro Nemoto performed for SASLprep vs. SASLprepbis: http://www.ietf.org/mail-archive/web/precis/current/msg00790.html I haven't done that yet, though. Thanks again to you and Florian for your careful reviews. Peter From nobody Fri Aug 29 11:08:49 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DC31A078D; Fri, 29 Aug 2014 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXe93xhAaVJl; Fri, 29 Aug 2014 11:08:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 899EC1A0739; Fri, 29 Aug 2014 11:08:38 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 760F541237; Fri, 29 Aug 2014 12:09:24 -0600 (MDT) Message-ID: <5400C1A6.6030204@stpeter.im> Date: Fri, 29 Aug 2014 12:08:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "xmpp@ietf.org" , "precis@ietf.org" References: <5400B894.8050007@stpeter.im> In-Reply-To: <5400B894.8050007@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/56Br1k2j9uKX-2zniFmC9ZAhFf0 Subject: Re: [xmpp] review of draft-ietf-xmpp-6122bis-12 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:08:40 -0000 On 8/29/14, 11:29 AM, Peter Saint-Andre wrote: > > On 7/30/14, 3:25 PM, Joe Hildebrand (jhildebr) wrote: >> > 6. IANA Considerations >> > >> > The following completed templates provide the information >> necessary >> > for the IANA to add 'JIDlocalIdentifierClass' and >> > 'JIDresourceFreeformClass' to the PRECIS Profiles Registry. >> >> Should we also ask them to mark the status of nodeprep and >> resourceprep to >> deprecated in the stringprep profiles registry? > > Yes. RFC 3454 never considered that profiles would be marked as deprecated: IANA has set up a registry of stringprep profiles. This registry is a single text file that lists the known profiles. Each entry in the registry has three fields: - Profile name - RFC in which the profile is defined - Indicator whether or not this is the newest version of the profile Each version of a profile will remain listed in the registry forever. That is, if a new version of a profile supersedes an earlier version, both versions will continue to be listed in the registry, but the current version indicator will be turned off for the earlier version and turned on for the newer version. Thus we might want to consult with IANA, the authors of RFC 3454, and the relevant Area Directors about how they would like to proceed. Peter