← Prev in month
← Prev in thread
Next in thread →
Next in month →
RE: [ws-dd] Issue 123 - WS-Discovery - Remove special "ad-hoc" scope
Antoine and I discussed this offline; following is the modified proposal for this issue. This proposal defines a new scope matching rule for matching Target Services that do not have any scope. This avoids defining a version dependent default value in the Target Service metadata. Section 4.1 /s:Envelope/s:Body/*/d:Scopes Unordered set of Scopes the Target Service (or Discovery Proxy) is in, which MAY be of more than one URI scheme. If included, MUST be a set of absolute URIs, and contained URIs MUST NOT contain white space. If omitted or empty no implied value implied value is a set that includes "http://docs.oasis-open.org/ws-dd/discovery/2008/09/adhoc". In a managed mode, all Scopes SHOULD be included. Section 5.1 http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0 Using a case-sensitive comparison, the string representation of S1 and S2 is the same. http://docs.oasis-open.org/ws-dd/discovery/2008/09/none Using this rule, the Probe match the Target Service, if and only if the Target Service does not have any Scopes. When a Probe specifies this rule, it MUST NOT contain any Scopes. Thanks, Vipul -----Original Message----- From: Antoine Mensch [mailto:] Sent: Monday, December 22, 2008 5:27 AM To: Subject: Re: [ws-dd] Issue 123 - WS-Discovery - Remove special "ad-hoc" scope WS-Discovery specifies that a Probe with no scopes matches Target Services in any scope. Because the spec does not define a specific way to retrieve a Target Service with no scope, when a Target Service has not been configured with any specific scope (a likely case, as scopes are in general deployment time information), such a service may only be retrieved using a Probe with no scope, which is pretty inefficient. Target Services should therefore always have a default scope, when none has been specified at deployment time. This default scope could be left as an implementation choice, but it makes sense to define a standard one for increasing interoperability in scenarios such as the one outlined in my previous mail (see below). It is also a way to avoid breaking backward compatibility with applications that rely on an existing feature. In order to avoid associating the default value semantics to empty Scopes in Hello, ProbeMatches and ResolveMatches, but rather to specify that a Target Service must match a Probe with the default scope when none other has been configured, I propose to add the following paragraph at the end of section 5.1 (Matching Types and Scopes): /Target Services MUST always have at least one Scope, as they would otherwise only match a Probe with no Scopes, which is used as a wildcard to match any Scopes. When no specific scopes have been specified for a Target Service, its Scopes consist of a set that includes "http://docs.oasis-open.org/ws-dd/discovery/2008/09/adhoc"./ Antoine Mensch a écrit : > I agree that the ad-hoc scope usage is not particularly clear in the > spec. However, we do have a use case for it: we use it as a marker for > devices that have not been configured yet, so that an admin > application can explicitly look for them and start the configuration > process. Maybe we could add something in the text that says that > devices that do not have a specific scope are by default in the > "ad-hoc" scope. > > Cheers > > Antoine > > Ram Jeyaraman a écrit : >> >> This issue is assigned the number 123. For further discussions on >> this issue, please refer to this issue number or use this thread. >> >> *From:* Vipul Modi >> *Sent:* Monday, December 15, 2008 4:06 PM >> *To:* Ram Jeyaraman >> *Subject:* New Issue: WS-Discovery: Remove special "ad-hoc" scope >> >> *Spec:* WS-Discovery >> >> *Version:* Working Draft 04 >> >> *Details:* >> >> Section 4.1 Hello specifies that if a service does not have a Scope >> it is said to be in an “adhoc” scope >> http://docs.oasis-open.org/ws-dd/discovery/2008/09/adhoc. >> >> The absence of the Scopes in the Hello may not mean that a Target >> Service does not have any scopes. The Target Service may not >> advertise the scopes because of the security reason or because of the >> size limitation. In such case it is difficult for the client to >> assume that service is in an “ad-hoc” scope. What happens when the >> Probe include this special value, should all services that advertised >> empty Scopes respond or should the services that do not have any >> scopes configured respond? Furthermore there does not appear to be >> any scenario for this special treatment for the empty Scopes field. >> It is seems to be an unused feature that is not well understood and >> defined. >> >> *Proposal:* >> >> Remove the special “ad-hoc” scope. >> >> *Section 4.1* >> >> /s:Envelope/s:Body/*/d:Scopes >> >> Unordered set of Scopes the Target Service (or Discovery Proxy) is >> in, which MAY be of more than one URI scheme. If included, MUST be a >> set of absolute URIs, and contained URIs MUST NOT contain white >> space. If omitted or empty no implied value implied value is a set >> that includes >> "http://docs.oasis-open.org/ws-dd/discovery/2008/09/adhoc". >> >> In a managed mode, all Scopes SHOULD be included. >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus >> Database: 270.9.18/1849 - Release Date: 15/12/2008 09:01 >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 15/12/2008 17:04 > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
← Prev in month
← Prev in thread
Next in thread →
Next in month →