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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Proposals to issues


All, I had an action item about new proposal for Rel9 - Pull model. And here is the proposal for it and some additional proposal for other issues also. Rel9 : Pull model Proposal: Include a support for pull model or poll model. This is useful for an endpoint that can initiate a connection but can't accept a connection. The use cases for the pull model are as follows: - To send a message to the endpoint inside a firewall. Firewall doesn't allow an incoming connection, but the endpoint inside a firewall can initiate a connection for polling a message. - To send a message to a mobile device that has not capability to receive an incoming connection. These use cases are included in the presentation at: http://lists.oasis-open.org/archives/wsrm/200305/ppt00000.ppt *I believe the word "Pull model" I use is the same with the word "Poll model/Polling model" that others call. So I think it's better to use one word for the same functionality. I slightly prefer to use "Pull model". The reason we used "Pull" is because it is symmetric to "Push" which is a normal request message in the HTTP request. So I would like to propose we use "Pull model". And the fact is the pull model is using polling mechanism to receive a message. Any comments? Rel3: Non HTTP bindings Proposal: The spec should not preclude other bindings, but defer to include those bindings in the next spec. Rel7: Backwards compatibility Proposal: The title of the Section 5.5 in the requirements doc Ver0.1 seems to be incompatible with the description of R5.1. Remove the requirement or make a clarification. Rel8: Intermediaries clarification Proposal: The spec should be able to use with other open standard specification to support of Intermediaries. However the spec itself only consider that the intermediaries are transparent with SOAP level, if any. Rel13- 22 (10 issues): Proposal: Create a separate issue list for issues to the spec. And move Rel13-22 to the new list. *Since these 10 issues are come from an issue list on the WS-R spec, it is appropriate to discuss these items in a discussion of the spec. Rel23: Security DOS Proposal: This issue should be considered in the transport level, and neither include in the requirement list nor in the spec, how to deal with this attack. Rel25: Compatibility Proposal: Include a requirement as follows: The spec should be usable with other open standard technologies, if appropriate. Other discussion: WSDL Proposal: A spec should be usable with WSDL without requiring WSDL spec to be extended. Thanks, Iwasa

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