Hello, >> The HTTP Content-Type header of all client requests SHOULD be "text/xml; >> charset=utf-8".
> 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. Are there situations where this might cause > problems? I agree. Maybe the default should be assumed to be utf-8 and if different, it may be specified. >> The <body/> element SHOULD also include the following attributes > 'hold' is only a SHOULD, and client behavior seems unspecified if it's > omitted. 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? (There seem to be a lot of SHOULDs on the server side, which > turn into complications for clients.) Agree again. >> 12. Polling Sessions: >> the connection manager MAY require a client to use polling by setting the >> 'requests' attribute ... of its Session Creation Response to "1" > This complicates clients by forcing them to support polling. It would be > preferable to prohibit this, so clients that don't need polling don't have > to support it. When is this useful enough to justify the extra client > complexity? Agree again. 1. 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." 2. For stream restarts, "The BOSH <body/> element SHOULD be empty (i.e., not contain an XML stanza). However, if the client includes an XML stanza in the body, the connection manager SHOULD ignore it. [10]" Why is this requirement imposed? 3. What happens if the client sends XML stanzas in the session creation (or stream add) request? Regards, -Dhruv.
