
Thanks Takuya for starting this discussion thread. Yes, I think R0301 sets bar too high, IMHO. I would make one more point that R0302 cannot allow client-side simpler implementation. Given that OGSA WSRF BP 1.0 mandates to provide state-change notification, client-side implementation is RECEIVER of such state-change notifications. Thus both server-side and client-side software must support TLS and MLS. I guess that is not Takuya's intention. Thoughts? ---- Hiro Kishimoto Takuya Mori wrote:
Hi All,
I am sending this message to get more opinions on the issue about requiring the implementations to support both TLS and MLS.
Hopefully, I'd like to form a consensus on it before reviewing the BSP on the next monday call.
- R0301,0302: mandates that the RECEIVER support both TLS and MLS; and SENDER can use either. - Hiro thinks that this sets too high a bar on implementations and should be relaxed for the RECEIVER also. - Takuya thinks that the secure channel profile sets a high bar anyway so this additional requirement is acceptable and is needed to promote interoperability. - No consensus reached. - Takuya will put the issue to the list to get more opinions.
Here is the statement.
---- R0301 A RECEIVER MUST support both Transport Layer Security and Message Level Security as profiled in the section 3.2 and 3.3 of this Profile.
R0302 A SENDER MUST employ, at least, one of Transport Layer Security or Message Level Security as profiled in the section 3.2 and 3.3 of this Profile. ----
The current draft of the OGSA BSP10 Secure Channel mandates a RECEIVER to "support" both TLS and MLS, while it requires to use at least one of them for a SENDER.
My intention here is that to require the support of the both of TLS and MLS by a RECEIVER is essential to ensure interoperability, because supporting one of them by a RECEIVER allows mismatch of the protocol between a RECEIVER and SENDER.
On the otherhand, as described in the minutes above by Andreas, Hiro thinks that this sets too high a bar on implementations and should be relaxed for the RECEIVER also.
I can also understand his opinion. And I think the cause of the contrary is that we have different priorities between interoperability and practicability.
Any comments to this issue will be welcomed very much! Just telling us your preference will also be great.
Thanks, Takuya