RE: [internal] RE: Proposal for managed mode cluster of issues

Alain,

Thanks for reviewing the proposal and providing the feedback. Please see inline for my comments.

Thanks,

Vipul

From: Alain Regnier [mailto:alain@ricoh-tech.com]
Sent: Friday, October 17, 2008 3:52 AM
To: ws-dd@lists.oasis-open.org
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:Vipul.Modi@microsoft.com]
Sent: Mon 10/13/2008 12:43 PM
To: ws-dd@lists.oasis-open.org
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

ws-dd message