Re: [ebxml-msg] Short proposal

[Matthew MacKenzie <matt@mac-kenzie.net>]

Doug Bunting wrote:

> Matt,
>
> Your use cases sound to me like they need two default CPA documents or 
> descriptions rather than one.  At one level, the Messaging TC would 
> need to describe / define the environment in which the Interrogation 
> Service runs. 

Point taken.  What is not in the proposal but probably should be is that 
in order for the interrogation service to work, we need to define the 
default parameters.  I don't think we need a CPA for the interrogation 
service.  I think we just need to say:

- No or explicitly null CPAId value.
- HTTP (No SSL Client Auth)
- No Acks
- No Duplicate Elimination
- No Non-repudiation
- ...


> At another, the service (MSH) receiving an Interrogation Request must 
> have an appropriate Interrogation Response available, meaning it must 
> have the default CPA (where you've focused this proposal).  Getting 
> both levels nailed down may be slightly less straightforward than your 
> proposal implies.

I'm not sure where its gets less straightforward.  Please explain.  It 
might be an issue if the MSH doesn't have a Default CPA...I guess 
Default CPA needs to be addressed at more or less the same time as this 
proposal.

>
> I'd guess deciding the parameter set for executing an anonymous 
> Interrogation Request will form the bulk of the development work for 
> our TC.  The actual Interrogation Request / Response would likely be 
> relatively simple.

Yeah, you're right.  Am I overly optimistic about our ability to agree 
on these parameters?  I think it will be easy, but I have been wrong in 
the past :-)

>
> Small point: My preference would be for the receiving service, using 
> information available in the Request, to respond with a fully 
> qualified CPA rather than having us attempt description of "something 
> (random) between a CPP and a CPA".  The Request shouldn't be anonymous 
> but "merely" be un-authenticated.

That would require a dynamic CPA generator, likely template based.  I 
have no problem with that, but its a thing that can be added later on if 
it proves to be too much of a task for us.


Thanks for reading, Doug.  I'll refine the proposal based on your comments.

-Matt