RE: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

From
"Kacques Q. Eurand"
Date
2009-10-21T01:33:24+00:00
ID
Thread
RE: [ebxml-msg] Groups - ebXML Messaging TC weekly call added
Title: Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

inline <JD>

From: Sander Fieten 
[mailto:] 
Sent: Tuesday, October 20, 2009 3:36 
PM
To: 
Subject: Re: 
[ebxml-msg] Groups - ebXML Messaging TC weekly call added

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, "" <> 
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