>On Sun, May 22, 2011 at 3:13 AM, Dhruv Matani <[email protected]> wrote: >>>> 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 character set is always UTF-8 by default anyway.
okay. > >> 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." > >This seems redundant, anyway. It's always the client's job to send >requests to receive replies--this is fundamental to BOSH. Probably what the XEP is trying to say here is that the client "must not" initiate any sort of data exchange with the server unless it receives a <features> packet from the server. I wanted it to read as "MUST" since pidgin breaks this and assumes <features> being present in the session creation response. > > >To follow up: > >On Mon, May 16, 2011 at 7:47 PM, Glenn Maynard <[email protected]> wrote: >> 11. Overactivity: >> >>> If during any period the client sends a sequence of new requests equal in >>> length ... >> >> Is this necessary? Servers can effectively rate-limit clients by throttlign >> their responses. That way, rate limiting is enforced by the first >> Overactivity rule ("longer than the number..."). This simplifies clients, >> because when not in polling mode, they no longer have to pay attention to >> the 'polling' attribute at all and don't need to perform any timer-based >> throttling. > >I see what's happening here: this rule only applies when the last >packet is an unnecessary empty packet, one that that wasn't actually >needed to pad out the number of held connections. As long as a client >never does that, only sending empty packets when it has a reason to do >so (including during retransmissions), this rule has no effect. > >I'm not sure why the polling time matters here, though; it seems >simpler to just prohibit sending null requests (requests with no body, >'pause' or 'terminate' command, or anything else with side-effects) >when the number of requests is already greater than or equal to the >value of 'hold'. I think this rule applies (as you have earlier mentioned) only to the case when multiple adjacent (or continuous) empty bodies are sent and this happens when the server already has held responses for this BOSH session. Either ways it makes sense to remove the requirement of BOSH servers supporting polling since it complicates things without too much of a benefit. -- -Dhruv Matani. http://dhruvbird.com/ "What's the simplest thing that could possibly work?" -- Ward Cunningham
