Date: Fri, 7 Nov 2008 22:31:39 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Guido Falsi <mad@madpilot.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles Message-ID: <1226097099.328979.788.nullmailer@galant.ukfsn.org> In-Reply-To: <4914B113.60303@madpilot.net> References: <20081104111947.GB62907@megatron.madpilot.net> <1225799105.807983.1164.nullmailer@galant.ukfsn.org> <20081104135107.GA64776@megatron.madpilot.net> <1225821264.107584.759.nullmailer@galant.ukfsn.org> <4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net> <1226091521.039371.399.nullmailer@galant.ukfsn.org> <4914B113.60303@madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Nov 2008, Guido Falsi wrote: > Iain Hibbert wrote: > > The attribute ID list should be in ascending order according to the > > specification. This means though that some logic could be wrong because > > the protocol descriptor list for any given service class would likely > > appear before the service name in the response attribute list and you > > would use the wrong channel.. > > Uhm, I did not get this detail in the specification. You can find this in the small print of the SDP spec sections relating to ServiceSearch and ServiceSearchAttribute requests, in the AttributeIDList box. I guess its so that a server can do a straight pass through search without having to loop up and down the list, but I don't know if that would work out simpler or not in practice. Obviously the Nokia people thought not, as it worked anyway :) iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1226097099.328979.788.nullmailer>