Re: [Standards] draft-ietf-xmpp-websocket-10

[drichards]

> -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
> . 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

[Florian Zeitz]

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
. 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

[drichards]

> -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

[drichards]

> -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

[drichards]

> -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

[drichards]

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

 

 

[Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)

[XMPP Extensions Editor]

This message constitutes notice of a Last Call for comments on XEP-0332 (HTTP 
over XMPP transport).

Abstract: This specification defines how XMPP can be used to transport HTTP 
communication over peer-to-peer networks.

URL: http://xmpp.org/extensions/xep-0332.html

This Last Call begins today and shall end at the close of business on 
2014-10-21.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and 
requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!

[Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

[XMPP Extensions Editor]

This message constitutes notice of a Last Call for comments on XEP-0322 
(Efficient XML Interchange (EXI) Format).

Abstract: This specification describes how EXI compression can be used in XMPP 
networks.

URL: http://xmpp.org/extensions/xep-0322.html

This Last Call begins today and shall end at the close of business on 
2014-10-21.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and 
requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!