Re: [Standards] draft-ietf-xmpp-websocket-10
The current XEP is of course geared towards TCP/TLS connection and forsees two Mechanisms: -Different exi-specific port -Reopening the stream in-band (reusing compression semantic) The second one would be possible technically, yet would violate the RFC. But you’re right, the first one would still work (using your suggestion). Von: Standards [mailto:standards-boun...@xmpp.org] Im Auftrag von Dave Cridland Gesendet: Donnerstag, 9. Oktober 2014 18:03 An: XMPP Standards Betreff: Re: [Standards] draft-ietf-xmpp-websocket-10 On 9 October 2014 15:26, Hund, Johannes mailto:johannes.h...@siemens.com>> wrote: One point that I do realize now (too late) is that this means it's not possible to use EXI (XEP-0322) over websocket, right? It's basically a 1:1 binary representation of the information in an XML structure/document and therefore definitely not UTF-8. I would have thought that you'd want to negotiate an EXI session differently at the HTTP/WebSocket layer anyway, surely?
Re: [Standards] draft-ietf-xmpp-websocket-10
On 9 October 2014 15:26, Hund, Johannes wrote: > One point that I do realize now (too late) is that this means it's not > possible to use EXI (XEP-0322) over websocket, right? > It's basically a 1:1 binary representation of the information in an XML > structure/document and therefore definitely not UTF-8. > I would have thought that you'd want to negotiate an EXI session differently at the HTTP/WebSocket layer anyway, surely?
Re: [Standards] draft-ietf-xmpp-websocket-10
> -Ursprüngliche Nachricht- > Von: Standards [mailto:standards-boun...@xmpp.org] Im Auftrag von > Florian Zeitz > Gesendet: Donnerstag, 9. Oktober 2014 03:00 > An: standards@xmpp.org > Betreff: Re: [Standards] draft-ietf-xmpp-websocket-10 > > On 08.10.2014 20:42, dricha...@coversant.com wrote: > > > > > >> -Original Message- > >> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of > >> Peter Saint-Andre - &yet > >> Sent: Wednesday, October 08, 2014 12:15 PM > >> To: standards@xmpp.org > >> Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 > >> > >> On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: > >>> Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data > >>> frames must be of type text and contain UTF-8 encoded data. Was > >>> there some reason for this since it makes XMPP stream compression > not usable? > >> > >> Hi Dave, > >> > >> I think we'd recommend doing compression at the HTTP layer, just as > >> for WebSocket we're doing security at the HTTP layer. > >> > >> Also, the spec has been approved for publication and is in the RFC > >> Editor > > queue > >> so it's too late to change it: > >> > >> http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ > >> > >> And x...@ietf.org is the right list for IETF specs. :-) > >> > >> Peter > >> > >> -- > >> Peter Saint-Andre > >> https://andyet.com/ > > > > Argh. No I don't take it back - all it is is a framework for creating > > compression extensions. It doesn't actually define any specific > mechanisms. > > > > I don't know what you found, but the latest approach for WebSocket > compression within the hybi WG appears to be > <https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression>. > It provides a general framework for compression, and registers one > specific extension using DEFLATE. > > The plan for XMPP over WS was indeed always to use such an extension > for compression, if required. As no finished draft exists/existed it > seems sensible that no reference to this was included. I generally > think this is a concern of the WebSocket implementation, and not the > XMPP mapping. > > Regards, > Florian Zeitz One point that I do realize now (too late) is that this means it's not possible to use EXI (XEP-0322) over websocket, right? It's basically a 1:1 binary representation of the information in an XML structure/document and therefore definitely not UTF-8. Regards, Johannes
Re: [Standards] draft-ietf-xmpp-websocket-10
On 10/8/14, 9:59 PM, dricha...@coversant.com wrote: -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Florian Zeitz Sent: Wednesday, October 08, 2014 8:00 PM To: standards@xmpp.org Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 On 08.10.2014 20:42, dricha...@coversant.com wrote: -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Peter Saint-Andre - &yet Sent: Wednesday, October 08, 2014 12:15 PM To: standards@xmpp.org Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames must be of type text and contain UTF-8 encoded data. Was there some reason for this since it makes XMPP stream compression not usable? Hi Dave, I think we'd recommend doing compression at the HTTP layer, just as for WebSocket we're doing security at the HTTP layer. Also, the spec has been approved for publication and is in the RFC Editor queue so it's too late to change it: http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ And x...@ietf.org is the right list for IETF specs. :-) Peter -- Peter Saint-Andre https://andyet.com/ Argh. No I don't take it back - all it is is a framework for creating compression extensions. It doesn't actually define any specific mechanisms. I don't know what you found, but the latest approach for WebSocket compression within the hybi WG appears to be <https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression>. It provides a general framework for compression, and registers one specific extension using DEFLATE. The plan for XMPP over WS was indeed always to use such an extension for compression, if required. As no finished draft exists/existed it seems sensible that no reference to this was included. I generally think this is a concern of the WebSocket implementation, and not the XMPP mapping. Regards, Florian Zeitz Thanks for that. I assumed based on Peter's comment that it was going to be a websocket extension thing so I'll take any further comments over there. I did see that doc but then I looked at http://www.iana.org/assignments/websocket/websocket.xhtml which is apparently not up to date. IANA probably won't update that until the Internet-Draft is approved. We do the same thing at the XMPP Registrar. :-) Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] draft-ietf-xmpp-websocket-10
> -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Florian > Zeitz > Sent: Wednesday, October 08, 2014 8:00 PM > To: standards@xmpp.org > Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 > > On 08.10.2014 20:42, dricha...@coversant.com wrote: > > > > > >> -Original Message- > >> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of > >> Peter Saint-Andre - &yet > >> Sent: Wednesday, October 08, 2014 12:15 PM > >> To: standards@xmpp.org > >> Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 > >> > >> On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: > >>> Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data > >>> frames must be of type text and contain UTF-8 encoded data. Was > >>> there some reason for this since it makes XMPP stream compression not > usable? > >> > >> Hi Dave, > >> > >> I think we'd recommend doing compression at the HTTP layer, just as > >> for WebSocket we're doing security at the HTTP layer. > >> > >> Also, the spec has been approved for publication and is in the RFC > >> Editor > > queue > >> so it's too late to change it: > >> > >> http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ > >> > >> And x...@ietf.org is the right list for IETF specs. :-) > >> > >> Peter > >> > >> -- > >> Peter Saint-Andre > >> https://andyet.com/ > > > > Argh. No I don't take it back - all it is is a framework for creating > > compression extensions. It doesn't actually define any specific mechanisms. > > > > I don't know what you found, but the latest approach for WebSocket > compression within the hybi WG appears to be > <https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression>. It > provides a general framework for compression, and registers one specific > extension using DEFLATE. > > The plan for XMPP over WS was indeed always to use such an extension for > compression, if required. As no finished draft exists/existed it seems sensible > that no reference to this was included. I generally think this is a concern of the > WebSocket implementation, and not the XMPP mapping. > > Regards, > Florian Zeitz Thanks for that. I assumed based on Peter's comment that it was going to be a websocket extension thing so I'll take any further comments over there. I did see that doc but then I looked at http://www.iana.org/assignments/websocket/websocket.xhtml which is apparently not up to date.
Re: [Standards] draft-ietf-xmpp-websocket-10
On 08.10.2014 20:42, dricha...@coversant.com wrote: > > >> -Original Message- >> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Peter >> Saint-Andre - &yet >> Sent: Wednesday, October 08, 2014 12:15 PM >> To: standards@xmpp.org >> Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 >> >> On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: >>> Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames >>> must be of type text and contain UTF-8 encoded data. Was there some >>> reason for this since it makes XMPP stream compression not usable? >> >> Hi Dave, >> >> I think we'd recommend doing compression at the HTTP layer, just as for >> WebSocket we're doing security at the HTTP layer. >> >> Also, the spec has been approved for publication and is in the RFC Editor > queue >> so it's too late to change it: >> >> http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ >> >> And x...@ietf.org is the right list for IETF specs. :-) >> >> Peter >> >> -- >> Peter Saint-Andre >> https://andyet.com/ > > Argh. No I don't take it back - all it is is a framework for creating > compression extensions. It doesn't actually define any specific mechanisms. > I don't know what you found, but the latest approach for WebSocket compression within the hybi WG appears to be <https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression>. It provides a general framework for compression, and registers one specific extension using DEFLATE. The plan for XMPP over WS was indeed always to use such an extension for compression, if required. As no finished draft exists/existed it seems sensible that no reference to this was included. I generally think this is a concern of the WebSocket implementation, and not the XMPP mapping. Regards, Florian Zeitz
Re: [Standards] draft-ietf-xmpp-websocket-10
> -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Peter > Saint-Andre - &yet > Sent: Wednesday, October 08, 2014 12:15 PM > To: standards@xmpp.org > Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 > > On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: > > Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames > > must be of type text and contain UTF-8 encoded data. Was there some > > reason for this since it makes XMPP stream compression not usable? > > Hi Dave, > > I think we'd recommend doing compression at the HTTP layer, just as for > WebSocket we're doing security at the HTTP layer. > > Also, the spec has been approved for publication and is in the RFC Editor queue > so it's too late to change it: > > http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ > > And x...@ietf.org is the right list for IETF specs. :-) > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ OK, I take back my other comment. I found the document describing compression extensions for WebSocket. Would be really nice to mention in the XMPP WebSocket doc that there's such a thing.
Re: [Standards] draft-ietf-xmpp-websocket-10
> -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Peter > Saint-Andre - &yet > Sent: Wednesday, October 08, 2014 12:15 PM > To: standards@xmpp.org > Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 > > On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: > > Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames > > must be of type text and contain UTF-8 encoded data. Was there some > > reason for this since it makes XMPP stream compression not usable? > > Hi Dave, > > I think we'd recommend doing compression at the HTTP layer, just as for > WebSocket we're doing security at the HTTP layer. > > Also, the spec has been approved for publication and is in the RFC Editor queue > so it's too late to change it: > > http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ > > And x...@ietf.org is the right list for IETF specs. :-) > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ Argh. No I don't take it back - all it is is a framework for creating compression extensions. It doesn't actually define any specific mechanisms.
Re: [Standards] draft-ietf-xmpp-websocket-10
> -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Peter > Saint-Andre - &yet > Sent: Wednesday, October 08, 2014 12:15 PM > To: standards@xmpp.org > Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 > > On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: > > Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames > > must be of type text and contain UTF-8 encoded data. Was there some > > reason for this since it makes XMPP stream compression not usable? > > Hi Dave, > > I think we'd recommend doing compression at the HTTP layer, just as for > WebSocket we're doing security at the HTTP layer. > > Also, the spec has been approved for publication and is in the RFC Editor queue > so it's too late to change it: > > http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ > > And x...@ietf.org is the right list for IETF specs. :-) > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ Thanks - it would have been helpful to put in some statement to that effect. What was the intent? The websocket is not HTTP so the HTTP CONTENT-ENCODING should not apply to the websocket. The next option would be the websocket extension mechanism but although RFC 6455 alludes to compression, there is no compression extension (or any other type) listed in the registry. Seems there isn't really a current option for compression or am I missing something?
Re: [Standards] draft-ietf-xmpp-websocket-10
On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames must be of type text and contain UTF-8 encoded data. Was there some reason for this since it makes XMPP stream compression not usable? Hi Dave, I think we'd recommend doing compression at the HTTP layer, just as for WebSocket we're doing security at the HTTP layer. Also, the spec has been approved for publication and is in the RFC Editor queue so it's too late to change it: http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ And x...@ietf.org is the right list for IETF specs. :-) Peter -- Peter Saint-Andre https://andyet.com/
[Standards] draft-ietf-xmpp-websocket-10
Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames must be of type text and contain UTF-8 encoded data. Was there some reason for this since it makes XMPP stream compression not usable? Dave Richards
