BoshIssues

This page lists known issues with the BOSH specifications (XEP-0124 and XEP-0206).

NOTE this list is in no particular order.

Update (2 Februari 2013): This list has been discussed at summit #13, the results of it are included below. We agreed upon submitting al patches before the 22th of februari 2013, so we can push these XEPs to final.

Pipelining

Summary

All 124 requests are POST requests -- and POST requests are non-idempotent and should not be pipelined. ?Though it is referred to as SHOULD NOT, unless you have a very very strong enough reason to pipeline POST, you MUST NOT. [*]

Status

No additional information needed, we can write a patch for section 18.1. Note we also need to fix this in paragraph 1, 4, 5, 7.1, 12 and 16. It seems that the term 'pipelining' is used as a way to tunnel multiple HTTP requests simultaneously over one TCP connection. Because re-using TCP-connections and keeping them alive does not have the same 'magical' properties, I think we should scale down and rewrite the standard as 'just 2 HTTP requests'.

Discussion

Peter Saint-Andre: Mridul, I agree with your later message that pipelining POSTs should be strongly discouraged, as it already is in RFC 2616. Do we need some text about that in XEP-0124?

Mridul: I always assumed that was implicit, but it is not obvious when starting out I guess. Considering the confusion it raised, I think you are right - we might want to discourage it strongly : with references to http rfc for the "why".

Peter Saint-Andre: BOSH uses POST, which is not idempotent. RFC 2616 says "Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods". Yet XEP-0124 says:

18.1 HTTP Pipelining

Even if the client requests HTTP Pipelining and the connection manager supports it, there is no guarantee that pipelining will succeed, because it might not be supported by intermediate proxies.

The best the client can do is to request the use of HTTP Pipelining by setting the 'hold' attribute to a value of "1". If HTTP Pipelining does not work (because the server returns HTTP 1.0 or connection:close), then the client SHOULD degrade gracefully by using multiple connections.

So I think we need to fix section 18.1.

Resolution

Needs to be fixed indeed, BOSH/POST and pipe-lining don't mix. Add some explanation to it.

Owner

?

Value of 'hold' and Pipelining

Summary

The recommended value of 'hold' is "1" except when using pipelining. Because of the pipelining confusion, this is nonsense. So de facto the recommended value is always "1" right now. As far can be determined there is no reason to recommend otherwise, so it's best to simply recommend a 'hold' value of "1".

Status

Propose a patch.

Owner

Bear will write a patch.

Format of 'accept' value in session creation response

Issue

In XEP-0124 section 7.2, text says the 'accept' attribute is space separated, yet the example is comma separated (thanks to Guus der Kinderen for bringing this issue up).

Status

Will be comma separated, but we need to check if a proposed patch will break any implementations.

Owner

Bear will write a patch

'secure' attribute

Issue

The 'secure' attribute was removed from the schema and some of the text regarding the session creation response, but there exists several references to it.

Status

More information/discussion is needed; should the 'secure' attribute here be removed altogether from section 7.2 and 16.3, or maintained for historical reasons (with a remark it is present only for backward compatibility and should be ignored)? It appears safe to remove mention of the 'secure' attribute from section 16.4.

Details

In section 7.2, immediately before example 2:

If it established a secure connection to the server (as defined
in Initiating a BOSH Session), then in the same response the
connection manager SHOULD also include the 'secure' attribute
set to "true" or "1".

In section 7.2, caption for example 3:

Subsequent response with 'from' and 'secure' attributes

In section 16.3:

The request MAY include 'route', 'from' and 'secure' attributes
(see Session Creation Request), but SHOULD NOT include 'ver',
'content', 'hold' or 'wait' attributes (since a new session is
not being created.

In section 16.4:

Note: Empty <body/> elements that do not include a 'from' or
'secure' attribute SHOULD NOT include a 'stream' attribute
(since nothing is being transmitted for any stream).

Status & Owner

These can be removed, Bear will write a patch

Session Termination and Sending BOSH Errors

Issue

It is not clear on what connection there should be responded to a BOSH termination and what should be done with the other connection.

Status

Proposed fix to XEP-124 is:

• Clarify that BOSH errors and BOSH termination should be sent on the most recent connection
• Clarify that on termination (by request or by error), all connections (except for the most recent, above) should be closed by sending an empty <body/>
• Clarify that if there is any payload included in the "terminate" request, the payload should not need any response from the service.

At summit #13: send termination on the oldest connection, to not break current implementations, closing body on other connection.

Owner

Winfried

Discussion

See http://mail.jabber.org/pipermail/bosh/2011-March/thread.html#352

'Content-Type' HTTP Header

Issue

XEP-0124 states in section 5 (HTTP Overview):

The HTTP Content-Type header of all client requests SHOULD be "text/xml; charset=utf-8". However, clients MAY specify another value if they are constrained to do so (e.g., "application/x-www-form-urlencoded" or "text/plain"). The client and connection manager SHOULD ignore all HTTP Content-Type headers they receive.

Ignored headers add unnecessary overhead to every request; upstream is often severely limited.  It would be better to prefer omitting this header entirely when possible.

Proposed solution

In RFC2616 the content-type header is marked as 'SHOULD', as it is in XEP-0124. Constrained clients might need that header, in constrained network environments lack of a content-type header might result in blocking the request. (In section 7 XEP-0124 a little more is said about this). So omitting the header by default might have unwanted results. At the same time the 'SHOULD' in both XEP-0124 and RFC2616 leave room to omit the header when there are good reasons to so, e.g. in a deployment with very limited bandwidth. So the best solution would be: don't change XEP-0124.

At summit: some explanation might be good.

Owner

Lance will write a patch

Status

More discussion needed.

'Date' HTTP Header

Issue

The HTTP 'Date' header is ignored in BOSH. Ignored headers add unnecessary overhead to every request; upstream is often severely limited. It would be better to prefer omitting this header entirely when possible.

Discussion

The Date headers are in RFC2616 marked as SHOULD. On the date RFC2616 states that if a client or server is without a clock, then it MAY be omitted. The 'SHOULD' leaves room to omit the header when there are good reasons for it. Note that neither XEP-0124 nor XEP-0206 mention the Date header anywhere and all the examples have no Date header. So the best solution would be: don't change XEP-0124

• Is anybody aware of network environments where omitting the Date header might have adverse results?

Status

Better not remove these.

Owner

Lance will write a patch.

'Hold' and 'Request' Attribute Values

Issue

XEP-0124 section 7.2 (Session Creation Response) states:

• 'requests' -- This attribute enables the connection manager to limit the number of simultaneous requests the client makes (see Overactivity and Polling Sessions). The RECOMMENDED values are either "2" or one more than the value of the 'hold' attribute specified in the session request.
• 'hold' -- This attribute informs the client about the maximum number of requests the connection manager will keep waiting at any one time during the session. This value MUST NOT be greater than the value specified by the client in the session request.

But it is senseless to specify an amount of 'Requests' that is equal or less then 'hold'. Better add that the value of requests MUST be bigger then hold, and that the RECOMMENDED value is hold+1.

Status

Needs a patch.

Owner

Bear will write a patch.

Session Creation Attributes Too Optional

Issue

In section 7.2 (Session Creation Response) of XEP-0124 is stated that the <body> element SHOULD have an 'hold' property. The comment is: "If the client doesn't know the server's hold value, things will break.  What should clients do here, and why is the server specifying 'hold' not a MUST?"

Discussion

It is not clear what and how would exactly break.

Status

Discussed that it would be better if clients MUST provide a hold and servers MUST reply with a requests value.

Owner

Bear will write a patch.

Stream Creation: missing <stream:features/>

Issue

On the BOSH mailing list the following issue was brought up:

Additionally, I does it make sense to change the "should" below to a "must"?
"If no <stream:features/> element is included in the connection manager's session creation response, then the client SHOULD send empty request elements until it receives a response containing a <stream:features/> element."

Proposed fix

'SHOULD' is already quite strong, I see no compelling reason to change it in a 'MUST'. Proposal: leave XEP-0124 as it is.

Status

Issue discussed, no compelling need to change the specs here.

Unclear Terminology

Issue

In XEP-0124 and XEP-0206 the use of “HTTP Request”, “BOSH Session” and “Payload Stream” is not consistent. The readability of the specs would improve if these would be used in a more consistent way.

Status

Specs need to be reread on this and patches proposed. Cleaning this up will make the spec more readable.

Owner

Winfried will propose patches.

Better explanation for "1 sometimes 2 HTTP sockets open" mechanism

Issue

Some feel the need for a bit better explanation on how HTTP requests are replaced.

Status

More explanation can make the spec more readable. Best do this with some (ascii)artwork.

Owner

M&M proposes a patch.

Re-requesting RIDs

Issue

Basically it seems that if no response is yet generated, you shouldn't throw out a re-request of the same RID, as there are cases where this is the logical thing to do.

Details

See https://groups.google.com/forum/#!msg/strophe/D3Nj_I2OvaM/VeoDvvHd-hMJ for more information. And http://mail.jabber.org/pipermail/standards/2012-May/thread.html#26000

Status

If a rerequest with the same RID is done, then either the client is broken or the response of the oldest request with the same RID went into nirvana. In both cases the sensible action would be to close the oldest request with a non-fatal error response.

Owner

Ashley writes a patch

HTTPS port

Issue

There is not an HTTPS port for BOSH.

Status

No need for this.

JSON Content Type

See http://xmpp.org/extensions/inbox/json.html

Issue

This proposed extension adresses a discussion that reoccurs every now and then. The inital discussion over this proposal pointed out that mapping XML to JSON is a bit problematic. Also it should be clear where we are aming at:

• Keeping BOSH as it is with XML and allow a JSON payload
• Translate the BOSH-layer to JSON
• Translate all of XMPP, including BOSH to JSON

This proposal seems to do the last.

Status

• Mapping issues of the translation needs to be fixed
• The aim of the proposal needs to be clarified
• It is unclear how big the need for this is

If there are enough people motivated to work on this, best form some a working group to clear up the issues.

Update: JSON is under discussion at the XSF in genaral. In these discussions there is no apparent need for any spec changes in the BOSH specs.

Note

Also see http://xmpp.org/extensions/xep-0295.html (Humorous)

HTTP-layer authentication and XMPP-layer authentication

Issue

If a client authorizes using HTTP Basic, does that mean it then uses EXTERNAL in XMPP?

M-Link's next release will do this for TLS-based auth (ie, X.509 strong auth over BOSH) - I'm not so sure what we should do for Basic, if anything.

Status

Some clarification on what SASL EXTERNAL probably would mean in the context of BOSH.

Owner

Winfried will ping the original maker of this comment (dwd). If he is not willing to explain this, M&M can write a patch.

Key encoding

Issue

Section 15.3 is unclear about the encoding of the key, specifically, whether the hexadecimal representation uses lowercase or uppercase versions of the alphabetic characters. The SHA-1 specification (RFC 3174) seems to imply that the characters are uppercase, however many libraries produce lowercase. We need to clarify this.

Status

This should be case insensitive.

Owner

Lance will write a patch