PMode.Protocol comments

["Dale Moberg" <dmoberg@us.axway.com>]

·         PMode[1].Protocol.Address: the value of this parameter represents the address (endpoint URL) of the Receiver MSH (or Receiver Party) to which User Messages under this P-Mode are to be sent.

 

Note that a URL automatically determines the transport protocol (for example if the address is an email address, then the transport protocol must be SMTP. If the address scheme is “http”, then the transport protocol must be HTTP.)

 

Well, the URL scheme involving email addresses is actually “mailto” And protocols pop3, imap, and smtp are all associated with mail. pop3 can even be used to send using  "XTND XMIT" extensions. There has historically been considerable confusion about how the mailto: URL scheme actually identifies resources The proposals have ranged from saying that a mailbox resource is identified to saying that the resource is a message composing “form” ). So typing a mailto URL into a firefox window, for example, opens an email application for composing a message.

 

http://www.iana.org/assignments/uri-schemes.html has a number of schemes for URLs whose relation to protocols is more complex than HTTP, HTTPS, FTP schemes. Maybe we could just omit the second sentence about protocol.address? At the least, correct saying that the address can be an email address. An email address without a scheme is not a URL

 

Here are some additional remarks:

 

How about the return leg? Will/can there be an address value? (I suspect that if MEP=Two-way and MEPbinding=push-and-push we need a return value.)

 

But how about MEP=two-way and MEPbinding=sync; then, are we to use the ws-addressing URI (anon) for indicating “return channel”? Will those values be allowed for Pmode? 

 

Is any information about the SOAP binding needed? There is a SOAP version, but if XMLP generates multiple SOAP bindings to HTTP will these need to be distinguished?