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

 


Help: OASIS Mailing Lists Help | MarkMail Help

trans-ws message

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


Subject: Conditions for URI Approach


Hi all,

 

Following an action item from today’s meeting I am mailing my comments attached to my vote on the URI and SOAP attachments ballot directly to the committee, see below.

 

Regards,

Magnus

 

------------ Comments to my vote (which was for URIs only) --------------------------

 

My vote here is conditional, and only applies if we can satisfactory address the following:

1) Security: Even if we don't explicitly deal with security issues in the standard we must have a recommendation/expected
documented usage that covers the expected requirements for security needs.
- There must be a secure way to transfer data that can be used by all clients
- The need to open additional ports in any firewall should be eliminated or minimised and well documented.
- We must explain how clients can securely provide access to their resources if they are exposed via URIs.
- We must determine if it is acceptable to require outgoing internet access for the implementation/business processing layer
of the web service implementation (which would typically not run in the DMZ)

2) Lifetime: We must have a recommended solution for how to control the lifetime of any resource pointed to by a URI. (One
idea here could be to use expiration dates for all URIs.)

3) Simple Clients: Client side implementation should be as straight forward as possible. It gets complicated if a client
must supply permanent URIs to access resources, or if a client must support multiple different implementations. (Having said that, for client side simplicity I would prefer an optional SOAP with attachments mechanism, just because it is probably the easiest/most expected means of transfer to support for the client.)

My questions essentially boil down to: If we leave the detailed mechanism of data transfer undefined in the standard, how can we provide something that can be used as a generic solution without requiring a lot of complexity in implementation on the client and/or the server? We can of course go with the option of declaring that the details of data transfer would need to be explicitly agreed upon between the customer and the supplier, but that means that it will be very difficult to write a generic client application that can connect to all implementations of the translation web services, regardless of the supplier.

 



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