OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification


Title: New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

We need to clarify the relationship between the base WS-RM specification and the MakeConnection specification. It seems that there are two options:

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.

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]