MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [FWD: [ebxml-msg-comment] comment from Pim van der Eijk
FYI, DW
-------- Original Message --------
Subject:
[ebxml-msg-comment] Public Comment
From:
comment-form@oasis-open.org
Date: Thu, July 06, 2006 9:13 am
To:
ebxml-msg-comment@lists.oasis-open.org
Comment from:
lists@sonnenglanz.net
Name: Pim van der Eijk
Organization:
Sonnenglanz Consulting BV
Regarding Specification: EbXML Messaging
Services 3.0, Part 1, Core Features
Here is some feedback on
the ebMS3 specification.
I hope you find it useful.
Kind
regards,
Pim van der Eijk
------------------
Line
210-214: add note that also multiple payloads, possibly of
different MIME types, can be transported in a single ebMS message
(important advantage in some applications)
Line 290
Change:
"/x:MyHeader/x:SomeProperty/@value1"
To
"/x:MyHeader/x:SomeProperty/@attribute1"
Line
294:
The prefix "wssswa" is defined
in
http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf
with
the
value
"http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1.xsd"
rather
than
"http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-swa-profile-1.0.xsd"
(The
URL doesn't resolve to an actual XSD at the doc.oasis-open site
though).
Line 309:
These definitions seem to assume that the
terms "Producer" or a "Consumer" are reserved for Endpoints and cannot
be used for Intermediaries. Is that correct?
Line 322:
"There
are two types of ebMS Messages:"
Are these types exclusive? If
a message has both eb:SignalMessage and eb:UserMessage elements, what
is its type? A pull request could at the same time push a
UserMessage. Is that allowed?
Line 323:
The definition does
not say which entity initiates a Signal Message, whereas the definition
of User Message does.
Line 342:
"receive and process
error messages associated"
should this be:
"receive and process
Signal Messages associated"?
Line 352:
"enough message
data"
->
"enough message (meta)data"?
(some of the data
needed may not end up in the actual message)
Line
382-383:
Formatting (no new paragraph)
Line 364:
Section
2.2
Line 489:
"responses to these." -> "responses to these
requests."
Line 495, Message Pulling:
It looks like this
mechanism can be used to select a particular mailbox.
Could this be
generalized to a mechanism where the Initiator wants to retrieve a
response to a particular message? The Responder could have a
database of RefToMessageId values of messages waiting to be pulled. The
requested message may not be the first in the queue.
Could
the Initiator provide additional filtering information, e.g. only
retrieve message less than 1 MB in size? This would increase the
value for SMEs that have limited bandwidth connections.
Or
should the Initiator/Responder negotiate policies about which message
to put in which Message Partition based on criteria like
size?
Is there only one message being pulled for each
PullRequest / MPF?
Line 509:
Uses the "P-Mode" concept
that hasn't been introduced at this point.
Line 527:
Is there
no From/To PartyInfo in a Pull Request?
How does the Responder know
who is pulling?
An initiating MSH may operate on behalf of multiple
Parties (or a single Party with multiple IDs). Is there a need to be
able to specify a "To" (pulling messages sent "to").
Or is an MPF
always unique for a particular PartyId ?
Line 533 and
548:
While it is an non-normative example, it may be clearer to
change these to something
like:
"<eb:MessageId>UUID-4@receiver.com</eb:MessageId>"
"<eb:MessageId>UUID-5@sender.com</eb:MessageId>
<eb:RefToMessageId>UUID-4@receiver.com</eb:RefToMessageId>"
Line
640, section 3.4.1:
It is not clear from this text (and earlier,
line 479-480), whether the concept of MPFs makes sense outside the
context of Pulling. When A pushes messages of two types to B, is
there any benefit in using MPFs?
Line 681, no distinct
addressing for MPFs.
Priority handling (other than queues at sender
and receiver) often also depends on networking management equipment
with bandwidth management (packet shapers). Those products
classify network trafic based on source/target IP addresses, URIs, port
numbers. So some mechanism to associate MPFs with distinct
addresses (statically or dynamically) would be useful.
Line
786:
"the the ebXML Application." -> "the ebXML
Application."
Line 887:
"Because either packaging option can
be used, implementations MUST support
non-multipart
messages."
Should this be:
"Because either
packaging option can be used, implementations MUST support both
multipart and non-multipart messages." ?
Line 901:
"parts.
containing additional" -> "parts containing additional"
Line
903:
"requires an XML content." -> "requires XML
content."
Line 918:
"Package contain a type" -> "Package
contains a type"
Line 965:
"Namespace declaration" -> "A
namespace declaration"
Line 1030:
"the namespace for" ->
"the namespace prefix for"
Line 1079:
"there MUST NOT be
additional Payload Containers."
Does this mean the ebMS 3.0
specification precludes composition with other SOAP protocols that want
to attach data? (Somewhat theoretical question,
admittedly).
Line 1119 and 1148:
"Both eb:UserMessage element
and eb:SignalMessage element MAY"
Does this mean
"Both a
eb:UserMessage element and a eb:SignalMessage element
MAY"
or
"Both eb:UserMessage elements and eb:SignalMessage
elements MAY" ?
If the spec allowed multiple eb:UserMessages, it
could easily support batch/unbatch operations.
Line 1159 and
1165:
Not sure why "(no change beside renaming)" is
there.
Line 1192:
"cid:foo", note that "foo" has to be a MIME
content ID, i.e. "foo@example.com".
Line 1225: this allows
for payloads not in the message, but line 1386 doesn't.
Line
1230:
Why is the element "timestamp" in lower case?
eb:Timestamp would be more consistent?
Line 1253:
What
is the semantics of multiple PartyId elements in a From (or
To)?
EbMS requires these to be alternative names for a single
organizations.
Has this requirement be dropped in ebMS 3? If
yes, that should be specified explicitly.
Note: various
people have struggled to squeeze hierarchical addresses (Company/
Division/ Unit/ Employee) in the ebXML PartyId field.
Line
1311:
"If a CPA is referred to and a receiver determines that a
message is in conflict with the referred CPA, the appropriate handling
of this conflict is undefined by this specification."
What does
this mean for ebCPPA 3.0? Should it have a normative ebMS3 binding that
defines how this is handled in an interoperable way?
Line
1320:
"a profiling exercise" -> "profiles using this
specification"
Line 1382:
"(see Section , for details)"
missing reference.
Line 1386:
"The PartInfo element is
used to reference either a MIME
attachment or an XML element within
the SOAP Body, according to the value of the href
attribute,
described below." Line 1215 mentions URL-identified
payloads too. Does the spec allow this or not? Not according to line
1391-1393.
Note: there may be a case for disallowing URI
payloads, i.e. requiring all payloads to be in the message.
The
semantics of a URI in a PayloadInfo not in the MIME envelope is
unidentified. Should the receiving MSH attempt to download the payload
from the Internet? What if it can't access it?
More useful
would be some sort of ebXML Signal or extension protocol for
downloading/pulling large attachments separately from the main message
is useful. E.g. if there are two attachments, a 40 KB XML document and
a 160 MB PDF file, it would be nice if the first can be pushed and the
second pulled on demand and based on some combination of MessageId and
Content-Id.
Line 1405: Schema element.
Does this mean
that the receiving MSH must validate the payload?
If not, why does
the message handler need to carry this information?
Line 1415:
Instead of Description, there are use cases for allowing
extensible metadata about payloads. E.g. to get the MIME type,
you now have to find the MIME part. Sometimes it makes sense to have
that in the PayloadInfo. If the attached payload is XML
Encrypted, PayloadInfo could reveal the "real" datatype. If the
payload is a TIFF image, the PayloadInfo could provide
meta-data.
Line 1425:
eb:version="2.0" ?
Line
1452:
"However, ebMS message can" -> "However, ebMS messaging
can"
Line 1650:
Is this list exhaustive? If ebMS is
composed with other SOAP protocols, can they be escalated
too?
Line 1669:
"reported in a log I" -> "reported in a
log in"
Line 1830-1833.
How can a containing element
eb:Messaging be encrypted while a contained element eb:PartyInfo is
not? An example would help here ..
Line 2406-2423, section
8.2.3:
If both security and reliability are used, there is presumably
a required processing order of the security and reliability headers?
Where is this specified?
Line 2448-2452:
The
semantics of ack was NOT clearly a delivery semantics in ebMS2. The
ebMS3 specification is more precise in defining At-Least-Once as a
delivery contract. But the specification still allows the option of
acknowledging a message that is not delivered, e.g. in case of a
packaging error that is detected after the reliability processing of a
received message, where only the generation of an error is required .
Shouldn’t the spec tighten-up the requirements for acks, or
at least provide a conformance profile that requires a tighter
semantics? Should this type of difference be documented more
clearly?
Is there a contract P-Mode property that allows partners to
specify this level semantics of Reliability (including or not successful
"Deliver") ?
When RM-Deliver is executed before Deliver, there
may be issues in the case of failover. Suppose the MSH system (or the
interface from the MSH to the enterprise system) crashes, and
processing is transfered to a standby system, that system may want to
have all messages delivered in some previous time interval (e.g. 15
minutes if the standby system needs a few minutes to come to service)
redelivered, even though they have already been acknowledged.
This in order to get any messages possibly stuck between the MSH
and the enterprise system before the crash.
Is this supported by
either the WS-R or WS-RM specifications? If not, could ebMS3 add
some support here?
Line 2499-2502:
It is worth pointing out
that the order or RM-Deliver and Deliver could be
different.
Line 2637, Section 10:
There are some constraints
between Reliable Messaging and ebXML processing.
E.g. all messages
in a WSRM sequence should be in the same ebXML conversation and
CPAId.
Where are these contraints specified?
How are they
enforced in an implementation if it uses non-ebXML aware generic RM
processors?
There is now no ebXML concept of Message
Ordering.Can organizations still use the ordering
features of the
underlying RM specifications?
E.g. certain
service/action/cpaid/conversationid initiate new sequences, and others
terminate them. Is there a way to specify this
correlation.
Partners may want to specify that certain
Service/Action combinations, with a new ConversationID and in the same
CpaId, are to be performed in-order. How do they specify this,
and how does the ebMS processor know about this?
Line
2730:
"This become a" -> "This becomes a"
Line 2851 and
2858:
These examples have invalid Content-Ids (no "@"
sign).
General comments:
SyncReply module in ebMS2
A
mapping from the CPA properties for SyncReply to P-Modes would be
useful, for the existing ebMS2 users looking at ebMS3.
EbMS2 has
a Message Status service.
This seems to have disappeared?
Was it
considered not useful? It seems quite relevant in multi-hop. Do
any of the underlying specifications provide this
functionality?
EbMS2 has a Ping service.
What happened to
it?
EbMS2 had a section C Supported Profiling Services.
It
would be quite useful to have a similar table that maps these profiles
to ebMS3 with WS Security.
EbMS2 had a section 7.6 with reliable
messaging combinations.
When Part II adds support for multi-hop, it
would be useful to review how this could be mapped to ebMS3 with WS-R
or
WS-RM.
---------------------------------------------------------------------
To
unsubscribe, e-mail:
ebxml-msg-comment-unsubscribe@lists.oasis-open.org
For additional
commands, e-mail: ebxml-msg-comment-help@lists.oasis-open.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]