From lance@andyet.net Sat May 18 14:49:35 2013 Return-Path: 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 AAFFB21F8AF7 for ; Sat, 18 May 2013 14:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=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 vUE0HX5-6iqs for ; Sat, 18 May 2013 14:49:31 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0963321F8ADF for ; Sat, 18 May 2013 14:49:30 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id p11so4299605pdj.40 for ; Sat, 18 May 2013 14:49:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:message-id:mime-version:subject:date :references:cc:to:x-mailer:x-gm-message-state; bh=CI0mYup3AvkpayHccxkbyG7JBhW/1ropxOsarY4jmZw=; b=cyfwRZjBZVoObq/L/zRUJd/9Y3K7Q05GzWXAr1BlfJIxVT4IzHBYVasbEt7jMl10Ev RJzopFlyk/u7IiLMlFcg0f+FzV0QCdMwXAsGqXT9yXpH6ifJsQpY7FPBpSqHu8IMJ1km ms9uCJIL+y+G8ymKhwFOzNLQahzm2wvDpI/QTGKjlGNL+QicsM+11EmCXZmoDCHJzDPZ mOEdXjszwuwcwFFsJ/DHLfRCOnwnz8WBWZdbKskkm+Cj8BCuHIX3qkmmOUBsp7b37jxg WQrWIOyAEgSmIx7RWNpZ0OH3iMa969P1GeL8dfhyx01DPHUjQIAId5QSm1TXwmVv98F2 6fhQ== X-Received: by 10.68.224.65 with SMTP id ra1mr53580166pbc.103.1368913770636; Sat, 18 May 2013 14:49:30 -0700 (PDT) Received: from [10.0.1.190] (71-95-126-13.dhcp.mdfd.or.charter.com. [71.95.126.13]) by mx.google.com with ESMTPSA id xu10sm18403002pab.3.2013.05.18.14.49.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 May 2013 14:49:29 -0700 (PDT) From: Lance Stout Content-Type: multipart/signed; boundary="Apple-Mail=_0C1E75C4-14A3-4FDA-986E-B2E6E663BF5B"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Sat, 18 May 2013 14:49:28 -0700 References: <20130518204707.18094.87013.idtracker@ietfa.amsl.com> To: XMPP X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnmrkaBTTs9l8Od/5NUMoGkUHTzmmLuSoVnGIS7hdGNMwSnhb9GZ6qEcoAK75P6hDXT/e7M Cc: XMPP Standards Subject: [xmpp] New version of XMPP over Websocket draft X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 21:49:35 -0000 --Apple-Mail=_0C1E75C4-14A3-4FDA-986E-B2E6E663BF5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've updated the XMPP over WebSocket draft to include: - Several examples for establishing the WebSocket connection, closing = the connection, and performing a stream restart. - Adjust language for pings to note that XEP-0198 provides a keepalive pinging mechanism as well. - Modify language on closing the connection, noting that the XMPP = streams should be explicitly closed before closing the WebSocket connection. - Added recommendation to use XEP-0198 stream management. - Added note that a server should keep the session alive (based on = policy) if a connection is closed without closing the streams (XEP-0198). - Added section on using XEP-0156 to discover the WebSocket connection=20= endpoint. I've emailed the XMPP Registrar to register the _xmpp-client-websocket connection method name. I've also asked the = XMPP standards list about creating a .well-known/ document to supplement = the method defined in XEP-0156 as browser based clients that will use = the WebSocket transport can't make the necessary DNS calls. There do remain several issues that have been discussed at the previous IETF meeting and the XSF summit last February: - How to handle instructing the client to connect to a different endpoint (e.g., some see-other-uri error condition). If we can define a new stream error condition here, then that would be=20 preferable. - SASL EXTERNAL. What qualifies? Would a user session cookie (normally sufficient for HTTP requests) be acceptable? If a user session cookie is provided and authorized by the server before accepting the WebSocket connection, is SASL auth still needed or can a client request binding immediately? (similar to the use of pre-binding in = BOSH) - Compression. As we are using text frames, we can't compress the XMPP traffic directly. However, there are other I-Ds working on enabling compression for WebSocket message data. Should this be called out = now, or wait until those I-Ds have progressed? - IANA consideration: It's fully possible, and maybe even preferable, = for=20 a server to provide both BOSH and WebSocket endpoints on port 5280.=20= Should we update the IANA registration for 5280 to be named=20 something more generic than xmpp-bosh? Other suggestions had been discussed that, after having personally=20 implemented an XMPP over WebSocket client, I don't find sufficiently=20 compelling for changing the protocol: - Creating a new stream start/end marker - Requiring all in-scope namespaces to be declared on top-level stream = child elements Specifically, here's the relevant excerpt to handle the above: data =3D data.trim(); // Ignore any prelude/processing instructions data =3D data.replace(/^(\s*<\?.*\?>\s*)*/, ''); if (data.match(self.streamEnd)) { self.emit('stream:end'); return self.disconnect(); } else if (self.hasStream) { // Wrap the data with the saved stream start/end tags to // preserve namespace and xml:lang contexts try { streamData =3D parse(wrap(data)); } catch (e) { // Received invalid XML from the server return self.disconnect(); } self.emit('stream:data', streamData); } else { // Inspect start of stream element to get NS prefix name var parts =3D data.match(/^<(\S+:)?(\S+) /); self.streamStart =3D data; self.streamEnd =3D ''; try { streamData =3D parse(data + self.streamEnd); } catch (e) { try { // Received stream error while trying to open the stream streamData =3D parse(data); } catch (e2) { // Received invalid XML from the server return self.disconnect(); } } self.hasStream =3D true; self.emit('stream:start', streamData); } -- Lance Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-moffitt-xmpp-over-websocket-03.txt > Date: May 18, 2013 1:47:07 PM PDT > To: Eric Cestari , Jack Moffitt , = Lance Stout >=20 >=20 > A new version of I-D, draft-moffitt-xmpp-over-websocket-03.txt > has been successfully submitted by Lance Stout and posted to the > IETF repository. >=20 > Filename: draft-moffitt-xmpp-over-websocket > Revision: 03 > Title: An XMPP Sub-protocol for WebSocket > Creation date: 2013-05-18 > Group: Individual Submission > Number of pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-moffitt-xmpp-over-websocket-03.t= xt > Status: = http://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket > Htmlized: = http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-moffitt-xmpp-over-websocket-03 >=20 > Abstract: > This document defines a binding for the XMPP protocol over a > WebSocket transport layer. A WebSocket binding for XMPP provides > higher performance than the current HTTP binding for XMPP. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_0C1E75C4-14A3-4FDA-986E-B2E6E663BF5B 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE4MjE0OTI4WjAjBgkq hkiG9w0BCQQxFgQUaKzfWZMDz/l3zqmgoxut8RrVUSswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAQYSm3tFwxu9xZiEE U6tSu7WdVW1fEk/WP5OyaoSzdXp6RM4h4HpphLNeC5PpK7ylHGigTO/AK7Cd5kOnUeBWWerymOQm Qudkmex/7Ngu2mUfNPMv82sOj5tvYt08Lv//KNYOXmtCtPoF2IIzS2wmaSesVRxJdMVLEwFs1z4U lum4/GKtk7oNG3gJC9AvzIE7AhXE+Xx7nVJC5zUBOaGp14ttwH1R1QvlEH5oFNn3SMyQVHl/zK1c 8VlhcwVWnuxqg6wpOAussE/+m0MlRzfVvbmO1k7eNlUVhILwWwsZmZ5uNyIbF8s6UZ5RID8SsTlD LqlzisvJECni3o+ejDjE1wAAAAAAAA== --Apple-Mail=_0C1E75C4-14A3-4FDA-986E-B2E6E663BF5B-- From ben@nostrum.com Tue May 21 13:00:31 2013 Return-Path: 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 48B3C11E812D for ; Tue, 21 May 2013 13:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, 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 g6v1qtts1Zgl for ; Tue, 21 May 2013 13:00:30 -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 4681111E811D for ; Tue, 21 May 2013 13:00:30 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4LK0KoB002622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 15:00:20 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ben Campbell In-Reply-To: Date: Tue, 21 May 2013 15:00:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130518204707.18094.87013.idtracker@ietfa.amsl.com> To: XMPP Group X-Mailer: Apple Mail (2.1503) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: Re: [xmpp] New version of XMPP over Websocket draft X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:00:31 -0000 (as XMPP co-chair) Thanks, Lance! I'd like to remind everyone that XMPP over WebSocket is on our charter. = The chairs will shortly call the question about whether this draft = should be adopted as a working group draft for that work. I encourage = everyone to take a look at the update and discuss it, and think about = whether it's on the right track. Thanks! Ben. On May 18, 2013, at 4:49 PM, Lance Stout wrote: > I've updated the XMPP over WebSocket draft to include: >=20 > - Several examples for establishing the WebSocket connection, closing = the > connection, and performing a stream restart. > - Adjust language for pings to note that XEP-0198 provides a keepalive > pinging mechanism as well. > - Modify language on closing the connection, noting that the XMPP = streams > should be explicitly closed before closing the WebSocket = connection. > - Added recommendation to use XEP-0198 stream management. > - Added note that a server should keep the session alive (based on = policy) > if a connection is closed without closing the streams (XEP-0198). > - Added section on using XEP-0156 to discover the WebSocket connection=20= > endpoint. I've emailed the XMPP Registrar to register the > _xmpp-client-websocket connection method name. I've also asked the = XMPP > standards list about creating a .well-known/ document to supplement = the > method defined in XEP-0156 as browser based clients that will use = the > WebSocket transport can't make the necessary DNS calls. >=20 >=20 > There do remain several issues that have been discussed at the = previous > IETF meeting and the XSF summit last February: >=20 > - How to handle instructing the client to connect to a different > endpoint (e.g., some see-other-uri error condition). If we can > define a new stream error condition here, then that would be=20 > preferable. >=20 > - SASL EXTERNAL. What qualifies? Would a user session cookie (normally > sufficient for HTTP requests) be acceptable? If a user session > cookie is provided and authorized by the server before accepting > the WebSocket connection, is SASL auth still needed or can a client > request binding immediately? (similar to the use of pre-binding in = BOSH) >=20 > - Compression. As we are using text frames, we can't compress the XMPP > traffic directly. However, there are other I-Ds working on enabling > compression for WebSocket message data. Should this be called out = now, > or wait until those I-Ds have progressed? >=20 > - IANA consideration: It's fully possible, and maybe even preferable, = for=20 > a server to provide both BOSH and WebSocket endpoints on port 5280.=20= > Should we update the IANA registration for 5280 to be named=20 > something more generic than xmpp-bosh? >=20 >=20 > Other suggestions had been discussed that, after having personally=20 > implemented an XMPP over WebSocket client, I don't find sufficiently=20= > compelling for changing the protocol: >=20 > - Creating a new stream start/end marker > - Requiring all in-scope namespaces to be declared on top-level stream = child elements >=20 > Specifically, here's the relevant excerpt to handle the above: >=20 > data =3D data.trim(); > // Ignore any prelude/processing instructions > data =3D data.replace(/^(\s*<\?.*\?>\s*)*/, ''); > if (data.match(self.streamEnd)) { > self.emit('stream:end'); > return self.disconnect(); > } else if (self.hasStream) { > // Wrap the data with the saved stream start/end tags to > // preserve namespace and xml:lang contexts > try { > streamData =3D parse(wrap(data)); > } catch (e) { > // Received invalid XML from the server > return self.disconnect(); > } > self.emit('stream:data', streamData); > } else { > // Inspect start of stream element to get NS prefix name > var parts =3D data.match(/^<(\S+:)?(\S+) /); > self.streamStart =3D data; > self.streamEnd =3D ''; >=20 > try { > streamData =3D parse(data + self.streamEnd); > } catch (e) { > try { > // Received stream error while trying to open the = stream > streamData =3D parse(data); > } catch (e2) { > // Received invalid XML from the server > return self.disconnect(); > } > } >=20 > self.hasStream =3D true; > self.emit('stream:start', streamData); > } >=20 >=20 >=20 >=20 > -- Lance >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-moffitt-xmpp-over-websocket-03.txt >> Date: May 18, 2013 1:47:07 PM PDT >> To: Eric Cestari , Jack Moffitt = , Lance Stout >>=20 >>=20 >> A new version of I-D, draft-moffitt-xmpp-over-websocket-03.txt >> has been successfully submitted by Lance Stout and posted to the >> IETF repository. >>=20 >> Filename: draft-moffitt-xmpp-over-websocket >> Revision: 03 >> Title: An XMPP Sub-protocol for WebSocket >> Creation date: 2013-05-18 >> Group: Individual Submission >> Number of pages: 9 >> URL: = http://www.ietf.org/internet-drafts/draft-moffitt-xmpp-over-websocket-03.t= xt >> Status: = http://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket >> Htmlized: = http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-03 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-moffitt-xmpp-over-websocket-03 >>=20 >> Abstract: >> This document defines a binding for the XMPP protocol over a >> WebSocket transport layer. A WebSocket binding for XMPP provides >> higher performance than the current HTTP binding for XMPP. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From florob@babelmonkeys.de Tue May 28 13:54:37 2013 Return-Path: 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 E4BBA21E8092 for ; Tue, 28 May 2013 13:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 f3yFuYkwCpap for ; Tue, 28 May 2013 13:54:36 -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 C888421E8094 for ; Tue, 28 May 2013 13:54:21 -0700 (PDT) Received: from [2001:6f8:91c:0:3e97:eff:fe0f:f4d] by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1UhQuR-00024D-AO for xmpp@ietf.org; Tue, 28 May 2013 22:54:19 +0200 Message-ID: <51A51977.8020005@babelmonkeys.de> Date: Tue, 28 May 2013 22:54:15 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: xmpp@ietf.org References: <20130518204707.18094.87013.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] New version of XMPP over Websocket draft X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 20:54:37 -0000 Hey Lance, good to see you working on this. Some comments inline. Am 18.05.2013 23:49, schrieb Lance Stout: > I've updated the XMPP over WebSocket draft to include: > > - Several examples for establishing the WebSocket connection, closing the > connection, and performing a stream restart. > - Adjust language for pings to note that XEP-0198 provides a keepalive > pinging mechanism as well. > - Modify language on closing the connection, noting that the XMPP streams > should be explicitly closed before closing the WebSocket connection. > - Added recommendation to use XEP-0198 stream management. I feel that this, as well as the recommendation to use XMPP Ping, is good to have. However, I'm not sure having this at the RECOMMENDED level is actually sensible. I would much rather have this as OPTIONAL along with some more information on why this is useful/important to implement. > - Added note that a server should keep the session alive (based on policy) > if a connection is closed without closing the streams (XEP-0198). > - Added section on using XEP-0156 to discover the WebSocket connection > endpoint. I've emailed the XMPP Registrar to register the > _xmpp-client-websocket connection method name. I've also asked the XMPP > standards list about creating a .well-known/ document to supplement the > method defined in XEP-0156 as browser based clients that will use the > WebSocket transport can't make the necessary DNS calls. > > > There do remain several issues that have been discussed at the previous > IETF meeting and the XSF summit last February: > > - How to handle instructing the client to connect to a different > endpoint (e.g., some see-other-uri error condition). If we can > define a new stream error condition here, then that would be > preferable. > > - SASL EXTERNAL. What qualifies? Would a user session cookie (normally > sufficient for HTTP requests) be acceptable? If a user session > cookie is provided and authorized by the server before accepting > the WebSocket connection, is SASL auth still needed or can a client > request binding immediately? (similar to the use of pre-binding in BOSH) > IMHO, if the server is offering SASL EXTERNAL that means "I have some means of verifying your identity on another protocol level". I think it is sensible that a server would offer EXTERNAL if it saw a e.g. a session cookie. I would prefer to keep the SASL auth step, to keep this in line with the usual XMPP flow. > - Compression. As we are using text frames, we can't compress the XMPP > traffic directly. However, there are other I-Ds working on enabling > compression for WebSocket message data. Should this be called out now, > or wait until those I-Ds have progressed? > > - IANA consideration: It's fully possible, and maybe even preferable, for > a server to provide both BOSH and WebSocket endpoints on port 5280. > Should we update the IANA registration for 5280 to be named > something more generic than xmpp-bosh? > Interesting question. I think that reservation might have become somewhat bogus over time. 5280 is mostly a "HTTP service provided by a XMPP server". E.g. prosody has a general HTTP API which is used to provide different things, from web-admin, over chat logs to BOSH and websockets all on port 5280. IIRC ejabberd's web-admin is on 5280, too. Additionally BOSH is/was often proxied to port 80 to avoid same-origin policy issues. It might be worthwhile updating the registration, I'm not sure what a decent description (that actually warrants having a dedicated port) would be though. > Other suggestions had been discussed that, after having personally > implemented an XMPP over WebSocket client, I don't find sufficiently > compelling for changing the protocol: > > - Creating a new stream start/end marker > - Requiring all in-scope namespaces to be declared on top-level stream child elements > > Specifically, here's the relevant excerpt to handle the above: > > [snip bunch of javascript] I disagree, that this is not compelling (Well, I'm sort of bound to, since those are my suggestions), particularly considering your code example. With those two changes in place the equivalent client code would amount to: parser = new DOMParser(); stanza = parser.parseFromString(message, "application/xml"); On top of that it's a 13 line change in Prosody's mod_websocket. I think it fits our simple client, complex server model a lot better to have the complexity for making this easy to parse in a web-browser on the server side. Regards, Florian > > > > -- Lance From mwild1@gmail.com Wed May 29 05:55:45 2013 Return-Path: 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 DAF9C21F88B6 for ; Wed, 29 May 2013 05:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 uB2KCsc9mxI6 for ; Wed, 29 May 2013 05:55:45 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CE92621F89EB for ; Wed, 29 May 2013 05:55:44 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id 12so6156660vbf.4 for ; Wed, 29 May 2013 05:55:44 -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=0VDOyYMI6VsA2YOyfMh4XkqhUyrbXO50BbTs+J28YCQ=; b=lW+1dKplubbKWh1MW+cBTl7HPHErxnzfnWSE74rgzOevfB1IHd9wXWOc/gPve8fm2b UK9AqDDbHglBqhElr+BRbVeMH58W1YOZfKTIvlt6DmzbvMDVAGoQyrksRy6NxaozJ0q3 co72DayxU60BS1fZojsDo+mSH3pAMpTp4XXPhrtDRxPel9L5SUJSH5QSJ0q2x70BqyDG Q70jZl9xuCD9UIPH+Zn5coM1djORkPnkibmlo418cm6ek+qEbYve8cp7dxgX+ipHke0E 9G//vbMu5E0OSXX1J2Grtm8L9DXO7pjVhk6Rxx9Z8NrwOnXntQo98c9rtRqwz/1sgmdj R1RA== X-Received: by 10.220.167.69 with SMTP id p5mr1382794vcy.57.1369832144280; Wed, 29 May 2013 05:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.133 with HTTP; Wed, 29 May 2013 05:55:24 -0700 (PDT) In-Reply-To: <51A51977.8020005@babelmonkeys.de> References: <20130518204707.18094.87013.idtracker@ietfa.amsl.com> <51A51977.8020005@babelmonkeys.de> From: Matthew Wild Date: Wed, 29 May 2013 13:55:24 +0100 Message-ID: To: Florian Zeitz Content-Type: text/plain; charset=UTF-8 Cc: XMPP Working Group Subject: Re: [xmpp] New version of XMPP over Websocket draft X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:55:46 -0000 On 28 May 2013 21:54, Florian Zeitz wrote: > Hey Lance, > good to see you working on this. Some comments inline. > > Am 18.05.2013 23:49, schrieb Lance Stout: >> I've updated the XMPP over WebSocket draft to include: >> >> - Several examples for establishing the WebSocket connection, closing the >> connection, and performing a stream restart. >> - Adjust language for pings to note that XEP-0198 provides a keepalive >> pinging mechanism as well. >> - Modify language on closing the connection, noting that the XMPP streams >> should be explicitly closed before closing the WebSocket connection. >> - Added recommendation to use XEP-0198 stream management. > I feel that this, as well as the recommendation to use XMPP Ping, is > good to have. > However, I'm not sure having this at the RECOMMENDED level is actually > sensible. I would much rather have this as OPTIONAL along with some more > information on why this is useful/important to implement. > >> - Added note that a server should keep the session alive (based on policy) >> if a connection is closed without closing the streams (XEP-0198). >> - Added section on using XEP-0156 to discover the WebSocket connection >> endpoint. I've emailed the XMPP Registrar to register the >> _xmpp-client-websocket connection method name. I've also asked the XMPP >> standards list about creating a .well-known/ document to supplement the >> method defined in XEP-0156 as browser based clients that will use the >> WebSocket transport can't make the necessary DNS calls. >> >> >> There do remain several issues that have been discussed at the previous >> IETF meeting and the XSF summit last February: >> >> - How to handle instructing the client to connect to a different >> endpoint (e.g., some see-other-uri error condition). If we can >> define a new stream error condition here, then that would be >> preferable. >> >> - SASL EXTERNAL. What qualifies? Would a user session cookie (normally >> sufficient for HTTP requests) be acceptable? If a user session >> cookie is provided and authorized by the server before accepting >> the WebSocket connection, is SASL auth still needed or can a client >> request binding immediately? (similar to the use of pre-binding in BOSH) >> > IMHO, if the server is offering SASL EXTERNAL that means "I have some > means of verifying your identity on another protocol level". I think it > is sensible that a server would offer EXTERNAL if it saw a e.g. a > session cookie. I would prefer to keep the SASL auth step, to keep this > in line with the usual XMPP flow. > >> - Compression. As we are using text frames, we can't compress the XMPP >> traffic directly. However, there are other I-Ds working on enabling >> compression for WebSocket message data. Should this be called out now, >> or wait until those I-Ds have progressed? >> >> - IANA consideration: It's fully possible, and maybe even preferable, for >> a server to provide both BOSH and WebSocket endpoints on port 5280. >> Should we update the IANA registration for 5280 to be named >> something more generic than xmpp-bosh? >> > Interesting question. I think that reservation might have become > somewhat bogus over time. 5280 is mostly a "HTTP service provided by a > XMPP server". > E.g. prosody has a general HTTP API which is used to provide different > things, from web-admin, over chat logs to BOSH and websockets all on > port 5280. IIRC ejabberd's web-admin is on 5280, too. Additionally BOSH > is/was often proxied to port 80 to avoid same-origin policy issues. > It might be worthwhile updating the registration, I'm not sure what a > decent description (that actually warrants having a dedicated port) > would be though. > >> Other suggestions had been discussed that, after having personally >> implemented an XMPP over WebSocket client, I don't find sufficiently >> compelling for changing the protocol: >> >> - Creating a new stream start/end marker >> - Requiring all in-scope namespaces to be declared on top-level stream child elements >> >> Specifically, here's the relevant excerpt to handle the above: >> >> [snip bunch of javascript] > I disagree, that this is not compelling (Well, I'm sort of bound to, > since those are my suggestions), particularly considering your code example. > With those two changes in place the equivalent client code would amount to: > parser = new DOMParser(); > stanza = parser.parseFromString(message, "application/xml"); > On top of that it's a 13 line change in Prosody's mod_websocket. > > I think it fits our simple client, complex server model a lot better to > have the complexity for making this easy to parse in a web-browser on > the server side. I'll also add that while different technically, there is some precedent for this. Practically all BOSH implementations do this stamping of stream children already because of . Why we don't prefix I don't know, but that's the way the XEP and today's implementations are, so I guess the main answer is "historical reasons" - possibly rooted in poor XML namespace support in browsers 10 years ago. I say we should jump at the chance to use framing available to us in the transport while we can. Streaming parsers could still be used (or more importantly for multi-transport implementations: re-used), and it removes a contentious issue: many people dislike streaming parsers, but more worryingly many popular platforms simply don't even have them available (often leading people to write their own, and get it wrong and/or complain about XMPP/XML vocally). Regards, Matthew From mamille2@cisco.com Wed May 29 07:44:58 2013 Return-Path: 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 768E921F9092 for ; Wed, 29 May 2013 07:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.699 X-Spam-Level: X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, MANGLED_SAVELE=2.3, 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 qCnVbKWyKSni for ; Wed, 29 May 2013 07:44:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB321F905B for ; Wed, 29 May 2013 07:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9090; q=dns/txt; s=iport; t=1369838691; x=1371048291; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Zz0pMR+DL22EReu9pZv1+/lTR5v7KB8ottEFsj6hsro=; b=acgHnwhI32pg9lIOmWZTb5bDW3KCdWsaB73j/nX9vFhvnnFpfWF80UpM uk4rmcQ9WlER24mSfNg1q0o77hTUQGscaVGbOJqK9iALEgcE+nXGMf87j 1syCRCXh3vudwtGWFNa9rKC/hMBr59sHHL4mpkj6jdABfi4/efJnJcfei M=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooGAMwTplGtJV2Y/2dsb2JhbABagwkwwX2BChZ0giMBAQEDAXkFCwIBFgoKJAIfESUCBAENBQgGh20DCQYMsXUNiEKMPIImFhsHgnZhA49+gSuCOYFzgw+KdIUjgw+CJw X-IronPort-AV: E=Sophos;i="4.87,764,1363132800"; d="p7s'?scan'208,217";a="216257842" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 29 May 2013 14:44:50 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4TEioEH006152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 14:44:50 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 29 May 2013 09:44:50 -0500 From: "Matt Miller (mamille2)" To: Matthew Wild , XMPP Working Group Thread-Topic: Take advantage of framing [WAS: New version of XMPP over Websocket draft] Thread-Index: AQHOXHsSwKf8qIqCgUuvkaLwclvHNQ== Date: Wed, 29 May 2013 14:44:49 +0000 Message-ID: References: <20130518204707.18094.87013.idtracker@ietfa.amsl.com> <51A51977.8020005@babelmonkeys.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_A433F12F-DDCC-4F80-BEB0-55B05D7E81BC"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [xmpp] Take advantage of framing [WAS: New version of XMPP over Websocket draft] X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:44:58 -0000 --Apple-Mail=_A433F12F-DDCC-4F80-BEB0-55B05D7E81BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 29, 2013, at 6:55 AM, Matthew Wild wrote: > On 28 May 2013 21:54, Florian Zeitz wrote: >>=20 >> Am 18.05.2013 23:49, schrieb Lance Stout: >>=20 >>> Other suggestions had been discussed that, after having personally >>> implemented an XMPP over WebSocket client, I don't find sufficiently >>> compelling for changing the protocol: >>>=20 >>> - Creating a new stream start/end marker >>> - Requiring all in-scope namespaces to be declared on top-level = stream child elements >>>=20 >>> Specifically, here's the relevant excerpt to handle the above: >>>=20 >>> [snip bunch of javascript] >> I disagree, that this is not compelling (Well, I'm sort of bound to, >> since those are my suggestions), particularly considering your code = example. >> With those two changes in place the equivalent client code would = amount to: >> parser =3D new DOMParser(); >> stanza =3D parser.parseFromString(message, "application/xml"); >> On top of that it's a 13 line change in Prosody's mod_websocket. >>=20 >> I think it fits our simple client, complex server model a lot better = to >> have the complexity for making this easy to parse in a web-browser on >> the server side. >=20 > I'll also add that while different technically, there is some > precedent for this. Practically all BOSH implementations do this > stamping of stream children already because of xmlns=3D'http://jabber.org/protocol/httpbind'>. Why we don't prefix > I don't know, but that's the way the XEP and today's > implementations are, so I guess the main answer is "historical > reasons" - possibly rooted in poor XML namespace support in browsers > 10 years ago. >=20 > I say we should jump at the chance to use framing available to us in > the transport while we can. Streaming parsers could still be used (or > more importantly for multi-transport implementations: re-used), and it > removes a contentious issue: many people dislike streaming parsers, > but more worryingly many popular platforms simply don't even have them > available (often leading people to write their own, and get it wrong > and/or complain about XMPP/XML vocally). >=20 I completely agree with taking advantage of framing wherever possible. = While it does not appear to be difficult, I think we're doing ourselves = a disservice to continue this practice, particularly where XMPP-friendly = streaming parsers are effectively not available. In that vein, might I suggest the following for opening and closing (WS) = stream? * begin: Basically everything one would expect in a stream:stream. * end: - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_A433F12F-DDCC-4F80-BEB0-55B05D7E81BC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA1MjkxNDQ0 NTBaMCMGCSqGSIb3DQEJBDEWBBQbAJkBAF5OE594hnSUhrpLwCwOezCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAC9M 5+y2sekZGyRN61MRBQjafSJCckLClBQLfHk+7W1FWK3JWVTOvuwxgYS/UFGwEOfRcklHXl/1OGHe qNuFae2WdT4dkidRJt1zzQT/ZhGMtuhjaq8aMHblxq/71fMdKemPFk8aqxsdubNNAGuQIsBce4RN WRziHoOHbZjh1RenXPsYCXpz32pNH5fwhTwH0hZKchTsgZWMU8pbfV5pbyPdfTQLYlLcHHY1ER9D VQjNUXXy5MWeQlHareC0lAyR7DNFVRLWLCpCjXwIr7MUIuil2nWRJ9UIuyOlO87RmOiBywpQ39r4 wF209S3Eqj4JZfg++VFMVwydS30s5fWn/mEAAAAAAAA= --Apple-Mail=_A433F12F-DDCC-4F80-BEB0-55B05D7E81BC-- From yusuke.doi@toshiba.co.jp Wed May 29 09:08:42 2013 Return-Path: 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 568BE21F95EC for ; Wed, 29 May 2013 09:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] 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 iBAEHaWiqa8O for ; Wed, 29 May 2013 09:08:35 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3221F962E for ; Wed, 29 May 2013 09:08:35 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r4TG8Yoe013609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 May 2013 01:08:34 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4TG8Y58003190 for ; Thu, 30 May 2013 01:08:34 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 979 for ; Thu, 30 May 2013 01:08:34 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4TG8Y1X003187 for ; Thu, 30 May 2013 01:08:34 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r4TG8YB0021752 for xmpp@ietf.org; Thu, 30 May 2013 01:08:34 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id BAA21751; Thu, 30 May 2013 01:08:34 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r4TG8Xm5020866 for ; Thu, 30 May 2013 01:08:33 +0900 (JST) Received: by toshiba.co.jp id r4TG8XYJ008913; Thu, 30 May 2013 01:08:33 +0900 (JST) Date: Thu, 30 May 2013 01:08:32 +0900 (JST) Message-Id: <201305291608.r4TG8XYJ008913@toshiba.co.jp> To: mamille2@cisco.com From: DOI Yusuke In-Reply-To: References: <51A51977.8020005@babelmonkeys.de>

X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Take advantage of framing X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:08:42 -0000 Dear Matt, From: "Matt Miller (mamille2)" Subject: [xmpp] Take advantage of framing [WAS: New version of XMPP over Websocket draft] Date: Wed, 29 May 2013 14:44:49 +0000 > I completely agree with taking advantage of framing wherever possible. While it does not appear to be difficult, I think we're doing ourselves a disservice to continue this practice, particularly where XMPP-friendly streaming parsers are effectively not available. > > In that vein, might I suggest the following for opening and closing (WS) stream? > > * begin: version='1.0' > to='example.com' > from='juliet@example.com' > xml:lang='en'/> > Basically everything one would expect in a stream:stream. > > * end: Peter Waher and I have had similar (almost identical) discussion on EXI encoding because bit-packed EXI also has a problem on streaming. I think we can share the same definition of the open/close marker if they are transport agonistic (e.g. not placed under ws: namespace). Regards, Yusuke From mamille2@cisco.com Wed May 29 09:20:41 2013 Return-Path: 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 8AD7121F969E for ; Wed, 29 May 2013 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.849 X-Spam-Level: X-Spam-Status: No, score=-8.849 tagged_above=-999 required=5 tests=[AWL=1.150, 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 aa82XY7W9VI0 for ; Wed, 29 May 2013 09:20:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCE921F960B for ; Wed, 29 May 2013 09:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7708; q=dns/txt; s=iport; t=1369844421; x=1371054021; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SDZR2bgIvHSS+2gmcKtyExMRJdR0wkn9EXGaGTUpO4s=; b=kDWKk3EUMcEgcVOdYZsinoNy0AFdYuBcCwZru1RkxlaOTBdl++n45isb 8CjjxqTo4nWqpTov1XgudKKt4ntubS4UAKEvIGXboH1q16LZK3eTEkxE9 Oe/4v50U+MufQ5KTLRQgEsosjFNSo6pPUM/c5DBvAoZGnPW3OCiNai7l7 A=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAB4qplGtJXG9/2dsb2JhbABagwnCLoEKFnSCIwEBAQMBeQULAgEIEQMBAgskAjAdCAIEDgUIBod5BrpbjmIWChEHgnZhA49+gSuCOZUZgw+CJw X-IronPort-AV: E=Sophos;i="4.87,765,1363132800"; d="p7s'?scan'208";a="216309396" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 29 May 2013 16:20:20 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4TGKKoh011432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 16:20:20 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 29 May 2013 11:20:20 -0500 From: "Matt Miller (mamille2)" To: DOI Yusuke Thread-Topic: [xmpp] Take advantage of framing Thread-Index: AQHOXIbGu/YC9m7Uj0OdOwxCwJdCnpkcq5cA Date: Wed, 29 May 2013 16:20:20 +0000 Message-ID: References: <51A51977.8020005@babelmonkeys.de>

<201305291608.r4TG8Xhr022772@toshiba.co.jp> In-Reply-To: <201305291608.r4TG8Xhr022772@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_5FFC842F-191A-4074-BA42-7CF45DF8B42C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [xmpp] Take advantage of framing X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:20:42 -0000 --Apple-Mail=_5FFC842F-191A-4074-BA42-7CF45DF8B42C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 29, 2013, at 10:08 AM, DOI Yusuke wrote: > Dear Matt, >=20 > From: "Matt Miller (mamille2)" > Subject: [xmpp] Take advantage of framing [WAS: New version of XMPP = over Websocket draft] > Date: Wed, 29 May 2013 14:44:49 +0000 >=20 >> I completely agree with taking advantage of framing wherever = possible. While it does not appear to be difficult, I think we're doing = ourselves a disservice to continue this practice, particularly where = XMPP-friendly streaming parsers are effectively not available. >>=20 >> In that vein, might I suggest the following for opening and closing = (WS) stream? >>=20 >> * begin: > version=3D'1.0' >> to=3D'example.com' >> from=3D'juliet@example.com' >> xml:lang=3D'en'/> >> Basically everything one would expect in a stream:stream. >>=20 >> * end: >=20 > Peter Waher and I have had similar (almost identical) discussion on > EXI encoding because bit-packed EXI also has a problem on streaming. I > think we can share the same definition of the open/close marker if > they are transport agonistic (e.g. not placed under ws: namespace). >=20 Personally, I think I have a slight preference for a transport-specific = mechanism, but that could just be for reasons of precedent. As long as = something gets defined that is usable for WebSocket. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_5FFC842F-191A-4074-BA42-7CF45DF8B42C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA1MjkxNjIw MjBaMCMGCSqGSIb3DQEJBDEWBBSmRi41X8wf37vhzbuBrJs3y3WDnTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAHsv 14Ne3zT8XGykrMUcy1slwXKO3pK/CkxbDXqlvS84HudH4O+7MoaiYgHtAxjcaRftjrOxwdoinsNK 2+92//Y9XAdQzY9UzVhBpebNr0jvw04pRVgeM8ZLsvd0K+RMd6Jf6V79ilsqFjz2le12vcZ+gmYe j/6MJHdQ25gahg+3pyTfAcPDGtUbqYSEStnw/g+9BHzNT0Mf0mZgtQDIG7NEencjbNCmpeGKcGSb 6uAKrdOaPQPP0k5Plz1hpkiwrc66a4sBQPBmTvNFwuodPuhPhJ5zXRFfumkzA5e9Lm7VbLOUHe01 F8Nbv6Q2U9WgDNcyOLOYIfo7woRWrJB4tzAAAAAAAAA= --Apple-Mail=_5FFC842F-191A-4074-BA42-7CF45DF8B42C--