[BOSH] XEP-124: Doesn't the encoding in the accept attribute of thebody tag belong into the HTTP header?

[Tobias Markmann]

Hi,

I'm referring to Example 2 in XEP-124,
http://www.xmpp.org/extensions/xep-0124.html#session-create . Don't
the accepted encodings belong to the HTTP header instead of the body
tag of the Session Create Response. The Session Create Request gets
this right. It seems Content-Encoding field in the HTTP response
headers would be best; or am I misunderstanding something there?

Cheers,
Tobias

[Tomas Karasek]

Tobias Markmann wrote:
> Hi,
>
> I'm referring to Example 2 in XEP-124,
> http://www.xmpp.org/extensions/xep-0124.html#session-create . Don't
> the accepted encodings belong to the HTTP header instead of the body
> tag of the Session Create Response. The Session Create Request gets
> this right. It seems Content-Encoding field in the HTTP response
> headers would be best; or am I misunderstanding something there?
>
> Cheers,
> Tobias

Hello,

as I understood, the "accept" attribute shows set of encodings CM can
accept from client. On contrary to encodings client can accept from CM
which are specified in Accept-Encoding HTTP header. Due to HTTP RFC,
Accept-Encoding can be only in requests so I guess this is a workaround
for letting client pick an encoding as well. Then, requests and
responses can be in different encodings, whatever it's good for.

But I think that if you'd encode second request in encoding you got init
response in (Content-Encoding of init response), it won't do any harm.
CM should know how to decode data with a method when it encodes with
that method.

rgds,
tomk

[Tobias Markmann]

On Tue, Jul 22, 2008 at 9:11 PM, Tomas Karasek <tom.to.the.k (AT) gmail (DOT) com> wrote:
> Tobias Markmann wrote:
>>
>> Hi,
>>
>> I'm referring to Example 2 in XEP-124,
>> http://www.xmpp.org/extensions/xep-0124.html#session-create . Don't
>> the accepted encodings belong to the HTTP header instead of the body
>> tag of the Session Create Response. The Session Create Request gets
>> this right. It seems Content-Encoding field in the HTTP response
>> headers would be best; or am I misunderstanding something there?
>>
>> Cheers,
>> Tobias
>
> Hello,
>
> as I understood, the "accept" attribute shows set of encodings CM can accept
> from client. On contrary to encodings client can accept from CM which are
> specified in Accept-Encoding HTTP header. Due to HTTP RFC, Accept-Encoding
> can be only in requests so I guess this is a workaround for letting client
> pick an encoding as well. Then, requests and responses can be in different
> encodings, whatever it's good for.
>
> But I think that if you'd encode second request in encoding you got init
> response in (Content-Encoding of init response), it won't do any harm. CM
> should know how to decode data with a method when it encodes with that
> method.
>
> rgds,
> tomk
>

Okay, though I still have the feeling that this kind of stuff belongs
to the HTTP header. ;)

Cheers,
Tobias

[Stefan Strigler]

Hello Tobias,

Am Dienstag, den 22.07.2008, 19:23 +0200 schrieb Tobias Markmann:
> I'm referring to Example 2 in XEP-124,
> http://www.xmpp.org/extensions/xep-0124.html#session-create . Don't
> the accepted encodings belong to the HTTP header instead of the body
> tag of the Session Create Response. The Session Create Request gets
> this right. It seems Content-Encoding field in the HTTP response
> headers would be best; or am I misunderstanding something there?

One basic assumption of BOSH is to be able to deal with constraint
clients. One consequence in here is that a client may not be able to add
or modify ANY http headers.

http://www.xmpp.org/extensions/xep-0124.html#reqs states:

Compatible with constrained runtime environments** (e.g., mobile and
browser-based clients).

**Compatibility with constrained runtime environments implies the
following restrictions:

1. Clients should not be required to have programmatic access to
the headers of each HTTP request and response (e.g., cookies or
status codes).
2. ...
3. Clients should be able to specify the Content-Type of the HTTP
responses they receive.
4.
5.

[Tobias Markmann]

On Wed, Jul 23, 2008 at 11:17 AM, Stefan Strigler
<steve (AT) zeank (DOT) in-berlin.de> wrote:
> Hello Tobias,
>
> Am Dienstag, den 22.07.2008, 19:23 +0200 schrieb Tobias Markmann:
>> I'm referring to Example 2 in XEP-124,
>> http://www.xmpp.org/extensions/xep-0124.html#session-create . Don't
>> the accepted encodings belong to the HTTP header instead of the body
>> tag of the Session Create Response. The Session Create Request gets
>> this right. It seems Content-Encoding field in the HTTP response
>> headers would be best; or am I misunderstanding something there?
>
> One basic assumption of BOSH is to be able to deal with constraint
> clients. One consequence in here is that a client may not be able to add
> or modify ANY http headers.
>
> http://www.xmpp.org/extensions/xep-0124.html#reqs states:
>
> Compatible with constrained runtime environments** (e.g., mobile and
> browser-based clients).
>
> **Compatibility with constrained runtime environments implies the
> following restrictions:
>
> 1. Clients should not be required to have programmatic access to
> the headers of each HTTP request and response (e.g., cookies or
> status codes).
> 2. ...
> 3. Clients should be able to specify the Content-Type of the HTTP
> responses they receive.
> 4.
> 5.
>
>

Ahh..okay...that's fairly understandable. :)

[Peter Saint-Andre]

Tobias Markmann wrote:
> On Wed, Jul 23, 2008 at 11:17 AM, Stefan Strigler
> <steve (AT) zeank (DOT) in-berlin.de> wrote:
>> Hello Tobias,
>>
>> Am Dienstag, den 22.07.2008, 19:23 +0200 schrieb Tobias Markmann:
>>> I'm referring to Example 2 in XEP-124,
>>> http://www.xmpp.org/extensions/xep-0124.html#session-create .

BTW you can link to:

http://www.xmpp.org/extensions/xep-0124.html#example-2

:)

>>> Don't
>>> the accepted encodings belong to the HTTP header instead of the body
>>> tag of the Session Create Response. The Session Create Request gets
>>> this right. It seems Content-Encoding field in the HTTP response
>>> headers would be best; or am I misunderstanding something there?
>> One basic assumption of BOSH is to be able to deal with constraint
>> clients. One consequence in here is that a client may not be able to add
>> or modify ANY http headers.
>>
>> http://www.xmpp.org/extensions/xep-0124.html#reqs states:
>>
>> Compatible with constrained runtime environments** (e.g., mobile and
>> browser-based clients).
>>
>> **Compatibility with constrained runtime environments implies the
>> following restrictions:
>>
>> 1. Clients should not be required to have programmatic access to
>> the headers of each HTTP request and response (e.g., cookies or
>> status codes).
>> 2. ...
>> 3. Clients should be able to specify the Content-Type of the HTTP
>> responses they receive.
>> 4.
>> 5.
>>
>>
>
> Ahh..okay...that's fairly understandable. :)

Yes, I think that's a sensible explanation.

/psa