[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] issue i002 -- another proposal
While an interoperable solution for this would of course be best I concur that now is probably not the right time to address it. +1 to closing with no action. -----Original Message----- From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] Sent: Thursday, November 03, 2005 12:29 PM To: wsrx Subject: [ws-rx] issue i002 -- another proposal I had made a proposal [1] to resolve issue i002. There was a some discussion on this proposal at the last f2f meeting [2]. I also had some discussions with various folks on the sidelines. There was a general pushback on the proposal and we decided take the discussion to the mailing list. The pushback was mostly based on issues around: 1) Security -- this opens a security hole allowing hijacking of the sequence. I don't think this is an issue, as the same security solutions that were used in the Sequence creation can be applied for changing the AcksTo. 2) Complexity -- This adds complexity to the protocol for what is thought to be a corner case or perhaps something to be added in version 2.0. 3) Flexible EPRs -- EPRs don't require one to include fixed "addresses" or IP addresses. 4) Proprietary solutions -- Some telecom vendors say that they have a transparent solution for this. 5) This is a general problem -- It is a general problem with EPRs with various potential solutions, WSRM should not solve this in a WSRM-specific way. 6) Close the current Sequence and start a new one -- why can't the RMS just close the current sequence and start a new one and deal with it at a higher level? All of the solutions require either normal closing and opening of a new RM sequence (with an application level collation of RM sequences) or an intermediary or a lookup service (with no standard or wide deployment). We had an internal discussion within our mobile team (mobile usecase was the one driving the requirement) and we feel that it would be best if there was an interoperable way within WSRM to solve the problem without relying on proprietary solutions. But given the general pushback from the TC, although not our first preference, we would be OK with our own proprietary solution with a potential for including this requirement in a future version (if there is one) of the spec. Therefore, I would like to make the following proposal: Close with no action. Thx. -Anish -- [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509 /msg00256.html [2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14693/Mi nutesWSRXF2f-0905.htm#_Toc115510926
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]