RE: [ebxml-iic] Groups - ebMS 2.0 Deployment Profile Template (ebMS2-Deployment-Profile-Template-1.1-b.doc) uploaded

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: [ebxml-iic] Groups - ebMS 2.0 Deployment Profile Template (ebMS2-Deployment-Profile-Template-1.1-b.doc) uploaded

Pim:
Pim:
Good input here. If I set up a call this Monday 20, 11am PT, would you be able to attend to discuss this?
See inline my answers.
Please see a next email announcing the latest posting that takes your input into account.

Cheers,
Jacques

-----Original Message-----
From: Pim van der Eijk [mailto:pim.vandereijk@oasis-open.org]
Sent: Tuesday, June 14, 2005 8:34 AM
To: Jacques Durand; ebxml-iic@lists.oasis-open.org
Subject: RE: [ebxml-iic] Groups - ebMS 2.0 Deployment Profile Template (ebMS2-Deployment-Profile-Template-1.1-b.doc) uploaded

Jacques,

Here is some feedback on the document;  hope this is useful ..

2.1.4 A community could also impose restrictions at the MIME envelope level.
E.g. restricting the MIME types allowed for attachments, and the relative
order of attachments of various types.   The total size of the message may
be an issue, e.g. when SMTP gateways are used in the community, so average
and maximum message size is useful information in a profile.

<JD> I would add this profiling option in section 4.5 (not directly related to any spec feature or message element in Section 3)

3.1.6 Some ebXML profiles have requirements for the format and source of
MessageId.  E.g. in the HL7 DSTU it is derived from the HL7 interaction id.
Similarly for RefToMessageId. 
There may be length and format restrictions if the ID is generated by an EAI
messaging protocol that the ebMS processor bridges to.

<JD> OK, although it seems that there is no spec requirement for letting users decide of the conversationId... A conforming MSH may very well prohibit users to do what you say. Nevertheless, this being an implementation issue, some other MSHs will let you do what you said. So I propose indeed to add a profiling line, just in case a user community decides to use such MSHs that let them control the conversationId.

3.1.4 An example of a different use of ConversationId: In HL7 there is a
concept of interactive queries, where there would be a message for query
initialization, and then messages for "give me the next batch" continuation
queries.  The ConversationId could be used to encode such interations within
a single query to allow a backend data source to set and maintain a cursor
corresponding to a query. This it is not in the current DSTU, but was
proposed for a revision.

<JD> sounds a good use case. Falls under former 3.1.4 section, profiling (a) I believe.

3.19 Manifest.  The profile could specify if the order of Manifest elements
has to match the order of the referenced MIME attachments. Some profiles may
restrict the range of value for xlink:reference (e.g. nothing other than
content id references).

<JD> will add this to (former) 3.1.9.

General:

It may be useful to separate functionality of the ebXML message processor
from the application adapter invoking the message processor.  E.g. it is
important to know which optional parts of ebMS are needed to interact in a
particular community when you are in a software supplier selection process.
This is independent of payload format.

<JD> added section 4.6 to capture this.

Functionality such as setting ebXML header fields (e.g. MessageId) based on
XML payload data would be part of the invocation of the processor, rather
than its ebXML capabilities. The "alignment" field is very useful for
applications where ebXML header fields are filled from corresponding fields
in the XML payloads, in addition to the alignment with CPA and BPSS.  For
example, the HL7 ebXML DSTU provides such a mapping for HL7. The
responsibility of preserving this mapping is of the application invoking the
message processor, rather than the ebXML processor.

<JD> made this more explicit in section 1.3 alignment field.

Pim van der Eijk