Alain,
Thanks for reviewing the
proposal and providing the feedback. Please see inline for my comments.
Thanks,
Vipul
From: Alain Regnier
[mailto:]
Sent: Friday, October 17, 2008 3:52 AM
To:
Subject: RE: [ws-dd] Proposal for managed mode cluster of issues
Hello all,
Some
comments / questions on the Proposal for managed mode cluster of issues...
-
4.1 Hello “In a managed mode, all transport address(es) SHOULD be
included”
Shouldn’t that be the same requirement for ad hoc mode? Same thing for
d:Scope?
[Vipul Modi] In
an ad hoc mode, implementations may want to limit the content of the packet so
as not to exceed MTU. However as you noted down below this could save some
Probe/Resolve. This is a change in the existing behavior and potentially
existing implementations. I would recommend that we track this as a separate
issue and tackle it after CD1.
-
Section 2.7, Ln394-395: "(b) one or more transport addresses at which
network messages can be directed" is not contained in an
"a:EndpointReference element", in the case of logical address in
a:Address.
[Vipul Modi] I
believe this is already covered as part of the issue Antoine filed last week,
Issue 078.
-
<d:AppSequence> in PM and RM:
<d:AppSequence> in PM and RM is optional, as a DeviceProxy can omit that
info in its unicast PM and RM as indicated in Table 4.
[Vipul Modi] Thanks
for catching this. I also missed this in the normative outline of the Hello,
Bye, PM and RM.[Vipul Modi] I have updated the proposal.
- Ln
643: Why not say a Target Service "should include complete metadata in
Hello" for ad hoc mode as well? It could save unnecessary probe/resolves
[Vipul Modi] As
mentioned above let’s track this as a separate issue.
-
Section 4.1.3, Ln 698: Doesn't the Discovery Proxy "listen for multicast
Hello and store information" anyway, even if it's not configured for
multicast suppression? If not, what does the Device Proxy do in ad hoc mode?
Just act as a TargetService?
[Vipul Modi] In
a capacity of a multicast suppression agent yes, otherwise it is acting as a
target service advertising its managed endpoint.
- Fig. 4
Shouldn't the Discovery Proxy include all Target Service info in its Probe
Match, since it has the info already? This way, the client would not need to
send Resolve.
[Vipul Modi] Yes
the Discovery Proxy should include all the information. Thanks for raising
this, it means that this is not very clear from the specification. The PM and
RM sections refer to Hello, which clearly says that all information should be
included in the managed mode. I have added statement in the Discovery Proxy
section of Probe Match and Resolve Match to make this clear.
The figure is showing all possible message exchange patterns. It
does not indicate any sequence. Say a client knows about a Target Service
(saved Printer), the client now joins a network, find a DP. It does not need to
send Probe, it can simply send Resolve.
-
Section 5.2.2: What about in managed mode? does a Target Service completely
ignore probes in managed mode?
[Vipul Modi] The
multicast Probes? In that case the Target Service is also continuing to operate
in an ad hoc mode as well. So no it would not ignore them, it would respond
them normally. See the comment below for more clarification.
The spec
doesn't seem to prevent for a Target Service to act in both ad hoc and managed
mode at the same time on the same network. Is that on purpose?
[Vipul Modi] A
Target Service can operate in an ad hoc mode, a managed mode or both depending
upon its configuration. The specification describes the protocol in both modes.
As I mentioned in the primer comments, a higher level specification may
restrict that for example all Devices MUST support at least ad hoc mode.
Can a
Target Service switch from ad hoc to manged mode and vice versa? How?
It would be useful to have some more clarifications.
[Vipul Modi] This
depends upon the implementation and configuration of the Target Service. For
example, some Target Service may choose to operate in both mode, some may
operate only in managed mode if they are configured to do so. The specification
currently describes a mechanism for client to know about proxy when they send
multicast Probe and Resolve, the clients then can decide if they want to switch
or continue to operate in an ad hoc mode or operate both in an ad hoc and
managed mode.
Alain
From: Vipul Modi [mailto:]
Sent: Mon 10/13/2008 12:43 PM
To:
Subject: [ws-dd] Proposal for managed mode cluster of issues
Hello all,
Please find attached documents that incorporate the proposal
for the following “managed cluster” issues.
022 request-response MEP for communicating with proxy
034 Discovery proxy and multicast suppression requirement
035 define protocol assignment/binding for managed mode
036 discovery messages and managed mode
049 forced managed mode transition for the client
Following documents are attached with this email:
1. wsdd-discovery-1.1-spec-wd-02-managed-02.docx:
Includes the proposed changes with change bars. Note that some of the links may
be broken or you might see some weird formatting of the text within the change
bars. These gets fixed when the changes are accepted (see document 2).
2.
wsdd-discovery-1.1-spec-wd-02-managed-02-nochangebars.docx: Includes the
proposed changes without any change bars.
3. wsdd-discovery-1.1-wsdl-wd-02-managed.wsdl:
Modified WSDL file
Thanks,
Vipul
