[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 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----- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]