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

[Stephen Depooter <stephend xandros com>]

I've been away from the office on vacation for a while, so have been unable to 
get back to this.


The UPNP spec specifically refers to the meaning of supported versions of 
device and service types.

Section 2.3:
"For standard devices defined by a UPnP Forum working committee, MUST begin 
with “urn:schemas-upnp-org:device:” followed by the standardized device type 
suffix, a colon, and an integer device version i.e. 
urn:schemas-upnp-org:device:deviceType:ver. The highest supported version of 
the device type MUST be specified."

In section 1.3.2
"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."


Specifically the device must respond for any supported version.  Since the 
device clearly states in the description the highest supported version of a 
device or service implemented by the software, it must not respond to 
M-SEARCH queries for higher versions that the "highest supported version"

This is the behaviour that my patch implements.




On Wednesday 23 June 2010 07:29:44 pm Zeeshan Ali (Khattak) wrote:
> Hi,
>
> >> > 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."
> >>
> >>   With our devices it doesn't come to that since we respond to request
> >> with ANY version.
> >
> > Yes, but that is the point.  gssdp will happily respond to a request for
> > a MediaServer:3 if it only implements MediaServer:2.  Clearly this is
> > wrong since  a Control point getting a response back with the version of
> > the request, and not the version implemented will expect to be able to
> > use the new features in the MediaServer:3 specification, and not just the
> > MediaServer:2 specification.
>
>   No, this is actually correct. The device/service needs to reply to
> requests for ALL versions. The theory is that each new spec is
> supposed to be backward compatible so a control point designed for
> MediaSever:2 should be able to operate with MediaServer:3 with
> functionality limited to MediaServer:2 spec.
>
> > The proper behaviour is to only respond to requests for device/service
> > versions that the device in question implements.  Which would be
> > MediaServer:2 or MediaServer:1 in this case.
>
>    The proper behavior is (unfortunately) not dictated by common sense
> but by UPnP and DLNA specs. If you could point out any specific
> requirements from any of these two specs that we are voilating, we'll
> be happy to change the behavior.



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