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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: Re: [ebxml-cppa] Transport extensibility questions for 2.1



> Moberg: Hi
> I am working on some residual 2.1 extensibility problems that have not 
> been discussed in a while and keeping an eye on what might be required 
> of us for handling ebMS 3.0.
>
> Yesterday ebMS began considering HTTP transfer protocol bindings that 
> are "reversed" from the ordinary as discussed, for example, in
> http://www.projectliberty.org/specs/draft-liberty-paos-1.0-errata-v1.0.pdf
>
> ......So, suppose we had to express this binding information in CPPA 
> Transport? How should it be done? ....In particular, is it time for us 
> to add attributes/elements to HTTP so that we can specify more details 
> to fix the constraints on these bindings? We have previously discussed 
> whether to add the HTTP methods (the verbs, POST, GET etc). To that we 
> could add whether the request or response is being used. And so on.
>
mm1: Adding attribute or elements may help 'inform' what the norm is 
under these conditions (and adequately discern what is expected in the 
application transport).  Otherwise, the request is a response and a 
response is a request are somewhat counter-intuitive.

> One question is what our "CanSend" really means. I assumed that the 
> CanSend indicates, for a given service and action, who has the data 
> that is being made available to the other party. If so, then for the 
> reverse  binding case, the Sender is the one that needs to advertise 
> its endpoint and protocol information, while the Receiver is the one 
> that connects to that URL and receives the SOAP request in the HTTP 
> body in a HTTP response.
>
mm1: This sounds logical (as logical as most of this does).

>   I am soliciting comments on this interpretation first. After we have 
> some comments, then we can continue with how we might wish to extend 
> the 2.1 Transport model. 
>




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