[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 38: Need to clarify relationship between the WS-RMspecification and MakeConnection specification
+1 From: Doug Davis
[mailto:dug@us.ibm.com]
Option
#1: The base specification could explicitly depend upon the MakeConnection
specification. For example, by using phrases such as the current (line 238)
"Implementations MAY use the WS-MakeConnection anonymous URI template . .
.". The problem with this is that it requires the base specification to
normatively reference the MC specification. This causes the schedules of WS-RM
and WS-MC to be tied together, which runs counter to one of the reasons for
splitting them in the first place. Option
#2: The base specification could refer to optional polling mechanisms
"such as" WS-MC. A logical consequence of this is that the base spec
needs to clearly spell out how the RMS and RMD should behave in the *absence*
of any such polling mechanisms (otherwise they are not really optional).
Foremost is the expected behavior of the RMD when the RMS sends a
CreateSequence message that contains an Offer in which the Endpoint value is
wsa:anonymous. It seems that, absent any polling mechanism, there is no way for
a server-side RMS to resend unacknowledged response messages* and therefore the
RMD SHOULD NOT respond with a CreateSequenceResponse that contains an Accept
element (i.e. the RMD SHOULD NOT accept the offer). - gp
* You
could argue that the client can prompt the server to re-send the response by
re-sending the request. Without getting into the specifics of this idea, it
would still need to be clearly defined in the specification if we expect people
to produce solutions that can interoperate around this feature. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]