From stpeter@stpeter.im  Mon Oct  7 15:56:09 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF8F11E8183 for <xmpp@ietfa.amsl.com>; Mon,  7 Oct 2013 15:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzLH43bChDQX for <xmpp@ietfa.amsl.com>; Mon,  7 Oct 2013 15:56:05 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2205111E8182 for <xmpp@ietf.org>; Mon,  7 Oct 2013 15:56:05 -0700 (PDT)
Received: from sjc-vpn3-515.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 83D41414C7; Mon,  7 Oct 2013 17:01:57 -0600 (MDT)
Message-ID: <52533BF7.2040607@stpeter.im>
Date: Mon, 07 Oct 2013 16:55:51 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: XMPP <xmpp@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [xmpp] small comments on draft-ietf-xmpp-websocket
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 22:56:09 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are a few small comments on draft-ietf-xmpp-websocket...

Section 2 says:

   XMPP also has a concept of messages, which
   are stanzas whose top-level element name is message.

To prevent confusion, I suggest:

   XMPP also has a concept of messages, which
   are stanzas whose top-level element name is <message/>.

Section 3.9 says:

   Because TLS is to be provided outside of the XMPP sub-protocol layer,
   a server MUST NOT advertise TLS as a stream feature (see Section 4.6
   of [RFC6120]), and a client MUST ignore any advertised TLS stream
   feature, when using the XMPP sub-protocol.

In cases where the WebSocket connection is served by an intermediary
connection manager, will the XMPP server necessarily know that the
client is connecting via WebSocket instead of BOSH or TCP? If so, we
might need to adjust that text slightly.

Section 4 mentions a connection method name of
"_xmpp-client-websocket" but that has not yet been added to the XMPP
registry:

http://xmpp.org/registrar/alt-connections.html

I'll make sure to ping the XMPP Registrar about that. ;-)

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSUzv3AAoJEOoGpJErxa2pO/sP/ihr9BxlZ9lo+Gz8szuRPeTe
JLeZDbDN0xiq0J3XUA3RQ7aJu/ga5ArbZK/xpMoqjhfX4UWe+86FgfPfRttEcGMM
j+PZs0jSxRLCO7YDG4Yt33Jvc7LfHyi5rqoj9sqdau8RF7wbu9gf+1M3rHrhGLaY
WWdcSZhtuMuuF5gzqqAz9/LV346mpgPKNJ9x9mxb1YCyBhZAxuEC88FaGF8+Rt9d
8jAQp/XhkkyUdgtHvrXxyfCW90CjjGjfEch66KucgBLXCo6hOS1zBCTCcLO5fuT0
S2ux+sY9r1MNuD3dVR/Cpf/M5RvIcwnuRmg0YiYWeHTVub9wzBtIOJUSecFlJC9l
Y3j0neN1cT+TfN7DnSF13mtPoYuxpM3F6AzP0PZQ4AMfXXrJV8XGEY98cEOX8Apz
ary7EJnYyH9EiI4zK2CsSq2DTjpqE7KwvwUt7ZFBIInfBg9zvN9q6k/2NscR035d
UtFV0sp5Y+6ws5HWLFT7cmcvJByWQ3H0rN6EtKLrOBPdgiJz2ALQZSQy05G+bQiD
RJSfmjOFRijsPlVtQN9GCeOOBdw82Z8VCLnKRKLW5yTIV6k1PwJRmIWCvI8QGzQS
pQ2gXKTozuHTQZnQOZxwG5rZ7D/YPIqrSWbFGXsNys77HHZJOo6CHYBxuI9M+LCO
iIfPlSda/QwiV1L/eixs
=EAG4
-----END PGP SIGNATURE-----

From stpeter@stpeter.im  Tue Oct  8 05:29:51 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AE121E81E2 for <xmpp@ietfa.amsl.com>; Tue,  8 Oct 2013 05:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.279
X-Spam-Level: 
X-Spam-Status: No, score=-101.279 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVpnRCe0l-3y for <xmpp@ietfa.amsl.com>; Tue,  8 Oct 2013 05:29:47 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0856621E8056 for <xmpp@ietf.org>; Tue,  8 Oct 2013 05:29:46 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 53DEA414D9; Tue,  8 Oct 2013 06:35:41 -0600 (MDT)
Message-ID: <5253FABA.9060105@stpeter.im>
Date: Tue, 08 Oct 2013 06:29:46 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: XMPP Standards <standards@xmpp.org>, XMPP <xmpp@ietf.org>
References: <B4EF7539-638D-42B0-9A49-9944E1ED6CC1@jitsi.org>
In-Reply-To: <B4EF7539-638D-42B0-9A49-9944E1ED6CC1@jitsi.org>
X-Enigmail-Version: 1.5.2
X-Forwarded-Message-Id: <B4EF7539-638D-42B0-9A49-9944E1ED6CC1@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [xmpp] Fwd: [Stox] WGLC for draft-ietf-stox-core-06
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 12:29:51 -0000

FYI.


-------- Original Message --------
Subject: [Stox] WGLC for draft-ietf-stox-core-06
Date: Tue, 8 Oct 2013 12:35:57 +0200
From: Yana Stamcheva <yana@jitsi.org>
To: stox@ietf.org <stox@ietf.org>

The editors and the chairs believe that the following draft is now ready
and hereby start a 2-week Working Group Last Call for:

draft-ietf-stox-core-06 : http://tools.ietf.org/html/draft-ietf-stox-core-06

The WGLC ends on October 22, 2013.

Please review the document and bring any remaining issues, or issues
whose resolution is not satisfactory, to the attention of the Working
Group on this list before October 22. If after reviewing the document
you find it complete and do not have any comments, please send a note to
that effect as well.

Regards,
Yana Stamcheva & Markus Isomaki
_______________________________________________
stox mailing list
stox@ietf.org
https://www.ietf.org/mailman/listinfo/stox



From stpeter@stpeter.im  Tue Oct  8 05:30:14 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C8421E818B for <xmpp@ietfa.amsl.com>; Tue,  8 Oct 2013 05:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.392
X-Spam-Level: 
X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG6nxAePMkU3 for <xmpp@ietfa.amsl.com>; Tue,  8 Oct 2013 05:30:09 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E7FB821E81DE for <xmpp@ietf.org>; Tue,  8 Oct 2013 05:30:05 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C325414D9; Tue,  8 Oct 2013 06:36:00 -0600 (MDT)
Message-ID: <5253FACD.6080704@stpeter.im>
Date: Tue, 08 Oct 2013 06:30:05 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: XMPP Standards <standards@xmpp.org>, XMPP <xmpp@ietf.org>
References: <7228C79F-98B8-4AFE-BB7B-99ACAA269EA5@jitsi.org>
In-Reply-To: <7228C79F-98B8-4AFE-BB7B-99ACAA269EA5@jitsi.org>
X-Enigmail-Version: 1.5.2
X-Forwarded-Message-Id: <7228C79F-98B8-4AFE-BB7B-99ACAA269EA5@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [xmpp] Fwd: [Stox] WGLC for draft-ietf-stox-presence-05
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 12:30:14 -0000

FYI.


-------- Original Message --------
Subject: [Stox] WGLC for draft-ietf-stox-presence-05
Date: Tue, 8 Oct 2013 12:36:06 +0200
From: Yana Stamcheva <yana@jitsi.org>
To: stox@ietf.org <stox@ietf.org>

The editors and the chairs believe that the following draft is now ready
and hereby start a 2-week Working Group Last Call for:

draft-ietf-stox-presence-05 :
http://tools.ietf.org/html/draft-ietf-stox-presence-05

The WGLC ends on October 22, 2013.

Please review the document and bring any remaining issues, or issues
whose resolution is not satisfactory, to the attention of the Working
Group on this list before October 22. If after reviewing the document
you find it complete and do not have any comments, please send a note to
that effect as well.

Regards,
Yana Stamcheva & Markus Isomaki
_______________________________________________
stox mailing list
stox@ietf.org
https://www.ietf.org/mailman/listinfo/stox



From ben@nostrum.com  Tue Oct  8 14:43:04 2013
Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A9B21F9E53 for <xmpp@ietfa.amsl.com>; Tue,  8 Oct 2013 14:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT6V1X-tyHAb for <xmpp@ietfa.amsl.com>; Tue,  8 Oct 2013 14:43:04 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE0221F9EFE for <xmpp@ietf.org>; Tue,  8 Oct 2013 14:43:03 -0700 (PDT)
Received: from [10.0.1.9] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r98Lh1cU064958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <xmpp@ietf.org>; Tue, 8 Oct 2013 16:43:02 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 8 Oct 2013 16:43:01 -0500
References: <20131008184514.32189.48777.idtracker@ietfa.amsl.com>
To: XMPP Group <xmpp@ietf.org>
Message-Id: <F6671D74-8228-4A55-99F8-443D51047900@nostrum.com>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism)
Subject: [xmpp] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 21:43:04 -0000

Hi Everyone,

Please note that they need more nominations for both RAI (our current =
home) and APP (our former home. Please consider nominating someone for =
those or any other areas. The NomCom has a hard job; a good set of =
candidates goes a long way towards helping them.

Thanks!

Ben.

Begin forwarded message:

> From: NomCom Chair <nomcom-chair@ietf.org>
> Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, =
RAI, TSV
> Date: October 8, 2013 1:45:14 PM CDT
> To: IETF Announcement List <ietf-announce@ietf.org>
> Cc: ietf@ietf.org
> Reply-To: ietf@ietf.org, nomcom-chair-2013@ietf.org
>=20
> UPDATE: nominations are too sparse in several of the IESG areas:  APP, =
OAM,
> RAI, and TSV.  If you know one or more of those areas, exercise your =
social
> network and submit nominations.  We'll be very grateful!
>=20
> Is there someone you work with at IETF who has leadership potential =
and a
> growing track record? Please read this Nomcom call for nominations and =
consider
> nominating her or him. Or several folks! Deadline for nominations is =
October 18.=20
> Nominate soon to give your nominee(s) plenty time to fill in the =
questionnaire.
>=20
> If you're nominated, even if you support the present incumbent, being =
reviewed
> by Nomcom is great IETF experience.  The questionnaire offers a chance =
to
> think about IETF and about your area.  Whether or not your candidacy =
progresses
> this time, you'll have gained some valuable insights, and you'll have =
contributed
> greatly. This process only works because many IETFers take part; =
please join in.
>=20
> Lots more, including which positions are open, how to make a =
nomination
> (including nomination of yourself), and how to send us your feedback =
on
> the desired expertise, follows.
>=20
> IETFers, let's hear from you!  Make nominations, accept nominations!
>=20
> If you have any questions about the process, feel free to get in touch =
with me.
>=20
> Best regards,
>=20
> Allison for the Nomcom
>=20
> Allison Mankin
> Nomcom Chair 2013-14
>=20
> ----- The Info You Need for Nominating -----
>=20
> The 2013-14 Nominating Committee (Nomcom) is seeking nominations
> from now until October 18, 2013. The open positions being considered
> by this year's Nomcom can be found later in this section, and also on
> this year's Nomcom website:
>=20
> https://datatracker.ietf.org/nomcom/2013/
>=20
> Information about the desired expertise for positions is here:
>          https://datatracker.ietf.org/nomcom/2013/expertise
>=20
> Nominations may be made by selecting the Nominate link at the top of
> the Nomcom 2013 home page, or by visiting the following URL:
>=20
> https://datatracker.ietf.org/nomcom/2013/nominate/
>=20
> Note that nominations made using the web tool require an ietf.org
> datatracker account. You can create a datatracker ietf.org account
> if you don't have one already by visiting the following URL:
>=20
> https://datatracker.ietf.org/accounts/create/
>=20
> Nominations may also be made by email to nomcom13 at ietf.org.
> If you nominate by email, please include the word "Nominate" in the =
Subject
> and indicate in the email who is being nominated, their email address =
(to
> confirm acceptance of the nomination), and the position for which you
> are making the nomination. If you use email, please use a separate =
email for
> each person you nominate, and for each position (if you are nominating =
one
> person for multiple positions).
>=20
> Self-nomination is welcome!  No need to be shy.
>=20
> Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing
> Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of
> nominees willing to be considered for positions under review in the
> current Nomcom cycle is not confidential". Willing nominees for each
> position will be listed in a publicly accessible way - anyone with a
> datatracker account may access the lists.  In all other ways, the
> confidentiality requirements of RFC 3777/BCP10 remain in effect.  All
> feedback and all Nomcom deliberations will remain confidential and =
will
> not be disclosed.=20
>=20
> In order to ensure time to collect sufficient community feedback about
> each of the willing nominees, nominations must be received by the
> Nomcom on or before October 18, 2013.  Please submit your nominations=20=

> as early as possible for the sake of your nominees, as we've set the
> questionnaire submission deadline for October 25, 2013.
>=20
> The list of people and posts whose terms end with the March 2014 IETF =
meeting,
> and thus the positions for which we are accepting nominations:=20
>=20
> IAOC
> Chris Griffiths
>=20
> IAB
> Bernard Aboba
> Marc Blanchet
> Ross Callon
> Eliot Lear
> Hannes Tschofenig
>=20
> IESG
> Barry Leiba (Applications)
> Brian Haberman (Internet)
> Benoit Claise (Operations and Management)
> Gonzalo Camarillo (RAI)
> Stewart Bryant (Routing)
> Sean Turner (Security)
> Martin Stiemerling (Transport)
>=20
> Please be resourceful in identifying possible candidates for these
> positions, as developing our talent is a very crucial requirement for
> the IETF.  Also, please give serious consideration to accepting =
nominations
> you receive.=20
>=20
> The summaries of the desired expertise for the positions, developed by =
the
> respective bodies, are found at:
>=20
> https://datatracker.ietf.org/nomcom/2013/expertise/
>=20
> In addition to nominations, the Nomcom seeks community input on
> the positions themselves.  We need and welcome the community's
> views and input on the jobs within each organization. If you
> have ideas on the positions' responsibilities (more, less,
> different), please let us know.  You can send us email about this to
> nomcom13 at ietf.org, and we will use this feedback actively.
>=20
> Thank you for your help in nominating a great pool of strong and =
interesting
> nominees!


From ben@nostrum.com  Fri Oct 11 02:58:37 2013
Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28D121F9D50 for <xmpp@ietfa.amsl.com>; Fri, 11 Oct 2013 02:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5dIj+Ewmmwi for <xmpp@ietfa.amsl.com>; Fri, 11 Oct 2013 02:58:37 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB7A521E8165 for <xmpp@ietf.org>; Fri, 11 Oct 2013 02:58:33 -0700 (PDT)
Received: from [192.168.176.30] (static-wan-bl3-161-234.rev.webside.pt [62.28.161.234] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9B9wUOv073040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <xmpp@ietf.org>; Fri, 11 Oct 2013 04:58:32 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Oct 2013 10:58:30 +0100
References: <52579E47.6020706@ericsson.com>
To: XMPP Group <xmpp@ietf.org>
Message-Id: <B4EDBBF1-71E3-423F-8D76-0DAEE6CA8E53@nostrum.com>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Received-SPF: pass (shaman.nostrum.com: 62.28.161.234 is authenticated by a trusted mechanism)
Subject: [xmpp] Fwd: [RAI] NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Oct 2013 09:58:37 -0000

FYI

Begin forwarded message:

> From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
> Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - =
APP, OAM, RAI, TSV
> Date: October 11, 2013 7:44:23 AM GMT+01:00
> To: <rai@ietf.org>
>=20
> Folks,
>=20
> we need more volunteers (see email below). If you are thinking of
> running but still have some doubts about it, feel free to talk with me
> (or with any of the former RAI ADs) and we will be happy to clarify
> everything for you.
>=20
> Cheers,
>=20
> Gonzalo
>=20
>=20
> -------- Original Message --------
> Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, =
RAI, TSV
> Date: Tue, 8 Oct 2013 11:45:14 -0700
> From: NomCom Chair <nomcom-chair@ietf.org>
> Reply-To: <nomcom-chair-2013@ietf.org>
> To: IETF Announcement List <ietf-announce@ietf.org>
> CC: <ietf@ietf.org>
>=20
> UPDATE: nominations are too sparse in several of the IESG areas:  APP, =
OAM,
> RAI, and TSV.  If you know one or more of those areas, exercise your =
social
> network and submit nominations.  We'll be very grateful!
>=20
> Is there someone you work with at IETF who has leadership potential =
and a
> growing track record? Please read this Nomcom call for nominations and
> consider
> nominating her or him. Or several folks! Deadline for nominations is
> October 18.
> Nominate soon to give your nominee(s) plenty time to fill in the
> questionnaire.
>=20
> If you're nominated, even if you support the present incumbent, being
> reviewed
> by Nomcom is great IETF experience.  The questionnaire offers a chance =
to
> think about IETF and about your area.  Whether or not your candidacy
> progresses
> this time, you'll have gained some valuable insights, and you'll have
> contributed
> greatly. This process only works because many IETFers take part; =
please
> join in.
>=20
> Lots more, including which positions are open, how to make a =
nomination
> (including nomination of yourself), and how to send us your feedback =
on
> the desired expertise, follows.
>=20
> IETFers, let's hear from you!  Make nominations, accept nominations!
>=20
> If you have any questions about the process, feel free to get in touch
> with me.
>=20
> Best regards,
>=20
> Allison for the Nomcom
>=20
> Allison Mankin
> Nomcom Chair 2013-14
>=20
> ----- The Info You Need for Nominating -----
>=20
> The 2013-14 Nominating Committee (Nomcom) is seeking nominations
> from now until October 18, 2013. The open positions being considered
> by this year's Nomcom can be found later in this section, and also on
> this year's Nomcom website:
>=20
> https://datatracker.ietf.org/nomcom/2013/
>=20
> Information about the desired expertise for positions is here:
>          https://datatracker.ietf.org/nomcom/2013/expertise
>=20
> Nominations may be made by selecting the Nominate link at the top of
> the Nomcom 2013 home page, or by visiting the following URL:
>=20
> https://datatracker.ietf.org/nomcom/2013/nominate/
>=20
> Note that nominations made using the web tool require an ietf.org
> datatracker account. You can create a datatracker ietf.org account
> if you don't have one already by visiting the following URL:
>=20
> https://datatracker.ietf.org/accounts/create/
>=20
> Nominations may also be made by email to nomcom13 at ietf.org.
> If you nominate by email, please include the word "Nominate" in the =
Subject
> and indicate in the email who is being nominated, their email address =
(to
> confirm acceptance of the nomination), and the position for which you
> are making the nomination. If you use email, please use a separate =
email for
> each person you nominate, and for each position (if you are nominating =
one
> person for multiple positions).
>=20
> Self-nomination is welcome!  No need to be shy.
>=20
> Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing
> Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of
> nominees willing to be considered for positions under review in the
> current Nomcom cycle is not confidential". Willing nominees for each
> position will be listed in a publicly accessible way - anyone with a
> datatracker account may access the lists.  In all other ways, the
> confidentiality requirements of RFC 3777/BCP10 remain in effect.  All
> feedback and all Nomcom deliberations will remain confidential and =
will
> not be disclosed.
>=20
> In order to ensure time to collect sufficient community feedback about
> each of the willing nominees, nominations must be received by the
> Nomcom on or before October 18, 2013.  Please submit your nominations
> as early as possible for the sake of your nominees, as we've set the
> questionnaire submission deadline for October 25, 2013.
>=20
> The list of people and posts whose terms end with the March 2014 IETF
> meeting,
> and thus the positions for which we are accepting nominations:
>=20
> IAOC
> Chris Griffiths
>=20
> IAB
> Bernard Aboba
> Marc Blanchet
> Ross Callon
> Eliot Lear
> Hannes Tschofenig
>=20
> IESG
> Barry Leiba (Applications)
> Brian Haberman (Internet)
> Benoit Claise (Operations and Management)
> Gonzalo Camarillo (RAI)
> Stewart Bryant (Routing)
> Sean Turner (Security)
> Martin Stiemerling (Transport)
>=20
> Please be resourceful in identifying possible candidates for these
> positions, as developing our talent is a very crucial requirement for
> the IETF.  Also, please give serious consideration to accepting =
nominations
> you receive.
>=20
> The summaries of the desired expertise for the positions, developed by =
the
> respective bodies, are found at:
>=20
> https://datatracker.ietf.org/nomcom/2013/expertise/
>=20
> In addition to nominations, the Nomcom seeks community input on
> the positions themselves.  We need and welcome the community's
> views and input on the jobs within each organization. If you
> have ideas on the positions' responsibilities (more, less,
> different), please let us know.  You can send us email about this to
> nomcom13 at ietf.org, and we will use this feedback actively.
>=20
> Thank you for your help in nominating a great pool of strong and =
interesting
> nominees!
>=20
>=20
>=20
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai


From internet-drafts@ietf.org  Fri Oct 18 14:44:25 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081D111E8319; Fri, 18 Oct 2013 14:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level: 
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwMMeWaGXHDy; Fri, 18 Oct 2013 14:44:24 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED19011E8358; Fri, 18 Oct 2013 14:44:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131018214422.21887.53267.idtracker@ietfa.amsl.com>
Date: Fri, 18 Oct 2013 14:44:22 -0700
Cc: xmpp@ietf.org
Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-08.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2013 21:44:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Extensible Messaging and Presence Protoco=
l Working Group of the IETF.

	Title           : Extensible Messaging and Presence Protocol (XMPP): Addre=
ss Format
	Author(s)       : Peter Saint-Andre
	Filename        : draft-ietf-xmpp-6122bis-08.txt
	Pages           : 21
	Date            : 2013-10-18

Abstract:
   This document defines the address format for the Extensible Messaging
   and Presence Protocol (XMPP), including support for code points
   outside the ASCII range.  This document obsoletes RFC 6122.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-6122bis-08


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 stpeter@stpeter.im  Sat Oct 19 20:17:30 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4413911E813B for <xmpp@ietfa.amsl.com>; Sat, 19 Oct 2013 20:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.373
X-Spam-Level: 
X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhMn60PcMy6W for <xmpp@ietfa.amsl.com>; Sat, 19 Oct 2013 20:17:26 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EB3BC11E812F for <xmpp@ietf.org>; Sat, 19 Oct 2013 20:17:25 -0700 (PDT)
Received: from sjc-vpn4-833.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EDF914100F; Sat, 19 Oct 2013 21:23:48 -0600 (MDT)
Message-ID: <52634B39.80604@stpeter.im>
Date: Sat, 19 Oct 2013 21:17:13 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: XMPP <xmpp@ietf.org>
References: <20131020031305.9656.82065.idtracker@ietfa.amsl.com>
In-Reply-To: <20131020031305.9656.82065.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.2
X-Forwarded-Message-Id: <20131020031305.9656.82065.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [xmpp] Fwd: I-D Action: draft-saintandre-xmpp-tls-02.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Oct 2013 03:17:30 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.


- -------- Original Message --------
Subject: I-D Action: draft-saintandre-xmpp-tls-02.txt
Date: Sat, 19 Oct 2013 20:13:05 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


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


	Title           : Use of Transport Layer Security (TLS) in the
Extensible Messaging and Presence Protocol (XMPP)
	Author(s)       : Peter Saint-Andre
	Filename        : draft-saintandre-xmpp-tls-02.txt
	Pages           : 10
	Date            : 2013-10-19

Abstract:
   This document provides recommendations for the use of Transport Layer
   Security (TLS) in the Extensible Messaging and Presence Protocol
   (XMPP).  This document updates RFC 6120.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-saintandre-xmpp-tls-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-saintandre-xmpp-tls-02


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/

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSY0s5AAoJEOoGpJErxa2pCtAP/2yc/qcXltcHUa4SJUUq6cZw
P9WPOCRxNn0tG3b/hQyF2agC4ospZocnmI3lNnagrbDUabrDjTk2S/q3qG+5Zd1g
VElhZkx6yVHQa9u6vexArwdyRE2ajiy+/v4ydj8EvBN6BRAg3o39827eh1eQaCna
vTZ3+/ywvr4ClG95yC+R4+ufB8PtfR9S0MmeWVHr4fSn7Xx1Y2Yy23Yl2DdKc+Ho
YJocsKNEVciXAr5VNz9SIPrlnkjQdJnikXSn6kdu6U703xFkfZmRZLB9elD/isDr
jg0qDw7TjpZD+LijseWxfKxNJiq5VAkU27Vf7/GIZJuAFL/Ma2irRJyzaOdls+hL
Qyf4HPF4cH6tiCMePT28D9LbaONgpHbQJ1tvV3sK8KZ5v6sh4Gx5vFyspBd+zilO
NJ3ikeXQStFY90DWdDTxaAE2dLIjcKsQw1OwUAO1BQl1PhHDK0zwnm+KZ6Uum+jH
W5crmM2aL42TIcamovt7CtkSEMIdFp20hP3EiDnVE2Sb9zm/SIlEZPcrw+sP2udK
WBcaOay5pALXBgDMpc+ny5TRxmLyiWmIgGdvlFrZUf9y+EyKul6xuPp50ZE1AN9N
T7cN1jPRzEFr3flkgJPJOezQm/lQDKFOZvhcNsQwb9dzPOGz6sZssSDXQXlC44b9
RrRr4gJxWDE+P4fLW+m8
=j/Es
-----END PGP SIGNATURE-----

From internet-drafts@ietf.org  Sun Oct 20 16:02:43 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4E311E828C; Sun, 20 Oct 2013 16:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.567
X-Spam-Level: 
X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn2j-qC8AOTX; Sun, 20 Oct 2013 16:02:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 121FE11E829E; Sun, 20 Oct 2013 16:02:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131020230241.22714.80535.idtracker@ietfa.amsl.com>
Date: Sun, 20 Oct 2013 16:02:41 -0700
Cc: xmpp@ietf.org
Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-04.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Oct 2013 23:02:43 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Extensible Messaging and Presence Protoco=
l Working Group of the IETF.

	Title           : Domain Name Associations (DNA) in the Extensible Messagi=
ng and Presence Protocol (XMPP)
	Author(s)       : Peter Saint-Andre
                          Matthew Miller
	Filename        : draft-ietf-xmpp-dna-04.txt
	Pages           : 16
	Date            : 2013-10-20

Abstract:
   This document improves the security of the Extensible Messaging and
   Presence Protocol (XMPP) in two ways.  First, it specifies how
   "prooftypes" can establish a strong association between a domain name
   and an XML stream.  Second, it describes how to securely delegate a
   source domain to a derived domain, which is especially important in
   virtual hosting environments.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-dna-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-dna-04


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 mwild1@gmail.com  Tue Oct 22 17:08:11 2013
Return-Path: <mwild1@gmail.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7353E11E8114 for <xmpp@ietfa.amsl.com>; Tue, 22 Oct 2013 17:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSh8VUcIadf8 for <xmpp@ietfa.amsl.com>; Tue, 22 Oct 2013 17:08:10 -0700 (PDT)
Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6B16B11E829A for <xmpp@ietf.org>; Tue, 22 Oct 2013 17:08:06 -0700 (PDT)
Received: by mail-vb0-f49.google.com with SMTP id w16so40499vbb.8 for <xmpp@ietf.org>; Tue, 22 Oct 2013 17:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=//ISZxSyplFGcELO22wzYwpEOOKjrTW/y4u/Whl1RZA=; b=a19E23bL5yMkcT9iVJH4LKdsMrT/n1Lkz3Yz8cstBsjHOqJ6lf3Hv8DkS3d2owSbmK 81BZtR20144P1ffOrA5Mqo2Aag+YbASFBIyLAxhTh9ZS8J8pRTQtYcwA0Qdx6QpTVTns IIsBG81N68e1uPOhWTDDYJjJRsoo6CkLY1uSrb4lnxoA+LrK3TQrBUl/6WNXMsKEDI7/ kaLz2oSO02IKeEn87M1AK1FPvxom5nC6UuQqe3EddA/tMRvUZqiSamw/wLmaMCqkrcKq e3+6Qr7fudV2y016H6RiwbhgPgr8iPRUSJ4eViPzSOJZwvMAsieDMeyT4B/8OeoTPiqm BeNg==
X-Received: by 10.221.21.133 with SMTP id qs5mr1849957vcb.28.1382486885753; Tue, 22 Oct 2013 17:08:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.12.131 with HTTP; Tue, 22 Oct 2013 17:07:44 -0700 (PDT)
From: Matthew Wild <mwild1@gmail.com>
Date: Wed, 23 Oct 2013 01:07:44 +0100
Message-ID: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>
To: XMPP Working Group <xmpp@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 00:08:11 -0000

Florian Zeitz, Lance Stout, Paul Aurich, Waqas Hussain and myself have
just been having some discussion about the largest remaining open
issue in the websocket draft.

I'll start explaining from the beginning, assuming no prior knowledge,
because we're looking for input from as many people as possible in
order to reach a consensus (ha).

Unlike standard TCP which offers a stream of bytes, websockets provide
"framing", which means that the underlying stream is split into
individual frames.

We had a general consensus early on that it made sense to use these
frames to separate stanzas, which is especially useful because
generally Javascript clients do not have access to a streaming (e.g.
SAX) XML parser which is required for parsing unframed XMPP streams.
With framing, clients could (theoretically) take each frame and parse
it individually as a small standalone document.

However there is some awkwardness in this approach, because the
concept of a stream is quite central to traditional XMPP.

Here are the two questions we have:

1) If stanzas are going to be parsed as standalone documents, can they
inherit namespaces from the stream header like they can in normal
XMPP? Or should we require entities to always explicitly declare
namespaces on stanzas? (this includes for example adding
xmlns="jabber:client" xml:lang="xyz" to every stanza).

2) Should we keep the existing stream open and close mechanisms? They
are not standalone documents, and so websocket clients will still need
to handle them with special code.

Options for #1:

  Including namespaces will allow clients (libraries) to pass the data
in a frame directly into the XML parser they have.

  If we don't include namespaces (the current situation), clients are
resorting to hacks which include:
   - Not handling namespaces properly, perhaps assuming they are
always jabber:client
   - Capturing the stream header, and preprending it to every incoming
stanza by concatentating them together (example at
https://github.com/legastero/stanza.io/blob/master/lib/websocket.js#L59
)

However the concerns about adding namespaces explicitly to every stanza include:
  - Bandwidth increase
  - General noise and mess (look at it from a JSON fanatic's perspective)

Options for #2:

First option (current):

  OPEN:  <stream:stream xmlns:stream="..." xmlns="jabber:client"
id="abc123" xml:lang="en">
  CLOSE: </stream:stream>
  ERROR: <stream:error>...</stream:error>

  Benefits include:
     - Pretty much what we are used to already with traditional XMPP,
which means we are all familiar with it, and don't need to define
drastically new stuff

  Problems include:
    - Open and close are not standalone documents, which complicates
parsing for clients without streaming parsers. Again, this leads to
client hacks which include:
        * Parsing with regular expressions
        * Replacing the > at the end with />

Second option (goal: make everything a standalone document):

   OPEN: <stream:stream xmlns:stream="..." xmlns="jabber:client"
id="abc123" xml:lang="en" />
   CLOSE: ????
   ERROR: <stream:error xmlns:stream="..." xmlns="jabber:client"
id="abc123" xml:lang="en">...</stream:error>

   Benefits:
       - Re-uses what we already have

   Problems:
       - Not clear what we should use to signal stream closure
       - Although it's re-using what we already have, it is
overloading it somewhat (the 'stream' is no longer a stream...)

Third option (let's try a new way!):

    OPEN: <open xmlns="..." id="abc123" />
    CLOSE: <close xmlns="..." />
    ERROR: <error xmlns="http://etherx.jabber.org/streams">...</error>

   Benefits:
       - Clean, simple

   Problems:
       - Quite a departure from traditional streams now
       - Duplicates some things from the 'stream' element

Questions, comments, feedback welcome! It's worth noting that this
issue won't be unique to websockets, but will likely be re-used by any
transports that support framing (SCTP for example).

Regards,
Matthew

From lance@andyet.net  Tue Oct 22 18:11:23 2013
Return-Path: <lance@andyet.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7FA21E8056 for <xmpp@ietfa.amsl.com>; Tue, 22 Oct 2013 18:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEpouCx5Dtd4 for <xmpp@ietfa.amsl.com>; Tue, 22 Oct 2013 18:11:17 -0700 (PDT)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF7711E80F2 for <xmpp@ietf.org>; Tue, 22 Oct 2013 18:11:17 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rq2so112322pbb.34 for <xmpp@ietf.org>; Tue, 22 Oct 2013 18:11:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ilbIV6fH5xHxYQonxVy+6tkXYbxW2Edky4rtorzBFrM=; b=JcMhQP0zfevduDLkXbCcBIyuv8U/OGIrB/4UCSGY/kQCdgdEGa/1X9vvF6hMdi5dI4 yRMoJb1U4Ksi/3Syd8WtT8yzccgeSn/1cBj59pzTwr7CzOIg1MAoMDTq367ElyNeHfCk /l8aoXaVqKOaX0v6VggytaFqpG7KBMIIr2Jb38270Gp/u3AuO+Z0eT+GHO5Z9Yl3i2ZW znFX4jun1FG93V2b3not8c9SOO83qgJ/Q6LBpZV1KX6WR5HmVzGOaPf5qI6BC/76feef eYAofkboLnWRfk+2JTRVCHamrox/WKjiyDbnm0ONwLfQA4cXIRLjVhM3zotcR1AN1G9w EWfQ==
X-Gm-Message-State: ALoCoQnXPBpZ+0CmCPGTFJ37JexXe2kKlvQp4L78rn4jcguJwiHel4GPFeHMh5skhg1BRerm+uI5
X-Received: by 10.66.228.38 with SMTP id sf6mr541773pac.21.1382490677248; Tue, 22 Oct 2013 18:11:17 -0700 (PDT)
Received: from [10.46.226.198] (mobile-166-147-082-153.mycingular.net. [166.147.82.153]) by mx.google.com with ESMTPSA id oj6sm36763977pab.9.2013.10.22.18.11.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 18:11:14 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Lance Stout <lance@andyet.net>
X-Mailer: iPhone Mail (11A501)
In-Reply-To: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>
Date: Tue, 22 Oct 2013 18:11:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7318E36F-9872-473D-B086-9E5DDC3566C0@andyet.net>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>
To: Matthew Wild <mwild1@gmail.com>
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 01:11:23 -0000

> (this includes for example adding
> xmlns=3D"jabber:client" xml:lang=3D"xyz" to every stanza).

A realization while reading this: we technically also would have to require t=
he <?xml ... ?> header in every frame to create complete standalone document=
s.

--Lance=

From lance@andyet.net  Tue Oct 22 20:44:07 2013
Return-Path: <lance@andyet.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2E11E8105 for <xmpp@ietfa.amsl.com>; Tue, 22 Oct 2013 20:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuqYT60gkU9d for <xmpp@ietfa.amsl.com>; Tue, 22 Oct 2013 20:44:01 -0700 (PDT)
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id A9F0C11E8116 for <xmpp@ietf.org>; Tue, 22 Oct 2013 20:44:01 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id kp14so80607pab.32 for <xmpp@ietf.org>; Tue, 22 Oct 2013 20:44:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:content-type:from :mime-version:subject:message-id:date:to; bh=n76JAxaFWBNeorPDuaG7azr4mNMc/A7y/t9dFbI2GGg=; b=NGR+I14JBbjBk24ZL1q7ecbnBcL6Rk4V0teHsghkYpnukqjMTrlJkoIf4i7nReXV9M nN8K06hlvkfbOiCWU1U5Smb6zSOEgP95v/KrgRSq0ZJH+PZFKVBuZ/v+nKymrWkFKHU3 hm10NGST8GlA6mUfWqWAjq87/M47yQXAvUGFuhuBO65Lr9ZFReiR623UvX7jPqEbbaP3 X0kJZNLAv+4g/YtPnSt4qE9PRZaYnmu3+3XuvRaP229FvO+uzVT6RjnEX4wXq2HTiDmq Zie+RoXTF/3+ADOOjsxmgLhgoCcccrtnURvnVfFVOwQlyEYfKi+UIvb9jJuAShni7oN9 yDbA==
X-Gm-Message-State: ALoCoQl4PmCuokKp7/HK4XA2qBKnFhRZhd0Oyv/cA+rMvpJuxxmKdV0DNjhxzXroJp2altxbEwSL
X-Received: by 10.68.197.104 with SMTP id it8mr1031293pbc.17.1382499841137; Tue, 22 Oct 2013 20:44:01 -0700 (PDT)
Received: from [10.98.240.146] (mobile-166-147-083-083.mycingular.net. [166.147.83.83]) by mx.google.com with ESMTPSA id ef10sm37477365pac.1.2013.10.22.20.43.59 for <xmpp@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 20:43:59 -0700 (PDT)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
From: Lance Stout <lance@andyet.net>
Mime-Version: 1.0 (1.0)
Message-Id: <B7F88A50-92B4-41ED-80EB-3E248BD9EF06@andyet.net>
Date: Tue, 22 Oct 2013 20:43:55 -0700
To: XMPP Working Group <xmpp@ietf.org>
X-Mailer: iPhone Mail (11A501)
Subject: [xmpp] WebSocket: see-other-uri
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 03:44:07 -0000

Aside from the discussion on start/close signaling of the streams, the last b=
ig todo for XMPP over WebSocket is to define a way for a server to redirect a=
 client to a different endpoint, similarly to the existing see-other-host er=
ror condition.

BOSH defines its own set of error conditions as part of its body wrapping el=
ement, which includes see-other-uri.

Possible solution 1:

Define a see-other-uri stream error condition, in the vein of existing strea=
m error conditions.

Pro: integrates with existing patterns, could be used to bounce a session ac=
ross different transport types.

Con: This might better belong in 6120bis. This could have issues with proxy c=
onnection managers making the source of the uri change ambiguous (ie, if it'=
s the proxy that initiates the uri change versus the server proper.)

Possible solution 2:

If we adopt new start/end signals, we could add conditions to the ending sig=
nal in the vein of the BOSH terminate action.

Pro: Would allow the inclusion of several other condition types as used in B=
OSH, particularly for connection managers. Allows for disambiguating errors f=
rom a proxy connection manager and a server.

Con: Introduces new location for this type of information.



Interactions with XEP-0198 stream management: 198 includes a location slot f=
or a host and port where a client should connect to resume a session. Readin=
g the archives, I see that this was not defined to be a uri because at the t=
ime only BOSH would have used it and so was considered unneeded. Given the u=
sefulness of 198 over WebSocket, it would be worth revisiting that point.


--Lance=

From derhoermi@gmx.net  Wed Oct 23 04:06:42 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6F911E8259 for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 04:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Level: 
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhnExe7-Jsjv for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 04:06:36 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1303911E836C for <xmpp@ietf.org>; Wed, 23 Oct 2013 04:06:29 -0700 (PDT)
Received: from netb.Speedport_W_700V ([91.35.53.139]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0Lkfii-1W6tVY1VKu-00aTVX for <xmpp@ietf.org>; Wed, 23 Oct 2013 13:06:28 +0200
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Lance Stout <lance@andyet.net>
Date: Wed, 23 Oct 2013 13:06:30 +0200
Message-ID: <05bf69lheokqb0bebpll1f35cbbu217sor@hive.bjoern.hoehrmann.de>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com> <7318E36F-9872-473D-B086-9E5DDC3566C0@andyet.net>
In-Reply-To: <7318E36F-9872-473D-B086-9E5DDC3566C0@andyet.net>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:qWPle/h7UjSy8Li/AHXe9bIFkyU2BMNM5oHrKh07ILFeMPlGMMC J09tlQ3V43zaNgxytHFRFQ5Z6xz1ZM3CqwcqMt36xua5M4zAypRdFJDW5BkxCpzl33Lb0Rn 2IMu3xTVWnaSePFLcMxyoHLYMp4WJVfMy8l6P/J6ZZnTnt82lMkN9J8xuFhdroHtVFFig+f 3WaRuO3WK+UGOqUmSF8kA==
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 11:06:42 -0000

* Lance Stout wrote:
>A realization while reading this: we technically also would have to 
>require the <?xml ... ?> header in every frame to create complete 
>standalone documents.

The XML declaration is never needed or useful if you don't do anything
crazy ("crazy" includes using the declaration's `standalone` attribute.)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From waqas20@gmail.com  Wed Oct 23 08:06:25 2013
Return-Path: <waqas20@gmail.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5964F11E843B for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 08:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhV5oD2ZELHh for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 08:06:24 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2D22E11E843A for <xmpp@ietf.org>; Wed, 23 Oct 2013 08:06:17 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id lc6so520403vcb.11 for <xmpp@ietf.org>; Wed, 23 Oct 2013 08:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aeht7K/+TtE9cHzwbgAwHrQUrsTdxvRG+KWTwgCVBzE=; b=gexx3+PwZu3du1DoyExtfvlZoaMT6s+VriWr+f9bvs8rKSq66ZjZHahsazX6vCjYga 71jhjZCT1XP9XdrO1CvF6m+DMKYvwt5QKcmI41eBOrsApQaYP1LbLM8T70RFgWUvu7Zn LL/NhJYxOQX+CdOBM5qw0m94FYYqU1kuiCdIOu19uHJ6g8d/0qyI+NJtFNdU30BJ572r x2nSRDrynZJ+eBFUIi4c9O1+N8Wi+5v/N8koZ74poDcdlh4Q/6Do3GDNGYtFZmSElEX4 tlurALRvwR4pisyoGYQZpK6/T4hac1skIgIbD6A/NR60jv0ZsnfVkeueKkvDMdcVN4/b cC9w==
X-Received: by 10.52.170.232 with SMTP id ap8mr265698vdc.40.1382540776803; Wed, 23 Oct 2013 08:06:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.243.168 with HTTP; Wed, 23 Oct 2013 08:05:56 -0700 (PDT)
In-Reply-To: <05bf69lheokqb0bebpll1f35cbbu217sor@hive.bjoern.hoehrmann.de>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com> <7318E36F-9872-473D-B086-9E5DDC3566C0@andyet.net> <05bf69lheokqb0bebpll1f35cbbu217sor@hive.bjoern.hoehrmann.de>
From: Waqas Hussain <waqas20@gmail.com>
Date: Wed, 23 Oct 2013 11:05:56 -0400
Message-ID: <CALm9TZ-PE1Ob85gSmroO-zkigUcwdCXY2Jb1bkYtbXU2934X6A@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 15:06:25 -0000

On Wed, Oct 23, 2013 at 7:06 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Lance Stout wrote:
>>A realization while reading this: we technically also would have to
>>require the <?xml ... ?> header in every frame to create complete
>>standalone documents.
>
> The XML declaration is never needed or useful if you don't do anything
> crazy ("crazy" includes using the declaration's `standalone` attribute.)

Unless our spec explicitly forbids it, someone will add it. After all,
if you are claiming each frame is an XML document, then adding it is
valid by default (adding the prolog is a SHOULD in the XML 1.0 spec).

--
Waqas Hussain

From stpeter@stpeter.im  Wed Oct 23 10:06:38 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490511E8455 for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 10:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.369
X-Spam-Level: 
X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9n6Lw00F4MO for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 10:06:16 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 93D0811E83FF for <xmpp@ietf.org>; Wed, 23 Oct 2013 10:06:16 -0700 (PDT)
Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D97FE4100F; Wed, 23 Oct 2013 11:12:59 -0600 (MDT)
Message-ID: <52680207.8030608@stpeter.im>
Date: Wed, 23 Oct 2013 11:06:15 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Lance Stout <lance@andyet.net>, XMPP Working Group <xmpp@ietf.org>
References: <B7F88A50-92B4-41ED-80EB-3E248BD9EF06@andyet.net>
In-Reply-To: <B7F88A50-92B4-41ED-80EB-3E248BD9EF06@andyet.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] WebSocket: see-other-uri
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 17:06:38 -0000

On 10/22/13 9:43 PM, Lance Stout wrote:
> Aside from the discussion on start/close signaling of the streams,
> the last big todo for XMPP over WebSocket is to define a way for a
> server to redirect a client to a different endpoint, similarly to the
> existing see-other-host error condition.
> 
> BOSH defines its own set of error conditions as part of its body
> wrapping element, which includes see-other-uri.
> 
> Possible solution 1:
> 
> Define a see-other-uri stream error condition, in the vein of
> existing stream error conditions.
> 
> Pro: integrates with existing patterns, could be used to bounce a
> session across different transport types.
> 
> Con: This might better belong in 6120bis. This could have issues with
> proxy connection managers making the source of the uri change
> ambiguous (ie, if it's the proxy that initiates the uri change versus
> the server proper.)
> 
> Possible solution 2:
> 
> If we adopt new start/end signals, we could add conditions to the
> ending signal in the vein of the BOSH terminate action.
> 
> Pro: Would allow the inclusion of several other condition types as
> used in BOSH, particularly for connection managers. Allows for
> disambiguating errors from a proxy connection manager and a server.
> 
> Con: Introduces new location for this type of information.

Possible solution 3:

Use <undefined-condition/> from RFC 6120 and include an application
specific error condition. We could even directly import the existing
BOSH errors:

   <stream:error>
     <undefined-condition
         xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     <body condition='see-other-uri'
           xmlns='http://jabber.org/protocol/httpbind'/>
   </stream:error>

Pro: Enables us to re-use all of the BOSH conditions if needed.

Con: Using BOSH error conditions for WebSocket seems like a hack.

> Interactions with XEP-0198 stream management: 198 includes a location
> slot for a host and port where a client should connect to resume a
> session. Reading the archives, I see that this was not defined to be
> a uri because at the time only BOSH would have used it and so was
> considered unneeded. Given the usefulness of 198 over WebSocket, it
> would be worth revisiting that point.

That's a possible change to XEP-0198, right?

Peter

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



From mamille2@cisco.com  Wed Oct 23 10:10:50 2013
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE7D11E81DC for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 10:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqcs8Ge7VazN for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 10:10:43 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D00AF11E8170 for <xmpp@ietf.org>; Wed, 23 Oct 2013 10:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5475; q=dns/txt; s=iport; t=1382548243; x=1383757843; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sgtVzb5WKobn8lXSPZ3Ky2D47m0Cz06IjUh3NlWc764=; b=DuMi5Q34xWxHhuJO154lRVbeSJlKcq59U3csSJCvxek3XEbUr06F6aT/ ynY9dGEF2ik1OJMetcWcs+yWbhwuIP7B0yheUvAZDkOUvI0wjhCEn1EBv FyPV1qlFJF8wXMelsKC2PohPkQswWe6swExo8v+iTAvMA+SbEgPo5lXkS 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAMkCaFKtJV2d/2dsb2JhbABZgwc4VL5PgS4WdIIlAQEBAwE6RAsCAQgiFBAhESUCBBMIAYdrAwkGDbEKDYlrjGCBNYEGAjMFgx+BCwOUKoF0gxqLIQOFNIMkgXE5
X-IronPort-AV: E=Sophos;i="4.93,555,1378857600"; d="scan'208";a="275743879"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2013 17:10:42 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9NHAgbE014029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <xmpp@ietf.org>; Wed, 23 Oct 2013 17:10:42 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.88]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 12:10:41 -0500
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: XMPP Group <xmpp@ietf.org>
Thread-Topic: [xmpp] Websockets: streams or not streams?
Thread-Index: AQHOz4P4F9Lhyyngw0WiO3di/5ZU75oC2mSA
Date: Wed, 23 Oct 2013 17:10:41 +0000
Message-ID: <BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>
In-Reply-To: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.101.72.48]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2891DDABC6197944896CF0A22B0F70DE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 17:10:50 -0000

On Oct 22, 2013, at 6:07 PM, Matthew Wild <mwild1@gmail.com>
 wrote:

> Florian Zeitz, Lance Stout, Paul Aurich, Waqas Hussain and myself have
> just been having some discussion about the largest remaining open
> issue in the websocket draft.
>=20
> I'll start explaining from the beginning, assuming no prior knowledge,
> because we're looking for input from as many people as possible in
> order to reach a consensus (ha).
>=20
> Unlike standard TCP which offers a stream of bytes, websockets provide
> "framing", which means that the underlying stream is split into
> individual frames.
>=20
> We had a general consensus early on that it made sense to use these
> frames to separate stanzas, which is especially useful because
> generally Javascript clients do not have access to a streaming (e.g.
> SAX) XML parser which is required for parsing unframed XMPP streams.
> With framing, clients could (theoretically) take each frame and parse
> it individually as a small standalone document.
>=20
> However there is some awkwardness in this approach, because the
> concept of a stream is quite central to traditional XMPP.
>=20
> Here are the two questions we have:
>=20
> 1) If stanzas are going to be parsed as standalone documents, can they
> inherit namespaces from the stream header like they can in normal
> XMPP? Or should we require entities to always explicitly declare
> namespaces on stanzas? (this includes for example adding
> xmlns=3D"jabber:client" xml:lang=3D"xyz" to every stanza).
>=20
> 2) Should we keep the existing stream open and close mechanisms? They
> are not standalone documents, and so websocket clients will still need
> to handle them with special code.
>=20
> Options for #1:
>=20
>  Including namespaces will allow clients (libraries) to pass the data
> in a frame directly into the XML parser they have.
>=20
>  If we don't include namespaces (the current situation), clients are
> resorting to hacks which include:
>   - Not handling namespaces properly, perhaps assuming they are
> always jabber:client
>   - Capturing the stream header, and preprending it to every incoming
> stanza by concatentating them together (example at
> https://github.com/legastero/stanza.io/blob/master/lib/websocket.js#L59
> )
>=20
> However the concerns about adding namespaces explicitly to every stanza i=
nclude:
>  - Bandwidth increase
>  - General noise and mess (look at it from a JSON fanatic's perspective)
>=20

The hack of wrapping stanzas in an element with all of the inheritable name=
spacing seems fairly innocuous.  It could be something like:

<app:wrapper xmlns:app=3D'urn:for:my:app' xmlns:stream=3D'http://etherx.jab=
ber.org/streams' xmlns=3D'jabber:client'>
  {{ insert websocket message here }}
</app:wrapper>

Assuming the client is keeping track of its stream state (which it really n=
eeds to).

That said, I personally have a slight preference for them to be proper stan=
d-alone.  The "general noise and mess" is something that one sees with BOSH=
 anyway.

> Options for #2:
>=20
> First option (current):
>=20
>  OPEN:  <stream:stream xmlns:stream=3D"..." xmlns=3D"jabber:client"
> id=3D"abc123" xml:lang=3D"en">
>  CLOSE: </stream:stream>
>  ERROR: <stream:error>...</stream:error>
>=20
>  Benefits include:
>     - Pretty much what we are used to already with traditional XMPP,
> which means we are all familiar with it, and don't need to define
> drastically new stuff
>=20
>  Problems include:
>    - Open and close are not standalone documents, which complicates
> parsing for clients without streaming parsers. Again, this leads to
> client hacks which include:
>        * Parsing with regular expressions
>        * Replacing the > at the end with />
>=20
> Second option (goal: make everything a standalone document):
>=20
>   OPEN: <stream:stream xmlns:stream=3D"..." xmlns=3D"jabber:client"
> id=3D"abc123" xml:lang=3D"en" />
>   CLOSE: ????
>   ERROR: <stream:error xmlns:stream=3D"..." xmlns=3D"jabber:client"
> id=3D"abc123" xml:lang=3D"en">...</stream:error>
>=20
>   Benefits:
>       - Re-uses what we already have
>=20
>   Problems:
>       - Not clear what we should use to signal stream closure
>       - Although it's re-using what we already have, it is
> overloading it somewhat (the 'stream' is no longer a stream...)
>=20
> Third option (let's try a new way!):
>=20
>    OPEN: <open xmlns=3D"..." id=3D"abc123" />
>    CLOSE: <close xmlns=3D"..." />
>    ERROR: <error xmlns=3D"http://etherx.jabber.org/streams">...</error>
>=20
>   Benefits:
>       - Clean, simple
>=20
>   Problems:
>       - Quite a departure from traditional streams now
>       - Duplicates some things from the 'stream' element
>=20

I have heard off-list from a few developers that dealing with the XMPP stre=
ams in WebSockets like raw TCP sockets is enough of a burden for them to ha=
ve completely ignored the opening <stream:stream>.  I think it's worth doin=
g something different for this reason.  I also think the target audience fo=
r the WebSocket-based transport client-side aren't (guaranteed to be) also =
writing code for dealing with raw TCP sockets.

I had posted a strawman to the list in May; that might be worth considering=
 (or not) < http://www.ietf.org/mail-archive/web/xmpp/current/msg02971.html=
 >.


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


From stpeter@stpeter.im  Wed Oct 23 12:18:37 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C35E11E820A for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 12:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.052
X-Spam-Level: 
X-Spam-Status: No, score=-102.052 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2yzhmRj0HQ4 for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 12:18:33 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCE011E8203 for <xmpp@ietf.org>; Wed, 23 Oct 2013 12:18:33 -0700 (PDT)
Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4E0194100F; Wed, 23 Oct 2013 13:25:16 -0600 (MDT)
Message-ID: <52682107.3030502@stpeter.im>
Date: Wed, 23 Oct 2013 13:18:31 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "Matt Miller (mamille2)" <mamille2@cisco.com>, XMPP Group <xmpp@ietf.org>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 19:18:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/13 11:10 AM, Matt Miller (mamille2) wrote:
> 
> On Oct 22, 2013, at 6:07 PM, Matthew Wild <mwild1@gmail.com>
> wrote:
> 
>> Florian Zeitz, Lance Stout, Paul Aurich, Waqas Hussain and
>> myself have just been having some discussion about the largest
>> remaining open issue in the websocket draft.
>> 
>> I'll start explaining from the beginning, assuming no prior 
>> knowledge, because we're looking for input from as many people
>> as possible in order to reach a consensus (ha).
>> 
>> Unlike standard TCP which offers a stream of bytes, websockets 
>> provide "framing", which means that the underlying stream is
>> split into individual frames.
>> 
>> We had a general consensus early on that it made sense to use 
>> these frames to separate stanzas, which is especially useful 
>> because generally Javascript clients do not have access to a 
>> streaming (e.g. SAX) XML parser which is required for parsing 
>> unframed XMPP streams. With framing, clients could
>> (theoretically) take each frame and parse it individually as a
>> small standalone document.
>> 
>> However there is some awkwardness in this approach, because the 
>> concept of a stream is quite central to traditional XMPP.
>> 
>> Here are the two questions we have:
>> 
>> 1) If stanzas are going to be parsed as standalone documents,
>> can they inherit namespaces from the stream header like they can
>> in normal XMPP? Or should we require entities to always
>> explicitly declare namespaces on stanzas? (this includes for
>> example adding xmlns="jabber:client" xml:lang="xyz" to every
>> stanza).
>> 
>> 2) Should we keep the existing stream open and close mechanisms? 
>> They are not standalone documents, and so websocket clients will 
>> still need to handle them with special code.
>> 
>> Options for #1:
>> 
>> Including namespaces will allow clients (libraries) to pass the 
>> data in a frame directly into the XML parser they have.
>> 
>> If we don't include namespaces (the current situation), clients 
>> are resorting to hacks which include: - Not handling namespaces 
>> properly, perhaps assuming they are always jabber:client - 
>> Capturing the stream header, and preprending it to every incoming
>>  stanza by concatentating them together (example at 
>> https://github.com/legastero/stanza.io/blob/master/lib/websocket.js#L59
>>
>>
>> 
)
>> 
>> However the concerns about adding namespaces explicitly to every 
>> stanza include: - Bandwidth increase - General noise and mess
>> (look at it from a JSON fanatic's perspective)
>> 
> 
> The hack of wrapping stanzas in an element with all of the 
> inheritable namespacing seems fairly innocuous.  It could be 
> something like:
> 
> <app:wrapper xmlns:app='urn:for:my:app' 
> xmlns:stream='http://etherx.jabber.org/streams' 
> xmlns='jabber:client'> {{ insert websocket message here }} 
> </app:wrapper>
> 
> Assuming the client is keeping track of its stream state (which it 
> really needs to).
> 
> That said, I personally have a slight preference for them to be 
> proper stand-alone.  The "general noise and mess" is something
> that one sees with BOSH anyway.
> 
>> Options for #2:
>> 
>> First option (current):
>> 
>> OPEN:  <stream:stream xmlns:stream="..." xmlns="jabber:client" 
>> id="abc123" xml:lang="en"> CLOSE: </stream:stream> ERROR: 
>> <stream:error>...</stream:error>
>> 
>> Benefits include: - Pretty much what we are used to already with 
>> traditional XMPP, which means we are all familiar with it, and 
>> don't need to define drastically new stuff
>> 
>> Problems include: - Open and close are not standalone documents, 
>> which complicates parsing for clients without streaming parsers. 
>> Again, this leads to client hacks which include: * Parsing with 
>> regular expressions * Replacing the > at the end with />
>> 
>> Second option (goal: make everything a standalone document):
>> 
>> OPEN: <stream:stream xmlns:stream="..." xmlns="jabber:client" 
>> id="abc123" xml:lang="en" /> CLOSE: ???? ERROR: <stream:error 
>> xmlns:stream="..." xmlns="jabber:client" id="abc123" 
>> xml:lang="en">...</stream:error>
>> 
>> Benefits: - Re-uses what we already have
>> 
>> Problems: - Not clear what we should use to signal stream closure
>> - Although it's re-using what we already have, it is overloading
>> it somewhat (the 'stream' is no longer a stream...)
>> 
>> Third option (let's try a new way!):
>> 
>> OPEN: <open xmlns="..." id="abc123" /> CLOSE: <close xmlns="..." 
>> /> ERROR: <error 
>> xmlns="http://etherx.jabber.org/streams">...</error>
>> 
>> Benefits: - Clean, simple
>> 
>> Problems: - Quite a departure from traditional streams now - 
>> Duplicates some things from the 'stream' element
>> 
> 
> I have heard off-list from a few developers that dealing with the 
> XMPP streams in WebSockets like raw TCP sockets is enough of a
> burden for them to have completely ignored the opening
> <stream:stream>.  I think it's worth doing something different for
> this reason.  I also think the target audience for the
> WebSocket-based transport client-side aren't (guaranteed to be)
> also writing code for dealing with raw TCP sockets.
> 
> I had posted a strawman to the list in May; that might be worth 
> considering (or not) < 
> http://www.ietf.org/mail-archive/web/xmpp/current/msg02971.html >.

You proposed:

###

* begin: <ws:open xmlns:ws='urn:ietf:params:xml:ns:xmpp-websocket'
                  version='1.0'
                  to='example.com'
                  from='juliet at example.com'
                  xml:lang='en'/>

* end: <ws:close xmlns:ws='urn:ietf:params:xml:ns:xmpp-websocket'/>

###

That seems fine to me. Lance made a good point about overloading the
streams namespace to no longer describe a stream. IMHO it would be
better to define something that's specific to the WebSocket binding,
since we already have a precedent of defined something specific to the
BOSH binding. Thus the streams construct is only for the TCP binding
(which is the only place where it really makes sense, I think).

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSaCEHAAoJEOoGpJErxa2pVgYQAIPFc4SZyc3es0/i5q1RT/nc
SteAyEuWjA6ihHUxE8psLql/W9UbcPDtumkWFzYTeNugik8PDB0PIaZQtOwMIXvb
2Jgt9gPyaC0d4oeIc1aZ4ZwG5YwXrzrPJKIoz31dy5GFhlM+diT7ZXVr5X0PQzWL
UgDb4Citr4r5kFdsV7uOv6RjBsE63SlGWe9aBqjYURSEDQZcOzTKh5Q0DFDqDGtI
KYaoeuxigf8oAkJ5BA4u9KtMdZlK1lB721cOFD7uCXKlepGVcc9ZMyBUSs/a6zAl
Wrt0GJdpj9foA8rhbE/qWCwxg0X2l1m37s2tj8cqOm7hQWJ88W6zxgMQMic6X5uE
mBc58oUK7BlS+6mtA/Ru7WPXN/IHbqW1uleSFk9wI/TUharMBTNbHrignAvFnaGm
cS3mm9l6soa/gRRhAp+YYNyyCJSGniAUkKO+1ZnuDYjHOEz28UNTFBy3+TyHYHQs
zCVsJ1ttWKJ7NISYG4o28jUeC1+9TUduF7Utq4zefGGcPJ8JwKskRmzlC3OPXOKg
Dtu1AJU5ucn2dhkMqY/QAj7PioNMqAGEq8+N+5PQBKVTj3MKFA0/ZukPZZTZUutj
qusKpjpjVDfLu+JJ1kYLnx63JhXCD9wpxR9opZ69Lhva7LPZdsi1Wkat3FalzaGr
8U/XktgvriUNpwuNaKg0
=VZw0
-----END PGP SIGNATURE-----

From ben@nostrum.com  Wed Oct 23 12:39:54 2013
Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707B011E8236 for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 12:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.195
X-Spam-Level: 
X-Spam-Status: No, score=-102.195 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4sb+4VdKBAE for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 12:39:54 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7111E820A for <xmpp@ietf.org>; Wed, 23 Oct 2013 12:39:53 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9NJdoQg039998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <xmpp@ietf.org>; Wed, 23 Oct 2013 14:39:51 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <37C2E5B9-D466-4461-A885-B509762F64FC@nostrum.com>
Date: Wed, 23 Oct 2013 14:39:55 -0500
To: XMPP Group <xmpp@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Subject: [xmpp] Draft Agenda for Vancouver
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 19:39:54 -0000

Hi,

The _draft_ agenda for the Vancouver XMPP meeting is available at the =
following link. Please send any feedback to the XMPP list as soon as =
possible. The final agenda is due Monday.

http://www.ietf.org/proceedings/88/agenda/agenda-88-xmpp


Thanks!

Ben.=20=

From 9ordin@gmail.com  Wed Oct 23 12:46:51 2013
Return-Path: <9ordin@gmail.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C47311E8142 for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 12:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqZaPER-UmxQ for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 12:46:50 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7430F11E8126 for <xmpp@ietf.org>; Wed, 23 Oct 2013 12:46:50 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id u16so2226957iet.32 for <xmpp@ietf.org>; Wed, 23 Oct 2013 12:46:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=ibJYpjlHSIVWpNvy/8/jZlyoInpJD5GzPBzi9HBvuK0=; b=k5FEjXD8hbHBexXYUGR0AQgI9IwTl0YEiJPXyUFXdAIIk9FBDRqCKs280/nez1xxP1 Cl03eonVC/qDwbQzMT1UrEMgGgkr5+ihY74FLcydsyz+sm3P+JqSXawPoYTTB/EY1obU RuajWm72b7KADOaQb/QKMDdrI2BIjk7ySKZgdrBN5N5tPtwnlak7JP2kaLf/UA71epf3 EjDyzubfbZCh/nPupdqOlW5V/XU68UmtWRXcDRn3SPAn+zUpPp+FjiJe0Y/YviMMP5P/ 3q+46E6eh5Qk89EVZrkjLhjnESY2qbX+NPpAMf6jPatrnuTy39dqj4Dboho+aCM17eJP LAKw==
X-Received: by 10.50.66.163 with SMTP id g3mr1765090igt.20.1382557609994; Wed, 23 Oct 2013 12:46:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.173.34 with HTTP; Wed, 23 Oct 2013 12:46:29 -0700 (PDT)
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com>
From: Gordin <9ordin@gmail.com>
Date: Wed, 23 Oct 2013 21:46:29 +0200
Message-ID: <CAFp5o_KO2jE3gQDr951PG5pm=Xa8cgJebhc0YcxKXS0=5tL+hg@mail.gmail.com>
To: XMPP Group <xmpp@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 19:46:51 -0000

Hi, $guy-who-implemented-webwockets-in-StropheJS here.

2013/10/23 Matt Miller (mamille2) <mamille2@cisco.com>:
>
> On Oct 22, 2013, at 6:07 PM, Matthew Wild <mwild1@gmail.com>
>  wrote:
>
>> Florian Zeitz, Lance Stout, Paul Aurich, Waqas Hussain and myself have
>> just been having some discussion about the largest remaining open
>> issue in the websocket draft.
>>
>> I'll start explaining from the beginning, assuming no prior knowledge,
>> because we're looking for input from as many people as possible in
>> order to reach a consensus (ha).
>>
>> Unlike standard TCP which offers a stream of bytes, websockets provide
>> "framing", which means that the underlying stream is split into
>> individual frames.
>>
>> We had a general consensus early on that it made sense to use these
>> frames to separate stanzas, which is especially useful because
>> generally Javascript clients do not have access to a streaming (e.g.
>> SAX) XML parser which is required for parsing unframed XMPP streams.
>> With framing, clients could (theoretically) take each frame and parse
>> it individually as a small standalone document.
>>
>> However there is some awkwardness in this approach, because the
>> concept of a stream is quite central to traditional XMPP.
>>
>> Here are the two questions we have:
>>
>> 1) If stanzas are going to be parsed as standalone documents, can they
>> inherit namespaces from the stream header like they can in normal
>> XMPP? Or should we require entities to always explicitly declare
>> namespaces on stanzas? (this includes for example adding
>> xmlns=3D"jabber:client" xml:lang=3D"xyz" to every stanza).
>>
>> 2) Should we keep the existing stream open and close mechanisms? They
>> are not standalone documents, and so websocket clients will still need
>> to handle them with special code.
>>
>> Options for #1:
>>
>>  Including namespaces will allow clients (libraries) to pass the data
>> in a frame directly into the XML parser they have.
>>
>>  If we don't include namespaces (the current situation), clients are
>> resorting to hacks which include:
>>   - Not handling namespaces properly, perhaps assuming they are
>> always jabber:client
>>   - Capturing the stream header, and preprending it to every incoming
>> stanza by concatentating them together (example at
>> https://github.com/legastero/stanza.io/blob/master/lib/websocket.js#L59
>> )
>>
>> However the concerns about adding namespaces explicitly to every stanza =
include:
>>  - Bandwidth increase
>>  - General noise and mess (look at it from a JSON fanatic's perspective)
>>

I'm not a fan of this solution, mostly because I don't like to waste
bandwidth with sending the client information it already knows over
and over again.
If namespaces are to be parsed correctly without using a SAX parser
than someone has to capture the header and put it in the messages that
are parsed every time. However in the proposed solution it is phrased
as if capturing the header and merging it with every message is a hack
when the client does it, but ok if the server does it. Personally I
think letting the server add a namespace that the client already knows
is equally "hacky" than letting the client do it. If someone is adding
a namespace to every message anyway it might as well be the client.
I favor the few lines of code in the client code over the constantly
wasted bandwidth here.

>
> The hack of wrapping stanzas in an element with all of the inheritable na=
mespacing seems fairly innocuous.  It could be something like:
>
> <app:wrapper xmlns:app=3D'urn:for:my:app' xmlns:stream=3D'http://etherx.j=
abber.org/streams' xmlns=3D'jabber:client'>
>   {{ insert websocket message here }}
> </app:wrapper>
>
> Assuming the client is keeping track of its stream state (which it really=
 needs to).

It doesn't need to be told with every stanza to do that though.

>
> That said, I personally have a slight preference for them to be proper st=
and-alone.  The "general noise and mess" is something that one sees with BO=
SH anyway.
>

Also, I don't really see how BOSH being messy justifies websocket
getting messier in any way.

>> Options for #2:
>>
>> First option (current):
>>
>>  OPEN:  <stream:stream xmlns:stream=3D"..." xmlns=3D"jabber:client"
>> id=3D"abc123" xml:lang=3D"en">
>>  CLOSE: </stream:stream>
>>  ERROR: <stream:error>...</stream:error>
>>
>>  Benefits include:
>>     - Pretty much what we are used to already with traditional XMPP,
>> which means we are all familiar with it, and don't need to define
>> drastically new stuff
>>
>>  Problems include:
>>    - Open and close are not standalone documents, which complicates
>> parsing for clients without streaming parsers. Again, this leads to
>> client hacks which include:
>>        * Parsing with regular expressions
>>        * Replacing the > at the end with />
>>
>> Second option (goal: make everything a standalone document):
>>
>>   OPEN: <stream:stream xmlns:stream=3D"..." xmlns=3D"jabber:client"
>> id=3D"abc123" xml:lang=3D"en" />
>>   CLOSE: ????
>>   ERROR: <stream:error xmlns:stream=3D"..." xmlns=3D"jabber:client"
>> id=3D"abc123" xml:lang=3D"en">...</stream:error>
>>
>>   Benefits:
>>       - Re-uses what we already have
>>
>>   Problems:
>>       - Not clear what we should use to signal stream closure
>>       - Although it's re-using what we already have, it is
>> overloading it somewhat (the 'stream' is no longer a stream...)
>>
>> Third option (let's try a new way!):
>>
>>    OPEN: <open xmlns=3D"..." id=3D"abc123" />
>>    CLOSE: <close xmlns=3D"..." />
>>    ERROR: <error xmlns=3D"http://etherx.jabber.org/streams">...</error>
>>
>>   Benefits:
>>       - Clean, simple
>>
>>   Problems:
>>       - Quite a departure from traditional streams now
>>       - Duplicates some things from the 'stream' element
>>

I'm not 100% sure on the posted solutions here. I'm OK with the
'stream' being selfclosing and no longer being a stream, as every
stanza is parsed on it's own anyway.

What I would vote for is probably kind of a mix of the 3 options above:

OPEN:  <stream:stream xmlns:stream=3D"..." xmlns=3D"jabber:client"
id=3D"abc123" xml:lang=3D"en"/> OR  <stream:open ......../>
CLOSE: <stream:stream/>  OR   <stream:close/>
ERROR: <stream:error>...</stream:error>

So, change the opening and closing tags to be selfclosing and let
everything else as it is.

Pros:
* Only two "/"s moved around, everything else stays as it is and
browsers can now parse everything.
* Still looks like intended for XMPP streams
* Works exactly like current implementations handle things anyway. (Of
course implementations that just plain match the closing tag against
</stream:stream> could actually parse it now)
* stream errors can stay the way they are

Cons:
* Not a real stream any more (like all of the other solutions)
* two stream:stream tags per stream. This could be "fixed" by either
** renaming ":stream" to ":open" in the closing tag and to ":close" in
the closing tag. Doing this would be the clearest solution but would
duplicate the meaning of stream:stream
or
** just renaming the ":stream" to ":close" in the closing tag. This
would avoid duplication of the meaning of stream:stream
or
** just ignoring that there are two "stream:stream"s for one stream
now. First one opens, second one closes.

Of this options I would probably prefer this one
OPEN:  <stream:stream xmlns:stream=3D"..." xmlns=3D"jabber:client"
id=3D"abc123" xml:lang=3D"en"/>
CLOSE: <stream:close/>
ERROR: <stream:error>...</stream:error>

Keep the stream:stream, make it selfclosing and replace the
</stream:stream> by a <stream:close/>


>
> I have heard off-list from a few developers that dealing with the XMPP st=
reams in WebSockets like raw TCP sockets is enough of a burden for them to =
have completely ignored the opening <stream:stream>.  I think it's worth do=
ing something different for this reason.  I also think the target audience =
for the WebSocket-based transport client-side aren't (guaranteed to be) als=
o writing code for dealing with raw TCP sockets.
>
> I had posted a strawman to the list in May; that might be worth consideri=
ng (or not) < http://www.ietf.org/mail-archive/web/xmpp/current/msg02971.ht=
ml >.
>

This is basically like the solution I came up with, just with
"ws:open" instead of "stream:stream" and "ws:close" instead of
"stream:close", so also +1 for this.

>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
>
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp

- gordin

From florob@babelmonkeys.de  Wed Oct 23 14:22:55 2013
Return-Path: <florob@babelmonkeys.de>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAB311E8241 for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 14:22:55 -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=-2.599, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRjs5p2gU9wa for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 14:22:54 -0700 (PDT)
Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACFB11E821A for <xmpp@ietf.org>; Wed, 23 Oct 2013 14:22:53 -0700 (PDT)
Received: from xdsl-78-34-253-169.netcologne.de ([78.34.253.169] helo=[192.168.234.39]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <florob@babelmonkeys.de>) id 1VZ5vK-0000RI-Ov for xmpp@ietf.org; Wed, 23 Oct 2013 23:25:03 +0200
Message-ID: <52683E25.4040208@babelmonkeys.de>
Date: Wed, 23 Oct 2013 23:22:45 +0200
From: Florian Zeitz <florob@babelmonkeys.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: xmpp@ietf.org
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>	<BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com> <CAFp5o_KO2jE3gQDr951PG5pm=Xa8cgJebhc0YcxKXS0=5tL+hg@mail.gmail.com>
In-Reply-To: <CAFp5o_KO2jE3gQDr951PG5pm=Xa8cgJebhc0YcxKXS0=5tL+hg@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 21:22:55 -0000

Am 23.10.2013 21:46, schrieb Gordin:
> Hi, $guy-who-implemented-webwockets-in-StropheJS here.
> 
> 2013/10/23 Matt Miller (mamille2) <mamille2@cisco.com>:
>>
>> On Oct 22, 2013, at 6:07 PM, Matthew Wild <mwild1@gmail.com>
>>  wrote:
>>
[...]
>>> Here are the two questions we have:
>>>
>>> 1) If stanzas are going to be parsed as standalone documents, can they
>>> inherit namespaces from the stream header like they can in normal
>>> XMPP? Or should we require entities to always explicitly declare
>>> namespaces on stanzas? (this includes for example adding
>>> xmlns="jabber:client" xml:lang="xyz" to every stanza).
>>>
>>> 2) Should we keep the existing stream open and close mechanisms? They
>>> are not standalone documents, and so websocket clients will still need
>>> to handle them with special code.
>>>
>>> Options for #1:
>>>
>>>  Including namespaces will allow clients (libraries) to pass the data
>>> in a frame directly into the XML parser they have.
>>>
>>>  If we don't include namespaces (the current situation), clients are
>>> resorting to hacks which include:
>>>   - Not handling namespaces properly, perhaps assuming they are
>>> always jabber:client
>>>   - Capturing the stream header, and preprending it to every incoming
>>> stanza by concatentating them together (example at
>>> https://github.com/legastero/stanza.io/blob/master/lib/websocket.js#L59
>>> )
>>>
>>> However the concerns about adding namespaces explicitly to every stanza include:
>>>  - Bandwidth increase
>>>  - General noise and mess (look at it from a JSON fanatic's perspective)
>>>
> 
> I'm not a fan of this solution, mostly because I don't like to waste
> bandwidth with sending the client information it already knows over
> and over again.
> If namespaces are to be parsed correctly without using a SAX parser
> than someone has to capture the header and put it in the messages that
> are parsed every time. However in the proposed solution it is phrased
> as if capturing the header and merging it with every message is a hack
> when the client does it, but ok if the server does it. Personally I
> think letting the server add a namespace that the client already knows
> is equally "hacky" than letting the client do it. If someone is adding
> a namespace to every message anyway it might as well be the client.
> I favor the few lines of code in the client code over the constantly
> wasted bandwidth here.
> 
There is actually a reason to have this on the server. Which is that
XMPP traditionally follows a simple client, complex server model.
Stamping this on the server side allows you to put whatever you receive
in the DOMParser, no further processing required.
The bandwidth argument is very valid though, and might outweigh the
small inconvenience for clients.
After yesterdays discussion I honest have no strong opinion on this.

>>
>> The hack of wrapping stanzas in an element with all of the inheritable namespacing seems fairly innocuous.  It could be something like:
>>
>> <app:wrapper xmlns:app='urn:for:my:app' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'>
>>   {{ insert websocket message here }}
>> </app:wrapper>
>>
>> Assuming the client is keeping track of its stream state (which it really needs to).
> 
> It doesn't need to be told with every stanza to do that though.
> 
Indeed. Both of you should be aware though that neither injecting some
namespaces directly into the stanzas, nor using a fixed wrapper element
is a correct solution here. You want to wrap stanzas in the actual
stream header you received. I'm convinced it's unnecessarily hard if not
impossibly to extract only the "important" attributes from it.

>>
>> That said, I personally have a slight preference for them to be proper stand-alone.  The "general noise and mess" is something that one sees with BOSH anyway.
>>
> 
> Also, I don't really see how BOSH being messy justifies websocket
> getting messier in any way.
> 
>>> Options for #2:
>>>
>>> First option (current):
>>>
>>>  OPEN:  <stream:stream xmlns:stream="..." xmlns="jabber:client"
>>> id="abc123" xml:lang="en">
>>>  CLOSE: </stream:stream>
>>>  ERROR: <stream:error>...</stream:error>
>>>
>>>  Benefits include:
>>>     - Pretty much what we are used to already with traditional XMPP,
>>> which means we are all familiar with it, and don't need to define
>>> drastically new stuff
>>>
>>>  Problems include:
>>>    - Open and close are not standalone documents, which complicates
>>> parsing for clients without streaming parsers. Again, this leads to
>>> client hacks which include:
>>>        * Parsing with regular expressions
>>>        * Replacing the > at the end with />
>>>
>>> Second option (goal: make everything a standalone document):
>>>
>>>   OPEN: <stream:stream xmlns:stream="..." xmlns="jabber:client"
>>> id="abc123" xml:lang="en" />
>>>   CLOSE: ????
>>>   ERROR: <stream:error xmlns:stream="..." xmlns="jabber:client"
>>> id="abc123" xml:lang="en">...</stream:error>
>>>
>>>   Benefits:
>>>       - Re-uses what we already have
>>>
>>>   Problems:
>>>       - Not clear what we should use to signal stream closure
>>>       - Although it's re-using what we already have, it is
>>> overloading it somewhat (the 'stream' is no longer a stream...)
>>>
>>> Third option (let's try a new way!):
>>>
>>>    OPEN: <open xmlns="..." id="abc123" />
>>>    CLOSE: <close xmlns="..." />
>>>    ERROR: <error xmlns="http://etherx.jabber.org/streams">...</error>
>>>
>>>   Benefits:
>>>       - Clean, simple
>>>
>>>   Problems:
>>>       - Quite a departure from traditional streams now
>>>       - Duplicates some things from the 'stream' element
>>>
> 
> I'm not 100% sure on the posted solutions here. I'm OK with the
> 'stream' being selfclosing and no longer being a stream, as every
> stanza is parsed on it's own anyway.
> 
> What I would vote for is probably kind of a mix of the 3 options above:
> 
> OPEN:  <stream:stream xmlns:stream="..." xmlns="jabber:client"
> id="abc123" xml:lang="en"/> OR  <stream:open ......../>
> CLOSE: <stream:stream/>  OR   <stream:close/>
> ERROR: <stream:error>...</stream:error>
> 
> So, change the opening and closing tags to be selfclosing and let
> everything else as it is.
> 
> Pros:
> * Only two "/"s moved around, everything else stays as it is and
> browsers can now parse everything.
> * Still looks like intended for XMPP streams
> * Works exactly like current implementations handle things anyway. (Of
> course implementations that just plain match the closing tag against
> </stream:stream> could actually parse it now)
This is entirely untrue. While it still looks almost like a normal XMPP
stream to a human, it has VERY different semantics. A self closing
stream tag, does just that. It immediately closes the stream. Prosody's
implementation currently will disconnect you if you send this. It does
not particularly care that you used a single tag to open and close the
stream instead of two tags.
I'm also rather surprised that you're fine with injecting all of the
namespaces, but would prefer if the server injected the single '/'
needed to make a stream start parseable on your behalf.

> * stream errors can stay the way they are
> 
> Cons:
> * Not a real stream any more (like all of the other solutions)
> * two stream:stream tags per stream. This could be "fixed" by either
> ** renaming ":stream" to ":open" in the closing tag and to ":close" in
> the closing tag. Doing this would be the clearest solution but would
> duplicate the meaning of stream:stream
> or
> ** just renaming the ":stream" to ":close" in the closing tag. This
> would avoid duplication of the meaning of stream:stream
> or
> ** just ignoring that there are two "stream:stream"s for one stream
> now. First one opens, second one closes.
> 
> Of this options I would probably prefer this one
> OPEN:  <stream:stream xmlns:stream="..." xmlns="jabber:client"
> id="abc123" xml:lang="en"/>
> CLOSE: <stream:close/>
> ERROR: <stream:error>...</stream:error>
> 
> Keep the stream:stream, make it selfclosing and replace the
> </stream:stream> by a <stream:close/>
> 
> 
>>
>> I have heard off-list from a few developers that dealing with the XMPP streams in WebSockets like raw TCP sockets is enough of a burden for them to have completely ignored the opening <stream:stream>.  I think it's worth doing something different for this reason.  I also think the target audience for the WebSocket-based transport client-side aren't (guaranteed to be) also writing code for dealing with raw TCP sockets.
>>
>> I had posted a strawman to the list in May; that might be worth considering (or not) < http://www.ietf.org/mail-archive/web/xmpp/current/msg02971.html >.
>>
> 
> This is basically like the solution I came up with, just with
> "ws:open" instead of "stream:stream" and "ws:close" instead of
> "stream:close", so also +1 for this.
> 

So there is something I think we had consensus on yesterday, that did
not make it into Matthew Wild's mail. And that is that some of the
solutions for #1 and #2 are mutually exclusive.

You managed to pick one such combination. If the stream start is
self-closing, namespaces are semantically not defined on the stanzas.
The element within which these namespaces are valid has already ended.
I'd be very uncomfortable if we were mandating to pretend that
everything that was defined in the stream header stays defined.

To me valid choices are really only:
Self-closing start/end + xmlns on every stanzas
or
normal XMPP stream (<stream:stream> stays open, no xmlns required on
stanzas)

Regards,
Florian

From lancestout@gmail.com  Wed Oct 23 18:25:57 2013
Return-Path: <lancestout@gmail.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA3411E80DC for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 18:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGuytLGJyMew for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 18:25:56 -0700 (PDT)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9404C11E819E for <xmpp@ietf.org>; Wed, 23 Oct 2013 18:25:53 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id wz7so1463842pbc.24 for <xmpp@ietf.org>; Wed, 23 Oct 2013 18:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=a5myBA/j3Tfd0AGFOZiiTHPvg/ln2XeY6bSB8MgWyi0=; b=AZs2MCnIrQmN7bDubdNqHfQjcbB6UvPi9hfOxubkUL5AbOne7OuCY8l8XTObc6Bl34 gEpwz8ZgOUU1DbPYyUVM7pVpHKSN36fNmIBaggDLmP1syy9TvczjgB0t2pldQO8tnZf8 /G+xkN7jK7ky9HPYxHPiZG6IhXunfA6NrAAV2tnDTgzeSEOo6YKMEsN+Ctx71bpCDKff YRb82bqBTFFxUq5MHUkoPIa06ajYcqtfgDxYbMBVk0AMWVJAakhQBaYe1cggXzgBFwUc 0Wut3Wqi+BVtkRTNPn1hjnie/L+IR/uZN67RnA7jN6ngwiKvSOSNqwq7ax0GB0VCTso9 N8jg==
X-Received: by 10.68.172.36 with SMTP id az4mr281804pbc.48.1382577953245; Wed, 23 Oct 2013 18:25:53 -0700 (PDT)
Received: from [10.0.1.3] (96-41-205-84.dhcp.elbg.wa.charter.com. [96.41.205.84]) by mx.google.com with ESMTPSA id yo2sm930866pab.8.2013.10.23.18.25.51 for <xmpp@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 18:25:52 -0700 (PDT)
From: Lance Stout <lancestout@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CFF344F3-BBAF-4A79-80A0-FC9A0134B31E"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <35373945-3139-400E-936D-412558846DAC@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Date: Wed, 23 Oct 2013 18:25:50 -0700
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com> <52682107.3030502@stpeter.im>
To: XMPP Working Group <xmpp@ietf.org>
In-Reply-To: <52682107.3030502@stpeter.im>
X-Mailer: Apple Mail (2.1816)
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2013 01:25:57 -0000

--Apple-Mail=_CFF344F3-BBAF-4A79-80A0-FC9A0134B31E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 23, 2013, at 12:18 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> IMHO it would be
> better to define something that's specific to the WebSocket binding,
> since we already have a precedent of defined something specific to the
> BOSH binding. Thus the streams construct is only for the TCP binding
> (which is the only place where it really makes sense, I think).

Whatever pattern we come up with here *will* be re-used for other =
transports such as
WebRTC data channels for doing P2P sessions, etc. Therefore, I am =
opposed=20
to making any namespace or element names be WebSocket specific.



Here's what I propose as the baseline "do nothing" approach that we need =
to beat=20
significantly if we do go with new protocol.

1. We update the requirements to say that stream open, error, and close =
must all be
   in their own frames. I'd argue this should be done regardless of if =
we keep the
   current open/close or mint new ones.

   Right now we allow an edge case of an open+error+close in one frame. =
Removing that=20
   actually removes the 'ugliest' bit of code in my implementation of =
the current spec.
 =20
   We had consensus on this at the Summit, although it might require =
some effort
   to ensure it is implemented properly in servers.

2. We strongly suggest that the 'stream' prefix be used, following what =
6120 states
   on the matter. It's actually not terribly much work to figure out the =
stream prefix,
   but it can involve regex that would only be needed for theoretical =
compatibility with some
   future server implementation that did this. IIRC, we had consensus on =
this at the Summit.

We can then suggest an implementation guide for environments lacking =
streaming parsers:

    StreamEnd =3D '</stream:stream>'
    StreamStart =3D ''

    on WebSocketMessage as Data do
      if (Data =3D=3D StreamEnd) then
         return emit('StreamEnded');
      end

      WrappedData =3D StreamStart + Data + StreamEnd;
      ParsedData =3D XMLParse(WrappedData);
=20
      if (!StreamStart) then
          StreamStart =3D Data;
          emit('StreamStarted', ParsedData);
      else
          emit('StreamData', ParsedData);
      end
    end

We already know when we have to send a new stream start signal, so we =
can reset StreamStart
to '' when needed at predictable, known times.



For completeness, if we make every frame standalone and with new =
start/end signals and
include xmlns and lang on every stanza:

    on WebSocketMessage as Data do
        ParsedData =3D XMLParse(Data);

        if (ParsedData.matches('urn:....', 'open') then
           emit('StreamStarted', ParsedData);
        else if (ParsedData.matches('urn:....', 'close') then
           emit('StreamEnded');
        else then
           emit('StreamData', ParsedData);
        end
    end

This is simpler, and an approach I could support. But, discounting blank =
lines and ends, there's only a=20
difference in 4 significant lines if I count correctly. Personally, I =
would rather require an extra 10=20
relatively simple lines in the client over changing the protocol and =
increasing the bandwidth costs.



I'm not dedicated to any particular approach here, and I've changed my =
mind *many* times in the last few=20
days. But right now I'm not convinced that the costs of new protocol and =
extra bandwidth are worth the=20
benefits since this issue is a very minor piece of the flow of =
processing and managing a WebSocket XMPP=20
stream properly (consider error handling, dispatching, etc).

-- Lance=

--Apple-Mail=_CFF344F3-BBAF-4A79-80A0-FC9A0134B31E
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM5jCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGqjCCBZKg
AwIBAgICL6UwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MzAzMTQwNTM1MTJaFw0xNTAzMTUyMjMyMzZaMIGMMRkwFwYDVQQNExBQTDAxbVhKMjhha3BBRzVj
MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjESMBAGA1UEBxMJS2VubmV3aWNrMRQw
EgYDVQQDEwtMYW5jZSBTdG91dDEjMCEGCSqGSIb3DQEJARYUbGFuY2VzdG91dEBnbWFpbC5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr0XNL4SLaoBR9y72zNo3eAefV7vk1UaEx
xML9TqPKZHV9gGxA/XO5YilACUU/l5In+8akri5djy/haORYEm5HwsR/R1vxhOK7cBEyXMCY41Vg
KyqnQPJlidJ0L5PMinz1cwo0wyLlh8WhxIBHBjgLbA8XAoDC7FL6KzDq+qoJdsBbehu4W9fVscRr
T7XeM41zHjc7FqJOD8I2n9Z5CIlEeWwaIEZO0HpxOlcbD5EGVaC7Wbji/nEOuQ1OI6iGId/7Xakg
JrGfjSg1wQ5dXIBMzbSZmw3B6WmDdNgpCzHYL+QrCLrFenO0u2D6ZR/dZQgIkPRhL6I7PqniJ3FN
0hJpAgMBAAGjggMSMIIDDjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFggdjTZDgsglI1DBpZiCB24Ub+ZMB8GA1UdIwQYMBaA
FK5Vg2/sMcq59x36r2sx88gd46y7MFcGA1UdEQRQME6BFGxhbmNlc3RvdXRAZ21haWwuY29tgRRs
YW5jZXN0b3V0QGdtYWlsLmNvbYEObGFuY2VAbGFuY2UuaW2BEGxhbmNlQGFuZHlldC5uZXQwggFM
BgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBh
Y2NvcmRpbmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0
YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug
aW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w
LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH
AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIv
Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu
Y2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v
MA0GCSqGSIb3DQEBBQUAA4IBAQALnAVqIrddlyGYqOAb4TfJ25u3sOtC352yAF7VaQdhkV/Z7Rum
OPpsEN7rwLfHOphYhafI4IxKy39NZbFBjzzcW8Kx6OJ1L/eDEW5Dbt1XzaBF4VVM1/DZyg/l3C0N
9/YrumhcgdSUgxLL2d/GzEk1dNTcZLpLJABf6L1W5RszU4HSPyVppLzYVVq5yLwmKnlIcnDjEdMr
jmsFq8b0Duk1j05IE2KBiWNy/Q0H9Hj/943/rvQOx7464jzuEGkWYO8AU7Nmq3h2DLoo8GECFwxy
e7rSL0o3KFkAQHC0YE/8GbaT05Jo7xnF/9X/IOWd0rSvBmTVkreGARQywViv35eCMYIDbDCCA2gC
AQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz
cyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwCQYFKw4DAhoFAKCCAa0wGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDI0MDEyNTUxWjAjBgkq
hkiG9w0BCQQxFgQUKYm5G0k880wxvaxSxyu2uor5++AwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg
SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAh/Jj+JW7zVtl0k4X
SL/AoUYPB6Ao5orbNCesfs6wyHnk+t/1y8yMH0bKDkJ8H6o4/sUZK/YZbZSVAx1CEMZwnpgwb7aB
0npzZVFSWH+hVhsvXkTjP9K8E3mi2hU99yCk2yk+ck6I/REL8nlQzkAZ6XOd5MGpWuo0talDE8xY
2S8IOEMumUIPB/Pd0LmuNaWPk0sgXHZljM0dgHMOKlQxQwlVUPjJKwNSBanoohOGKHYTC2vlPAmM
gqt8IAr1nHABeaBsEfhWmz4BcdYDBiEosMUpI93gwaIk5R7aK47P8w1lTt0Fi1tf2eglC7y7ixrs
hH0CYpk23/vKn4Stg6eeEwAAAAAAAA==

--Apple-Mail=_CFF344F3-BBAF-4A79-80A0-FC9A0134B31E--

From stpeter@stpeter.im  Wed Oct 23 20:29:58 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D502611E810D for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 20:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.187
X-Spam-Level: 
X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peWZXk+gdkMe for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 20:29:54 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B16AA11E8106 for <xmpp@ietf.org>; Wed, 23 Oct 2013 20:29:52 -0700 (PDT)
Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AF7004100F; Wed, 23 Oct 2013 21:36:36 -0600 (MDT)
Message-ID: <5268942E.6010205@stpeter.im>
Date: Wed, 23 Oct 2013 21:29:50 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Lance Stout <lancestout@gmail.com>,  XMPP Working Group <xmpp@ietf.org>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>	<BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com>	<52682107.3030502@stpeter.im> <35373945-3139-400E-936D-412558846DAC@gmail.com>
In-Reply-To: <35373945-3139-400E-936D-412558846DAC@gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2013 03:29:58 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/2013 07:25 PM, Lance Stout wrote:
> On Oct 23, 2013, at 12:18 PM, Peter Saint-Andre
> <stpeter@stpeter.im> wrote:
> 
>> IMHO it would be better to define something that's specific to
>> the WebSocket binding, since we already have a precedent of
>> defined something specific to the BOSH binding. Thus the streams
>> construct is only for the TCP binding (which is the only place
>> where it really makes sense, I think).
> 
> Whatever pattern we come up with here *will* be re-used for other
> transports such as WebRTC data channels for doing P2P sessions,
> etc. Therefore, I am opposed to making any namespace or element
> names be WebSocket specific.
> 
> 
> 
> Here's what I propose as the baseline "do nothing" approach that we
> need to beat significantly if we do go with new protocol.
> 
> 1. We update the requirements to say that stream open, error, and
> close must all be in their own frames. I'd argue this should be
> done regardless of if we keep the current open/close or mint new
> ones.

That strikes me as quite reasonable.

> Right now we allow an edge case of an open+error+close in one
> frame. Removing that actually removes the 'ugliest' bit of code in
> my implementation of the current spec.
> 
> We had consensus on this at the Summit, although it might require
> some effort to ensure it is implemented properly in servers.
> 
> 2. We strongly suggest that the 'stream' prefix be used, following
> what 6120 states on the matter. It's actually not terribly much
> work to figure out the stream prefix, but it can involve regex that
> would only be needed for theoretical compatibility with some future
> server implementation that did this. IIRC, we had consensus on this
> at the Summit.

Do you mean <stream:stream xmlns='http://etherx.jabber.org/streams'/>
or something like <stream:open/> with a different namespace?

> We can then suggest an implementation guide for environments
> lacking streaming parsers:
> 
> StreamEnd = '</stream:stream>' StreamStart = ''
> 
> on WebSocketMessage as Data do if (Data == StreamEnd) then return
> emit('StreamEnded'); end
> 
> WrappedData = StreamStart + Data + StreamEnd; ParsedData =
> XMLParse(WrappedData);
> 
> if (!StreamStart) then StreamStart = Data; emit('StreamStarted',
> ParsedData); else emit('StreamData', ParsedData); end end
> 
> We already know when we have to send a new stream start signal, so
> we can reset StreamStart to '' when needed at predictable, known
> times.

Agreed.

> For completeness, if we make every frame standalone and with new
> start/end signals and include xmlns and lang on every stanza:
> 
> on WebSocketMessage as Data do ParsedData = XMLParse(Data);
> 
> if (ParsedData.matches('urn:....', 'open') then 
> emit('StreamStarted', ParsedData); else if
> (ParsedData.matches('urn:....', 'close') then emit('StreamEnded'); 
> else then emit('StreamData', ParsedData); end end
> 
> This is simpler, and an approach I could support. But, discounting
> blank lines and ends, there's only a difference in 4 significant
> lines if I count correctly. Personally, I would rather require an
> extra 10 relatively simple lines in the client over changing the
> protocol and increasing the bandwidth costs.

I do think that bandwidth usage is not insignificant here.

> I'm not dedicated to any particular approach here, and I've changed
> my mind *many* times in the last few days. But right now I'm not
> convinced that the costs of new protocol and extra bandwidth are
> worth the benefits since this issue is a very minor piece of the
> flow of processing and managing a WebSocket XMPP stream properly
> (consider error handling, dispatching, etc).

I promise to give it some more thought, too...

/psa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSaJQtAAoJEOoGpJErxa2p4RoQAIq+foqVgn5HdRvR6F2h88ST
OAMsNbkulc2bnZ2q99S6Vh+M0O3YkS8dUj2zkd8fEEQB13V3ZuQozPMp/x0aW8Mo
K5/a/CZn8agPqSHa3WBRyIg2YwLTkuzoKzBNOgwpgpOHQh6x98YkOopKZQ+GevPm
9XzhNiEm0caYVoKv4L9U7nWPwW6tfUvzCmiGww1fIA7xaxEzdgtqtFsAzgDM54/Q
Khnfm9nEiS71Fd/V3WY0vt1UvKO+tGDA2DCRU0TPPr/x704iTrnRsBG1HIFBnGIG
ojB0Xi7G50b6M/CsoB+7Jcpdli4KlYJvoD/E1Ksn+qgeIOwElzyGIPrfdeTSjb3P
yEWobaFydUhWV5iLreJPjNbR/JQ28vU/ekoC9WICFscPKV1dL8B9jd1Yi3/GbOxD
f7LFtJJ5HP/1/VfHH6Ca+US0x2YJUTaa0Ip5IgSjnzN0OE9ORWB1Cb4+zxsgRhee
p/oZxHeke//fz0ilAQKykkbjG+Uqzv8DevRf4r2YraVj/ANI+v2Oc/CRnWAW4Kfi
DaVArCT5qA8EwmRyYDy8W/fEhJQqQW1RxSalSYQcVovH5nIpP+yN/Hy6Bo2TiFsg
iIT+6mCZ/xIcaUT0AAYLDx+M4Iqi74nfEu5tDRq9k1EHHuEty4bhyJBMsV7+znNG
cUwnMhytzhx0OM6lxsRU
=HgTT
-----END PGP SIGNATURE-----

From lancestout@gmail.com  Wed Oct 23 20:49:32 2013
Return-Path: <lancestout@gmail.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7331611E8113 for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 20:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpTTkATydSXt for <xmpp@ietfa.amsl.com>; Wed, 23 Oct 2013 20:49:31 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id A78B211E80FC for <xmpp@ietf.org>; Wed, 23 Oct 2013 20:49:31 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id x10so1567215pdj.23 for <xmpp@ietf.org>; Wed, 23 Oct 2013 20:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=c325ttkZ2oTcflypdGERl1P72Vq+oyR5CUn5y1FTZvo=; b=ydQmQ9fmIZRYvgn9Y//W62gQpCcHXVu74db+PK5q/4ofVFNRRmUGcxoSewqeLmHFqm HlWPRYqnLL4x14K56eGUN/XcuNQpYn3N4R+2HlYrL5bUUrbWDf8EmL2DwubL/CsDL5Gc GMQQLU4bt7yEK60Lerk0OdqI4k+7MEcC9D0hpOMUGTd2yioOtvCkmoUWcGCj0E36h8iE CQD81M/XBLPgakolQm16vZHXYXeDljLbdAnL+eO1d7SS3QHXLXHf/TtwV+S/CJMwd7zx Qx6yPB4k+CO9fVFxNPTwpv6zjQ0mAUUHFFGd0qGARR2+hVRaZE8Ozy3nbFqaJ+HqqFYA +EEA==
X-Received: by 10.68.215.4 with SMTP id oe4mr34940pbc.198.1382586571022; Wed, 23 Oct 2013 20:49:31 -0700 (PDT)
Received: from [10.0.1.3] (96-41-205-84.dhcp.elbg.wa.charter.com. [96.41.205.84]) by mx.google.com with ESMTPSA id va8sm8003749pbc.16.2013.10.23.20.49.29 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 20:49:29 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_EA3134E1-A65A-497F-8F33-FDA742FD6BA7"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Lance Stout <lancestout@gmail.com>
In-Reply-To: <5268942E.6010205@stpeter.im>
Date: Wed, 23 Oct 2013 20:49:28 -0700
Message-Id: <9ECC4E55-2529-4FDE-A2A8-431CFBC3BBC0@gmail.com>
References: <CAJt9-x5RO1rmniQm=4ArPJJ8wYCCxPBFnE4gMKVKLu-bjFUyeg@mail.gmail.com>	<BF7E36B9C495A6468E8EC573603ED9411EFA08DE@xmb-aln-x11.cisco.com>	<52682107.3030502@stpeter.im> <35373945-3139-400E-936D-412558846DAC@gmail.com> <5268942E.6010205@stpeter.im>
To: XMPP Working Group <xmpp@ietf.org>
X-Mailer: Apple Mail (2.1816)
Subject: Re: [xmpp] Websockets: streams or not streams?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2013 03:49:32 -0000

--Apple-Mail=_EA3134E1-A65A-497F-8F33-FDA742FD6BA7
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Oct 23, 2013, at 8:29 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

>> 2. We strongly suggest that the 'stream' prefix be used, following
>> what 6120 states on the matter. It's actually not terribly much
>> work to figure out the stream prefix, but it can involve regex that
>> would only be needed for theoretical compatibility with some future
>> server implementation that did this. IIRC, we had consensus on this
>> at the Summit.
> 
> Do you mean <stream:stream xmlns='http://etherx.jabber.org/streams'/>
> or something like <stream:open/> with a different namespace?


I meant <stream:stream xmlns:stream='http://etherx.jabber.org/streams' ...>.

With RFC 6120 4.8.5, implementations are allowed to only accept 'stream' as
the namespace prefix for the stream element. If we allow WebSocket clients
to make that same assumption, we simplify the work for clients using the 
existing protocol as is.

It's not a huge deal if we allow the prefix to be arbitrary or non-existant,
however. IIRC it only added 2 lines to the stream start case to pick it out 
and create what the closing stream tag token should be. But consensus at the
summit was that it wasn't needed in practice.

-- Lance
--Apple-Mail=_EA3134E1-A65A-497F-8F33-FDA742FD6BA7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM5jCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGqjCCBZKg
AwIBAgICL6UwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MzAzMTQwNTM1MTJaFw0xNTAzMTUyMjMyMzZaMIGMMRkwFwYDVQQNExBQTDAxbVhKMjhha3BBRzVj
MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjESMBAGA1UEBxMJS2VubmV3aWNrMRQw
EgYDVQQDEwtMYW5jZSBTdG91dDEjMCEGCSqGSIb3DQEJARYUbGFuY2VzdG91dEBnbWFpbC5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr0XNL4SLaoBR9y72zNo3eAefV7vk1UaEx
xML9TqPKZHV9gGxA/XO5YilACUU/l5In+8akri5djy/haORYEm5HwsR/R1vxhOK7cBEyXMCY41Vg
KyqnQPJlidJ0L5PMinz1cwo0wyLlh8WhxIBHBjgLbA8XAoDC7FL6KzDq+qoJdsBbehu4W9fVscRr
T7XeM41zHjc7FqJOD8I2n9Z5CIlEeWwaIEZO0HpxOlcbD5EGVaC7Wbji/nEOuQ1OI6iGId/7Xakg
JrGfjSg1wQ5dXIBMzbSZmw3B6WmDdNgpCzHYL+QrCLrFenO0u2D6ZR/dZQgIkPRhL6I7PqniJ3FN
0hJpAgMBAAGjggMSMIIDDjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFggdjTZDgsglI1DBpZiCB24Ub+ZMB8GA1UdIwQYMBaA
FK5Vg2/sMcq59x36r2sx88gd46y7MFcGA1UdEQRQME6BFGxhbmNlc3RvdXRAZ21haWwuY29tgRRs
YW5jZXN0b3V0QGdtYWlsLmNvbYEObGFuY2VAbGFuY2UuaW2BEGxhbmNlQGFuZHlldC5uZXQwggFM
BgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBh
Y2NvcmRpbmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0
YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug
aW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w
LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH
AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIv
Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu
Y2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v
MA0GCSqGSIb3DQEBBQUAA4IBAQALnAVqIrddlyGYqOAb4TfJ25u3sOtC352yAF7VaQdhkV/Z7Rum
OPpsEN7rwLfHOphYhafI4IxKy39NZbFBjzzcW8Kx6OJ1L/eDEW5Dbt1XzaBF4VVM1/DZyg/l3C0N
9/YrumhcgdSUgxLL2d/GzEk1dNTcZLpLJABf6L1W5RszU4HSPyVppLzYVVq5yLwmKnlIcnDjEdMr
jmsFq8b0Duk1j05IE2KBiWNy/Q0H9Hj/943/rvQOx7464jzuEGkWYO8AU7Nmq3h2DLoo8GECFwxy
e7rSL0o3KFkAQHC0YE/8GbaT05Jo7xnF/9X/IOWd0rSvBmTVkreGARQywViv35eCMYIDbDCCA2gC
AQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz
cyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwCQYFKw4DAhoFAKCCAa0wGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDI0MDM0OTI5WjAjBgkq
hkiG9w0BCQQxFgQUl88lY/lliG5tFyO6BDpkD59j4SEwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg
SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAkDIOquzWWLzGLXH5
sJAnKyHjBDRH4g/BOc5V6HMhO3Rwvhwbgwt0n9bvUTDQkffdnI/qdV7gSHY78XNm7KiGpkMhMQU7
77xThpgyYlEgRbgTLFQvZvI36m1bvZW5l7Skn9NsedCQDD9pdTc8MDRkrFulBpM14I1laqfP5VHq
d4WETTmWpV980k5t/8KfZA6Zj02b+WG1/YNQa49b16/K+dP2/0apZW6ezpUUxOn8wLMOyrASN45c
U0ccD9xkSpXz89toE4cNJ3ZJ+jyqbx+rYTh89058YBzdWV7rkAQvz2+ljNNRZpzamOlyhDX5YE6O
c4ieWYTUtQ1JeBCCpRMY2wAAAAAAAA==

--Apple-Mail=_EA3134E1-A65A-497F-8F33-FDA742FD6BA7--