Hi Hendrik, On Wed, Jan 4, 2012 at 8:48 PM, Hendrik Sattler <post@xxxxxxxxxxxxxxxxxx> wrote: >> That is what the OBEX spec says, but GOEP 2.0 says otherwise, actually >> PUT and GET may also be used without CONNECT and the even the OBEX >> spec state both PUT, GET and SETPATH supporting SRM headers. > > Using PUT and GET without CONNECT is not very efficient as you limit yourself > to the lowest MTU and default inbox (OPP). This was only there for some kind > of stateless IrDA connection which does not qualify for the requirements of > SRM, anyway Efficiency was no much of the point here, but what operation do support as stated in 2.2.23 Single Response Mode (SRM): "This header shall be used during CONNECT, DISCONNECT, SETPATH, PUT and GET operations only (see the table below)." This is also restated in 3. Session Protocol: " 2) Single Response Mode (SRM) can be negotiated during CONNECT, PUT, GET, or SETPATH, which will remain enabled until a DISCONNECT or OBEX transport disconnect occur." And it continues stating that SRM can be enable outside of connection scope: "If this mode is enabled outside the scope of an OBEX connection, SRM is automatically disabled when the operation that enabled this mode completes." So I can only interpret this statements as PUT and GET can be used to enable SRM at any point like GOEP 2.0 is doing. Now after that comes an interesting part, and that one I think makes GOEP 2.0 to not adopt SRM headers on CONNECT is the following: "This mode will allow multiple outstanding request or response packets during the context of an OBEX connection (or OBEX operation). Since SRM allows multiple outstanding packets, this mode also makes available the ability for multiple outstanding OBEX operations to exist at a time." Now look at the example 7.14 PUT and GET during Single Response Mode (SRM): "Start GET operation without waiting for the Server to respond to the outstanding PUT operation. Since only one response occurs per operation, it is known that the first Server response packet will pertain to the PUT operation." I believe this is why GOEP 2.0 want to avoid using SRM per connection, because multiple outstanding operations are not very easy to be handled without an id/serial to identify them which OBEX doesn't have, for instance there could be SRMP headers in responses which alters SRM and breaks the assumption that only one response occurs per operation. IMO what the OBEX spec writer suggests is that the operations are queued by the server, so it only starts responding once the previous operation is finished, but this doesn't have any benefit over enabling SRM per operation as GOEP 2.0 suggests. >> > Additionally, the spec says: >> > "Client devices supporting SRM must issue a Single Response Mode (SRM) >> > header [...] during all CONNECT requests [...]". >> >> That is still possible, by adding the headers manually, but > > How should the application ever know better than the part that implements the > low-level details of OBEX? That is a very unlikely case. I mean we have an API to add headers to a packet which the application can use to modify the behavior in e.g. CONNECT, but we won't be adding this headers automatically because there are not always recommended by specification using OBEX as GOEP 2.0. The impact is minimal since we still enable SRM per operation. >> automatically configuration will only be done for PUT/GET because of >> the way GOEP 2.0 is using SRM restrict that: >> > "SRM headers shall not be sent in the Connect request or response >> > packets (note, this is to preserve backwards compatibility). SRM shall >> > be enabled through Put and Get operations only." >> >> You can get GOEP 2.0 from bluetooth.org, you might find it interesting >> specially the examples are completely different from the ones OBEX >> spec has and we have to support them both. > > I have read that. BTW, it should be noticed that GOEP v2.0 references OBEX > v1.5, not v1.4. Maybe those differences come from the latest OBEX > specification? Good point, I don't have 1.5 yet, hope to get some clarification about it during the next UPF. > Also note that the first example (page 14) is _wrong_ as the "SRM disabled" in > the last line of the table is wrong. See all following examples that do not > have the entry. Also, this would directly contradict the OBEX specification. > The Bluetooth spec should get an errata for this, ASAP, as this will most > likely cause interoperability issues. The way the author appears to interpret is that if SRM was enable in PUT/GET it will remain active only during that operation: GOEP 2.0 Page 1.4 - 4.6 Using Single Response Mode: "SRM will remain in effect for the duration of the operation that enabled it (PUT or GET), at which time it will automatically be disabled and revert back to the normal GOEP request/response model." OBEX spec says that if SRM is enabled during the connection context it is valid to all subsequent operations, I guess GOEP 2.0 interpret context as just within CONNECT request/response. Again I think this is to avoid having to support multiple outstanding operations, but it is not stated anywhere so it is just my guess. > SRM is a complete mess, anyway. Indeed. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
