[Standards] BOSH patches
linuxwolf at outer-planes.net
Tue Dec 10 22:48:04 UTC 2013
On Dec 10, 2013, at 3:06 PM, Christian Schudt <christian.schudt at gmx.de> wrote:
> I am new to this mailing list.
> I have been trying to implement BOSH in Java (client side) on basis of draft 1.10.
> I think the document is quite understandable.
> However, I ran into the following issues:
> - I did not understand the HTTP pipelining stuff, which is now removed :)
Pipelining isn't something that can be applied to BOSH, so we all opted to remove any discussion on it.
> - The 'rid' and 'ack' attribute are marked as "positiveInteger" in the XSD. However, in Java, you need type "long" to represent the largest number (2^53-1). I think this should be changed to "unsignedLong". (integer is only 32-bit in XSD).
In XSD, positiveInteger is unbounded at the maximum (bounded to 1 at the minimum). You're thinking of unsignedInt.
> - "The client MUST generate a large, random, positive integer for the initial 'rid'": What is large? Is there a minimum? And should be "positive long".
Exactly what constitutes a large random value is left for clients to figure out. I don't know that we could reach consensus on what a suitable minimum is.
> - The from attribute. I think it should be: "it MUST forward the identity to the client by including a 'from' attribute in a response" (instead of MAY), because the core spec says:
> "For response stream headers in both client-to-server and server-to-server communication, the receiving entity MUST include the 'from' attribute"
> … just to be conform.
That seems like a reasonable request to me, but we might need more feedback from implementers before changing that MAY to a MUST (or even just a SHOULD). For a real BOSH connection manager, it ought to be known immediately; for a BOSH-as-proxy, though ... maybe the horribly implemented ones need the MAY.
> - The sentence "The client SHOULD NOT open more than two HTTP connections to the connection manager at the same time" confused me, because the document also said the number is defined by the "requests" attribute. But this sentence is now gone in 1.11.
(I think this revised section is my fault)
That section did not feel like a normative section to me (more like an extended intro), and so I tried make it more of a play-by-play of what a BOSH session conceptually looks like. That meant (to me) removing RFC 2119-style normative language.
> In the 1.11 version I don't really understand the diagram under point 4. Too many "empty" bodies.
> - What is the left side and the right side?
> - From "X" to "*" is one HTTP request? Then why is there a long time no request (but many pipes |)?
This is addition is my fault (again), I'll try to clarify (-:
The two sides are separate sockets between the client and server, for a single BOSH session. This was an attempt to illustrate how BOSH utilizes "one sometimes two" sockets for all BOSH traffic.
"X" indicates when an HTTP request is transmitted from the client to the server. "*" indicates when the corresponding HTTP response is transmitted from the server to the client. "| |" indicate the time a server leaves a request pending (at most "wait" seconds). "|" indicates an idle (but still open) socket connection between the client and server.
I can see about converting the above into a legend suitable to patch into the document, but I don't know when I can do that yet.
Hope this helps.
Matthew A. Miller
< http://goo.gl/LK55L >
> Kind regards,
> Am 10.12.2013 um 22:12 schrieb Peter Saint-Andre:
>> On 11/27/13 8:23 AM, Winfried Tilanus wrote:
>>> On 08-11-13 23:40, Peter Saint-Andre wrote:
>>>> Sitting here at IETF 88 with Lance Stout, I'm reminded to finally
>>>> apply the collected patch he sent me to incorporate all the hard
>>>> work that various folks on this list did earlier this year on
>>>> XEP-0124 and XEP-0206. The rendered files and diffs are as
>> Lance has sent me an updated patch, which I have applied. The diff
>> between 124rc1 and 124rc2 is here:
>> Peter Saint-Andre
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Standards