[ebxml-iic] 9/25/2002: ebMS Deployment Guide Template Draft

[Monica Martin <mmartin@certivo.net>]

Note one comment on Section 2.3.5.2.

-----Original Message-----
From: Eric VanLydegraf [mailto:ericv@kinzan.com]
Sent: Monday, September 23, 2002 8:05 PM
To: 'Pete Wenzel'
Cc: ebXML IIC
Subject: Comments: RE: [ebxml-iic] ebMS Deployment Guide Template Draft
0. 2


Section 2.3.5.2
Is the Manifest Element extenstion required ?

I don't think this is an option.
If a payload container is included in the message than Manifest must be
present otherwise the payload will be discarded
ebMS2.0{line no:991}
should there be no payloads then it's left out.

[MM1: THE UEB ARCHITECTURE TEAM ASKED ABOUT AN ITEM RELATED TO THIS WITH
THE MSH TEAM. I HAVE NOT GOTTEN A RESPONSE ON THE MANIFEST AND THE SOAP
BODY (AND WHETHER THE SPECIFICATIONS COULD POTENTIALLY NOT BE IN SYNC):
Passed a question to ebMS to clarify if the SOAP specification and
schemas support the manifest schema and specification normative text (Is
there a technical contradiction). See section 2.1 to ensure that the
manifest schema and specification, section 2.1 and SOAP specifications
or schema are consistent.]

The use of MAY here is more of a XSchema distinction, later on the
precise
rules of inclusion/exclusion of the element are spelled out.

But note:
ebMS2.0{988-990}xlink:href containing an unresolvable URI MAY be flagged
with an error - implementors decision.
I see this as a possible candidate for deployment guideline though.

Suggestion:
Maybe stick to "scheme" for all string format type choices 
3.1.1.1 & 3.1.3 is good example
but 
3.1.2 (CPA_ID) could be a scheme too, right ?
There may be other occurences of this, I wasn't very thorough in
tracking
this particular issue.
also do we have to worry about providing an example for those who will
fill
out the template ?

4.2.3.2.2
We should have them specify the codeContext if different from the
established standardized one or at least a scheme format.

4.2.4.3
I think the intent of this is that if the error related to a different
message is piggybacked onto a regular message than the Service/Action
are
the normal Service/Actions that are related to the message not the
error.

Otherwise if the message is only an error message than the
Service/Action is
specified
ebMS2.0{1380-1381}
I don't think there's a deployment guide decision for this. 
Suggest removal.

B.2.2 suggested rewrite
If other than "ebXML" what must the SOAPAction HTTP header field be?
Same for B.3.2 (though HTTP => SMTP should be changed)

B.2.6
Though not specified and implied in B.2.7 another form of access control
is
SSL Client Cert.

As an additional deployment guide section I propose we may want to
consider 
infrastructure guidelines.
E.g. handle payloads up to X MB, bandwith, processing capabilities ...

Certain deployment scenarios may expect infrastructure capabilities that
are
completely out of scope of ebMS specification but are additional
requirements for the deployment scenario for a given group.

--
Note:
I agree with Jacques suggestions for changing the organization of the
options, if we do it we should keep the ebMS reference anchors so that
one
can match the template section with the specific ebMS
requirement/option.


-----Original Message-----
From: Pete Wenzel [mailto:pete@seebeyond.com]
Sent: Monday, September 16, 2002 2:40 AM
To: ebXML IIC
Subject: [ebxml-iic] ebMS Deployment Guide Template Draft 0.2


Attached is a draft of the Deployment Guide Template, as discussed in 
recent calls.  Its purpose is to assist user communities (such as 
industry groups) in specifying how ebXML Messaging is to be used within 
that community, to meet differing business requirements and to foster 
interoperability.  EAN.UCC will be among the first to use/validate this 
template.  When filled in completely, the result is a Deployment Guide.

Jacques has already provided some good initial feedback; in the next 
draft, I will incorporate his suggestions.  At the moment, they are just

noted for future reference.

Please review the document and comment.  In particular:

1. Did I catch all "SHOULD" and "RECOMMENDED" options?  Are all 
questions appropriate?  What else needs to be asked?

2. Identify items that are subject to CPA (and/or BPSS), and note them. 
  (I have done this in some places.)  Organizations may still wish to 
use this template to influence choices that can be made in a CPA, or 
which they may instead specify in BPSS, but they should be made aware of

the overlaps that exist.

3. Optional: Provide descriptive text for each item, discussing the 
ramifications of choices that can be made.  For which is an answer 
mandatory?  Where the MS spec makes recommendations as to certain 
options, note that as well.

--Pete
Pete Wenzel <pete@seebeyond.com>
SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>