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: 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/MinutesWSRXF2f-0905.htm#_Toc115510926


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