71
edits
Difference between revisions of "BoshIssues"
Jump to navigation
Jump to search
Adding results from BOSH/Websockets sprint at summit #13
(Adding results from BOSH/Websockets sprint at summit #13) |
|||
| Line 2: | Line 2: | ||
'''NOTE''' this list is in no particular order. | '''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== | ==Pipelining== | ||
| Line 25: | Line 27: | ||
:::So I think we need to fix section 18.1. | :::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== | ==Value of 'hold' and Pipelining== | ||
| Line 32: | Line 40: | ||
===Status=== | ===Status=== | ||
Propose a patch | Propose a patch. | ||
===Owner=== | |||
Bear will write a patch. | |||
==Format of 'accept' value in session creation response== | ==Format of 'accept' value in session creation response== | ||
| Line 40: | Line 51: | ||
===Status=== | ===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== | =='secure' attribute== | ||
| Line 83: | Line 93: | ||
(since nothing is being transmitted for any stream). | (since nothing is being transmitted for any stream). | ||
</pre> | </pre> | ||
===Status & Owner=== | |||
These can be removed, Bear will write a patch | |||
==Session Termination and Sending BOSH Errors== | ==Session Termination and Sending BOSH Errors== | ||
| Line 95: | Line 108: | ||
* 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 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. | * 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=== | ===Discussion=== | ||
| Line 110: | Line 128: | ||
In RFC2616 the content-type header is marked as 'SHOULD', as it is in XEP-0124. Constrained | 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.'' | 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=== | ===Status=== | ||
| Line 121: | Line 144: | ||
* Is anybody aware of network environments where omitting the Date header might have adverse results? | * Is anybody aware of network environments where omitting the Date header might have adverse results? | ||
===Status=== | ===Status=== | ||
Better not remove these. | |||
===Owner=== | |||
Lance will write a patch. | |||
=='Hold' and 'Request' Attribute Values== | =='Hold' and 'Request' Attribute Values== | ||
| Line 131: | Line 157: | ||
*''''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. | *''''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. | ||
</blockquote> | </blockquote> | ||
But | 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=== | ===Status=== | ||
Needs a patch | Needs a patch. | ||
===Owner=== | |||
Bear will write a patch. | |||
==Session Creation Attributes Too Optional== | ==Session Creation Attributes Too Optional== | ||
| Line 142: | Line 171: | ||
It is not clear what and how would exactly break. | It is not clear what and how would exactly break. | ||
===Status=== | ===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/>== | ==Stream Creation: missing <stream:features/>== | ||
| Line 159: | Line 192: | ||
'SHOULD' is already quite strong, I see no compelling reason to change it in a 'MUST'. Proposal: ''leave XEP-0124 as it is''. | 'SHOULD' is already quite strong, I see no compelling reason to change it in a 'MUST'. Proposal: ''leave XEP-0124 as it is''. | ||
===Status=== | ===Status=== | ||
Issue discussed, no compelling need to change the specs here. | |||
==Unclear Terminology== | ==Unclear Terminology== | ||
| Line 166: | Line 199: | ||
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. | 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=== | ===Status=== | ||
Specs need to be reread on this and patches proposed. | 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== | ==Better explanation for "1 sometimes 2 HTTP sockets open" mechanism== | ||
| Line 173: | Line 209: | ||
Some feel the need for a bit better explanation on how HTTP requests are replaced. | Some feel the need for a bit better explanation on how HTTP requests are replaced. | ||
===Status=== | ===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== | ==Re-requesting RIDs== | ||
| Line 189: | Line 228: | ||
===Status=== | ===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== | ==HTTPS port== | ||
| Line 195: | Line 237: | ||
There is not an HTTPS port for BOSH. | There is not an HTTPS port for BOSH. | ||
===Status=== | ===Status=== | ||
No need for this. | |||
==JSON Content Type== | ==JSON Content Type== | ||
| Line 212: | Line 254: | ||
* It is unclear how big the need for this is | * 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. | 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=== | ===Note=== | ||
| Line 223: | Line 267: | ||
===Status=== | ===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== | ==Key encoding== | ||
| Line 230: | Line 277: | ||
===Status=== | ===Status=== | ||
This should be case insensitive. | |||
===Owner=== | |||
Lance will write a patch | |||