[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-dd] RE: Issue 131 - DPWS - Problem with SOAP address ofservices on a device
|
Hello everyone- Elmar and I discussed this offline. We may be able to
address this by adding some text in the description of the Hosted Service EPR.
But, we have not yet been able to settle on whether the text should explicitly
call out accidental impersonation. I propose we inform implementers that they should be aware
of the functional implications of their choice of URI, but not get into
specific details, as there will always be more design considerations than we
can list: Implementers are not constrained in
their choice for the [address] part of the HOSTED SERVICE Endpoint Reference,
and should consider functional implications and their DEVICE’s operating
environment when choosing this URI. The benefits and drawbacks of
different HOSTED SERVICE URI topologies is beyond the scope of this document. Elmar proposes we specifically call out accidental
impersonation: Implementers are not constrained in
their choice for the [address] part of the HOSTED SERVICE Endpoint Reference,
and should consider their DEVICES's operating environment when choosing this
URI. A HOSTED SERVICE URI topology may have functional implications like
accidental impersonation of HOSTED SERVICES. A discussion of all benefits and
drawbacks of different HOSTED SERVICE URI topologies is beyond the scope of
this document. I would like to close on this issue tomorrow. Is there any
other input or discussion on this? Thanks --D -----Original Message----- Dan Driscoll schrieb: > > I can’t recall if we had a discussion about this on
a prior call. > We only discussed this in private discussions. The issue
was on the agenda of the teleconference of december the 16th last
year. During this telco we run out of time and simply accepted the issue.
Perhaps it should be discussed again. > > I see this as an interesting implementation point,
but not something > we need for the core specification. DPWS
intentionally leaves URL > topology completely up to the implementer, because
many of the choices > here are very implementation-specific: some devices
host everything on > a single URL for simplicity (they use EPR/Action for
message > dispatching); others host services on unique URLs.
Some devices may > have their hosting URLs specified during
development, and may not be > able to change them as easily as they can
autogenerate a new device ID. > > Accidental impersonation by other services is not
the only > consideration in determining a URL topology. Some
devices host on port > 80—that decision has functional implications, too.
The list is pretty > lengthy, and this is a relatively constrained topic. > > We could possibly produce some text about this, but
I think we can > spend an awful lot of time in the TC producing
implementation guides > when we should really be focusing on the
specifications. > I think, if we add a requirement with a SHOULD
requirement level, the implementers can ignore the requirement. We can add a
note what the implementer should be aware of, if the requirement is
ignored. The problem exists only if there is no link between
service transport addresses and the device. Adding the device id to service
transport addresses is a simple solution that implementers can
adopt. > > Thanks! > > --D > > *From:* Ram Jeyaraman
[mailto:Ram.Jeyaraman@microsoft.com] > *Sent:* Tuesday, December 16, 2008 8:28 AM > *To:* ws-dd@lists.oasis-open.org > *Subject:* [ws-dd] Issue 131 - DPWS - Problem with
SOAP address of > services on a device > > This issue is assigned the number 131. For further
discussions on this > issue, please refer to this issue number or use this
thread. > > *From:* Elmar Zeeb
[mailto:elmar.zeeb@uni-rostock.de] > *Sent:* Monday, December 15, 2008 3:25 PM > *To:* Ram Jeyaraman > *Subject:* New Issue for DPWS > > Description: Problem with SOAP address of services
on a device > Document: wsdd-dpws-1.1-spec-wd-02 > Line number: > > There is the following scenario: A client is using a
service on a > device. This device leaves network and can't send a
bye message. A new > device joins network. The new device hosts a service
of the same type > that has the same transport address as the service
before. The new > device sends a hello message. The client won't be
able to detect that > it uses another instance of the service, that is
hosted on another device. > > Proposed solution: Service addresses should include
the device id or > should be unique. > > -- >
******************************************************************************* > Dipl.-Inf. Elmar Zeeb > Universität Rostock, Fakultät f. Informatik und
Elektrotechnik > Institut f. Angewandte Mikroelektronik und
Datentechnik > University of Rostock, Faculty of CS and EE > Institute of Applied Microelectronics and Computer
Engineering, > 18051 Rostock > Deutschland/Germany > Tel. : ++49 (0)381 498 - 7262 > Fax : ++49 (0)381 498 - 7252 > Email: elmar.zeeb@uni-rostock.de
<mailto:elmar.zeeb@uni-rostock.de> > www : http://www.imd.uni-rostock.de/,
http://www.ws4d.org/ >
******************************************************************************* -- ******************************************************************************* Dipl.-Inf. Elmar Zeeb Universität Rostock, Fakultät f. Informatik und
Elektrotechnik Institut f. Angewandte Mikroelektronik und Datentechnik University of Rostock, Faculty of CS and EE Institute of Applied Microelectronics and Computer
Engineering, 18051 Rostock Deutschland/Germany Tel. : ++49 (0)381 498 - 7262 Fax : ++49 (0)381 498 - 7252 Email: elmar.zeeb@uni-rostock.de www : http://www.imd.uni-rostock.de/,
http://www.ws4d.org/ ******************************************************************************* |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]