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

[Sander Fieten <sander@fieten-it.com>]

Title: 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.
§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 ?
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.”
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?
L540-541: Last sentence is incomplete.
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. 
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