Re: [ebxml-iic] ebMS Deployment Guide Template 24 Feb

[Pete Wenzel <pete@seebeyond.com>]

Thanks, Matt.  I will try to address your comments and turn around a new 
version in the next few minutes, so as not to delay the voting schedule.

Matthew MacKenzie wrote:
> General: Text should be added stating that all values are case 
> sensitive.  I've been bitten by this before.

Will add to instructions section; this should be specified for each 
element to which it applies, by those populating the template.

> 2.1.2: These questions are no really apropriate in the ebMS context.  
> Content-ID is going to be added by the MSH no matter what so that the 
> Manifest can be populated, and the start attribute is a nicety to 
> identify the attachment representing the SOAP envelope.
> 
> 2.1.3.1 See above.
> 
> 2.1.5 Be careful here.  MSHs don't have any obligation to recognize 
> additional mime params.
> 
> 2.2.1 I think this should be delegated to SOAP conformance, I don't see 
> its bearing in a deployment template.
> 
> 2.2.2 This is a conformance issue.

I was thinking about these as I went through the ebMS spec, wondering in 
some cases why they are even mentioned as being optional, instead of 
deferring treatment to the appropriate (SOAP and XML) specs.  I will 
review again and remove the ones that are clearly not governed by ebMS.

> 3.1.1.1 Recomend that the ebMS rules be allowed to govern this.  This 
> just fosters a less complete treatment of the ebMS spec.  Also, type is 
> required only if the value is not a URI.

Clearly the rules must be followed, but there is only one MUST in that 
section, so there is lots of wiggle room and a need for agreement 
between the parties (in their CPAs).  The ebMS spec recommends some 
possible sources for PartyId schemes, but usually a vertical standards 
body will want to specify which ones they support, and exactly how they 
should be identified.

> This may be better dealt with 
> earlier in the document where the PartyId type is defined.

That has been suggested before, but I have kept it in both sections so 
that the business analyst can say which identification schemes are used, 
and the architect can then define the representation of the element and 
attribute contents.

> 3.1.3 I recomend not allowing this to be user-mutable.  Conversation ID 
> generation should follow rules set out by the ebMS specification, and 
> vendors should not be burdened with opening this up to user modification.

I think you're right; the spec clearly states that this is 
implementation-dependent, as long as the conversation initiator 
guarantees it to be unique within the context of the CPAId.  In response 
to Jacques' opinion on this, the note at the end of 3.1.3 in the spec is 
helpful.  It suggests mapping between identification schemes generated 
by other implementations.  You could interpret "another implementation" 
to mean either another MSH, or the application, in which case exposure 
of the MSH's ConversationId to the application is not necessary.

> 4.2.4.1 Do you expect an MSH to withold a SOAP Fault, or do you mean 
> application level errors?

4.2.4.1.1 was removed in one of the final drafts of ebMS 2.0, so it 
should not have been in the template.

--Pete

> Pete Wenzel wrote:
> 
>> Attached is the 24 February revision of the Deployment Guide Template 
>> for ebXML Message Service.  I have incorporated Jacques' latest 
>> suggetions, and feel that it is now ready to be considered for 
>> approval as a committee specification.
>>
>> --Pete
>> Pete Wenzel <pete@seebeyond.com>
>> SeeBeyond
>> Standards & Product Strategy
>> +1-626-471-6311 (US-Pacific)