OASIS ebXML Messaging Services TC

  • 1.  Groups - ebXML Messaging TC weekly call added

    Posted 10-20-2009 12:19
      |   view attached

    Attachment(s)

    ics
    ical_25670.ics   662 B 1 version


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

    Posted 10-20-2009 22:36 
    



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


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

    Posted 10-21-2009 01:33 
    




    inline <JD>

    

    

    
From: Sander Fieten 
[mailto:sander@fieten-it.com]
    Sent: Tuesday, October 20, 2009 3:36 
PM
    To: ebxml-msg@lists.oasis-open.org
    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, "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


  • 4.  Message expiration

    Posted 10-29-2009 22:00 
    




    Hello,
    

     
    

    

    In the ebMS 3.0 Core Specification there is a reference 
in F.2.1.1 to the ebMS 2.0 TimeToLive element. In situations where this has 
business semantics, the core v3.0 hints that an extension property could be 
defined with this semantics. During the call there were reservations about 
adding such a property to part 2 (at least without a lot more 
research).
    

    As discussed during the last two calls, we could 
add the following paragraph to section 2.6.2 to 
express reliable messaging semantics for expiration (to stop 
resending/reforwarding):
    

     
    

    Message Expiration. An 
intermediary MAY understand WS-Reliability  [WSR11] headers, even if it is not explicitly 
identified as the target of those headers. If it does, it MAY check the 
value of the wsr:Request/wsr:ExpiryTime. If the value expresses that the message 
being forwarded has expired, as specified by 
WS-Reliability, the intermediary SHOULD discard the message silently without any 
notification to either the sender or destination.  
    

    

    In WS-ReliableMessaging, expiration 
is defined for sequences, not for individual messages, so this mechanism is 
not relevant for intermediaries that just pass on SOAP messages, when 
sequences are established with ultimate receivers. 
    

    Pim
    

     


Related Content