Re: [gupnp] [PATCH] Respond to M-SEARCH requests for urns specifying an eligible version

[Stephen Depooter <stephend xandros com>]

On Monday 14 June 2010 04:40:05 pm Zeeshan Ali (Khattak) wrote:
> Hi,
>
> On Mon, Jun 14, 2010 at 11:13 PM, Stephen Depooter <stephend xandros com> 
wrote:
> > On Thursday 10 June 2010 05:17:56 pm Zeeshan Ali (Khattak) wrote:
> > Extra white space fixes removed.
>
>   Thanks!
>
> > UPNP requires that we only respond to M-SEARCH requests for urn:
> > queries where we implement a compatible version of the specified
> > interface.  This is documented in UPNP Device Architecture version 1.1
> > section 1.3.2.
>
>    1.3.2 is about requests, I think you meant 1.3.3. Regarding version
> match, the specs require us to be backward and forward compatible (at
> least thats what DLNA requires) and that is why we want to be version
> agnostic when replying to M-SEARCH.

I think this patch correctly implements the responses to M-SEARCH requests.

The last paragraph of 1.3.2 talks about when to reply. section 1.3.3 only 
talks about the content of a reply when you actually do reply to the search 
request.

The last paragraph of 1.3.2 says:
"Updated versions of device and service types are REQUIRED to be fully 
backward compatible with previous versions. Devices MUST respond to M-SEARCH 
requests for any supported version. For example, if a device 
implements “urn:schemas-upnp-org:service:xyz:2”, it MUST respond to search 
requests for both that type and “urn:schemas-upnp-org:service:xyz:1”. The 
response MUST specify the same version as was contained in the search 
request. If a control point searches for a device or service of a particular 
version and receives no responses (presumably because no device present on 
the network supports the specified version), but is willing to operate using 
a lower version, it MAY repeat the search request specifying the lower 
version."


So my interpretation of 1.3.2 says that if you only implement version x of a 
service/device type, you must not reply to a request for version x+1 etc.  If 
the control point receives no responses for version x+1, then may resend a 
search request for a lower version x and hope to get an applicable response.
Backwards compatibility for services and devices is mandated in the upnp spec, 
so future versions must implement the previous versions commands and 
interfaces, however it is imposible for implementations of old versions to 
already implement new versions.  The DLNA spec volume 1 section 7.2.1.3 
mentions older control points not being expected to interoperate with newer 
devices.  However they can still use "parts of the UPnP device/service that 
are compatible witht he older conventions".  This is the backwards 
compatibility portion of the Upnp requirement.


-- 
Stephen Depooter
<stephend xandros com>
--
To unsubscribe send a mail to gupnp+unsubscribe\@o-hand.com