David I agree addressing is a good way to support this, and in general should be used. However, if we want to have something at the SOAP binding layer then this should deal with the fact that not every SOAP message has WS-Addressing headers.
In addition it is more efficient to do routing at the transport level rather than the WSA level. For example, in an intermediary there may be cases where I route the message without every parsing the SOAP envelope. How about if I rewrite it so that: 1. It is recommended to use WSA. 2. the Content-Description is a SHOULD rather than a MUST. 3. It is RECOMMENDED that it is present if WSA is not used Paul On 12/6/06, David Illsley <[EMAIL PROTECTED]> wrote:
Sorry, I have to ask... why not ws-addressing? You could embed an EPR with a refparam identifying the service in the WSDL which should then be copied to the SOAP Header. Or even just use the fact that the ?X-Service-Path would be automatically copied into a wsa:To element. Per Basic Profile 1.1 [1], "All vital information regarding the intent of a message is carried in soap:Envelope." Is another transport-specific out-of-envelope header really necessary? David [1] http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAPAction_HTTP_Header On 06/12/06, Paul Fremantle <[EMAIL PROTECTED]> wrote: > Hi > > I've been working with a consortium who want to be able to use smtp > mail for SOAP1.2. The current SOAP 1.2 binding for email has a concern > that the message is the main body of the email, and might be corrupted > by spam or anti-virus filters that add text into the message. > > So the proposal that is being made is that we base64 encode the SOAP > message as an attachment into the email. > > In addition there is a problem of routing the email to the correct > service. There are several options here: > 1. We could use one email address per service. However, this might be > a little annoying for anyone who pays per email address, because this > might be expensive. It also adds an overhead for management. > > 2. We could use the subject line for routing. Unfortunately subject > headers are routinely updated or truncated by spam filters. > > 3. We could add our own SMTP header, but this might be stripped out. > > 4. We could use a MIME header. Content-Description seems perfectly acceptable. > > We like #4 the best. > > Now we also need a URL syntax for this to specify in the WSDL or as an > EPR. We could create a new URL syntax (e.g. > smtp:[EMAIL PROTECTED]/axis2/services/Version) but there already is a > syntax: mailto. > > In order to capture the "path" to the service (e.g. > /axis2/services/Version) we need to encode this into the mailto URL. > If you read the mailto spec there is a way of encoding headers into > the mailto URL, so I suggested that we could use this to capture the > path information: > > mailto:[EMAIL PROTECTED]"/axis2/services/Version" > > This URL means include an SMTP header > X-Service-Path: "/axis2/services/Version" > > Our spec would also say to copy that value over and add a mime-header > Content-Description: "/axis2/services/Version" > > This has been written up here as a starting point (yes I know it needs work!) > > http://people.apache.org/~pzf/SMTPBase64Binding.html > > Paul > -- > Paul Fremantle > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > http://bloglines.com/blog/paulfremantle > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
