ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] Groups - ebXML Messaging TC weekly call added
- From: "Jacques R. Durand" <JDurand@us.fujitsu.com>
- To: "Sander Fieten" <sander@fieten-it.com>, <ebxml-msg@lists.oasis-open.org>
- Date: Tue, 20 Oct 2009 18:33:10 -0700
Title: Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added
inline <JD>
Below are my comments after reviewing version 0.43 of
the part 2 draft.
Sander
L45: Insert TC name
L220:
specifications should be specification
L289: As there’s a new version of the
AS4 profile I think this reference must be corrected
L341-L345: IN the
description / definition of the intermediary it is stated that routing is based
on patterns and that the routing function should use ebMS meta data for
interoperability. This is much more general than what is specified and an
earlier text in this paragraph. I would prefer to have a more strict
definition.
<JD> We may not need to be more detailed at this glossary
level. How about :
"... a routing function
that maps messages based on header content to the next
MSH (as
defined in section ...), either to a next MSH destination or to a
pull channel . "
§2.3.3: As mentioned some time ago I think the Bridged Domains topology
as currently described is not supported by this profile as it allows for
different protocols in de domains. The profile however requires end-to-end ebMS
messaging. Removing the different protocol usage from the bridge domains
description leaves nothing more than another instance of the interconnected hubs
topology. I can’t create a useful description, maybe one of you can? If not, I
would prefer to remove this topology from the document.
§2.3.4: Should this
section not precede 2.3.3 ?
<JD>
how about removing 2.3.3 and expanding a bit on 2.3.2 by mentioning the "bridged
domains" variant, where the regional Hub is serving as a gateway to an entire
subnetwork that can in turn involve other Intermediaries? The rationale is that
such gateways would isolate their subnet, each subnet being only reachable
via the gateway.
L417-421: Remove last
sentence from paragraph as it not really related to the transparency
feature.
L456-457: Change “... including Reliable Messaging ... signed.” to
“... including WS-ReliableMessaging and WS-Addressing header elements where used
within WS-ReliableMessaging to be signed.”
<JD>
still unclear wording...how about replacing with "...which specifies how to
combine reliable messaging and security"
L460: Insert “see section 2.6.2
on forwarding models” after “... subsequent forwarding”
L464: Change
“P-Modes” to “P-Mode features”
L472-475: Text unclear, remove?
<JD>
agree.
L540-541: Last sentence is
incomplete.
<JD>
how about replacing with: "However
they will be given some composed names such as
"First-and-Last-Push".
L665: Change the name to “Request-push-last-sync and
Reply-sync-last-pull”
L851: Remove missing reference or refer to section on
sub-channels and/or core spec on MPC.
L862: Remove “empty bullit”
L871:
Here it is stated that routing of PullRequests can be done on MPC alone. It’s
unclear to me which routing is meant here, because in most situation I expect
PullRequests not to be routed but directly processed by the Intermediary. If the
request is routed I assume it is routed to the Sending endpoint. And in such
situation I would expect that more information than only the MPC is needed for
routing.
<JD>
see 2.5.2.2, case (3), for routing of PullRequest. If more info is needed for
routing, then a ref parameter is added (like for other signals). But there is
nothing else "natively" available other than MPC, in
PullRequest.
L873: Reference to message
(a) and (b) should be reference to message 1 and 2
L883-888: Several element
names not formatted as such
L893-894: See earlier remark on which message is
routed here, the PullRequest or an User Message waiting at the intermediairy to
be pulled?
On 20/10/2009 14:18, "
ian.c.jones@bt.com" <
ian.c.jones@bt.com>
wrote:
Team,
sorry for
the late notice - details as
usual.
Please review Part 2 draft - I
have seen no comments on the list.
Thanks,
Ian
-- Mr.
Ian Jones
ebXML Messaging TC weekly call has been added by Mr. Ian
Jones
Date: Wednesday, 21 October 2009
Time: 11:30am -
01:00pm PT
Event Description:
ebXML Messaging TC weekly
call
Tel: +1-218-486-8700
Pass code 120905
Agenda:
1.
Role
2. Approval of previous minutes
3. V3 Advanced features -
bundling
4. V3 Final review
5. AS4 - Updates
6.
A.O.B.
Minutes:
View event details:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/event.php?event_id=25670
PLEASE
NOTE: If the above link does not work for you, your email
application
may be breaking the link into two pieces. You may be able to
copy and
paste the entire link address into the address field of your
web
browser.
Referenced Items
Date
Name
Type
----
----
----
2009-10-20
MessagingTC101409.htm
Minutes
2009-09-28
ebMS3-part2-V43.odt
Reference
Document
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]